TURBO anomaly with mixed FP and INT expression...
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
TURBO anomaly with mixed FP and INT expression...
Hi everyone!
I've just been making some tweaks to a Y-Modem like file-transfer prog that I developed some time ago and use regularly to move files between my laptop running QPC and my QL.
One little niggle that I had never resolved was a simple 'progress' indicator that, when the prog runs in either SBasic on QPC or Minerva SuperBasic produces the expected results, but whenever TURBO'd, always returns 0% until finally it switches to 100% - again on both platforms.
Here's the basic line:
progress=INT( (expBlk% / totBlks%) * 100)
I'm guessing some clever INTeger optimisation in TURBO that is producing an int result for division in the inner parenthesis (expBlk% / totBlks%) - which clearly would result in 0 until the two int variables match, when it becomes 1.
I can easily recode using FP vars instead of INTs to avoid this, but wondered if this is expected behaviour in TURBO'd programs?
I've just been making some tweaks to a Y-Modem like file-transfer prog that I developed some time ago and use regularly to move files between my laptop running QPC and my QL.
One little niggle that I had never resolved was a simple 'progress' indicator that, when the prog runs in either SBasic on QPC or Minerva SuperBasic produces the expected results, but whenever TURBO'd, always returns 0% until finally it switches to 100% - again on both platforms.
Here's the basic line:
progress=INT( (expBlk% / totBlks%) * 100)
I'm guessing some clever INTeger optimisation in TURBO that is producing an int result for division in the inner parenthesis (expBlk% / totBlks%) - which clearly would result in 0 until the two int variables match, when it becomes 1.
I can easily recode using FP vars instead of INTs to avoid this, but wondered if this is expected behaviour in TURBO'd programs?
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
Re: TURBO anomaly with mixed FP and INT expression...
Whilst still interested in whether this is an expected TURBO thing, I got around this trivial problem without resorting to nasty FPs, but simply with:
progress = INT( (expBlk% * 100) / totBlks% )
I then decided I didn't need 'progress' as an FP at all and simply recoded the whole thing as an INT:
progress% = (expBlk% * 100) / totBlks%
I must remember to watch out for such TURBO INTeger optimisations in the future...
progress = INT( (expBlk% * 100) / totBlks% )
I then decided I didn't need 'progress' as an FP at all and simply recoded the whole thing as an INT:
progress% = (expBlk% * 100) / totBlks%
I must remember to watch out for such TURBO INTeger optimisations in the future...
Re: TURBO anomaly with mixed FP and INT expression...
Most probably, Turbo reverts to integer division when divididng two integer types (sounds logical, doesn't it?), while SBASIC does what it always does when calculating expressions: It uses a floating point result.
Tobias
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Aurora
- Posts: 932
- Joined: Sat Oct 25, 2014 9:53 am
Re: TURBO anomaly with mixed FP and INT expression...
Thinking about it, the normal divide / should probably be excluded from the optimisation - after all, if you wanted integer divide, you would simply use the DIV operator.
As it is, I have to watch-out that expBlk% never exceeds 327 using the workaround.
No biggie - I'll always love TURBO - thanks SNG and GG
As it is, I have to watch-out that expBlk% never exceeds 327 using the workaround.
No biggie - I'll always love TURBO - thanks SNG and GG
-
- Super Gold Card
- Posts: 716
- Joined: Mon Nov 24, 2014 2:03 pm
Re: TURBO anomaly with mixed FP and INT expression...
Hi,
Try this:
100 PRINT MODULO(999999,987654)
110 :
120 DEFine FuNction MODULO(ms,md)
130 RETurn ms-(INT(ms/md)*md)
140 END DEFine
:
This seems to be OK for huge 6-didgit numbers, which I wrote recently.
Please feel free to use it.
If you should find any bugs, please let us all know...
Regards,
Steve.
Try this:
100 PRINT MODULO(999999,987654)
110 :
120 DEFine FuNction MODULO(ms,md)
130 RETurn ms-(INT(ms/md)*md)
140 END DEFine
:
This seems to be OK for huge 6-didgit numbers, which I wrote recently.
Please feel free to use it.
If you should find any bugs, please let us all know...
Regards,
Steve.
Re: TURBO anomaly with mixed FP and INT expression...
I was going to suggest the following MODification which is slightly faster (But DIV only works on long ints in SBASIC, IIRC):stevepoole wrote:<><>Code: Select all
100 PRINT MODULO(999999,987654) 110 : 120 DEFine FuNction MODULO(ms,md) 130 RETurn ms-(INT(ms/md)*md) 140 END DEFine
Code: Select all
120 DEFine FuNction ModL(ms, md)
130 RETurn ms - (ms DIV md) * md
140 END DEFine
150 :
999969 DIV 31 = 32257, as expected, but from then on we get
999970 DIV 30 = -32204 !?! - should be 33332
999971 DIV 29 = -31055 - should be 34481
etc
Surely this is a bug?
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
-
- Super Gold Card
- Posts: 716
- Joined: Mon Nov 24, 2014 2:03 pm
Re: TURBO anomaly with mixed FP and INT expression...
Hi Per,
I can vouch for the bug on QPC2 too... I get the same bad results as you using DIV .
Who has the code for the DIV function ? It definitely needs debugging.
The problem is that SMSQ integers range from -32768 to 32767 !
The MODULO (or should it be MODULUS?) code uses bigger 'integers'. This is why I wrote it in the first place.
Regards,
Steve.
I can vouch for the bug on QPC2 too... I get the same bad results as you using DIV .
Who has the code for the DIV function ? It definitely needs debugging.
The problem is that SMSQ integers range from -32768 to 32767 !
The MODULO (or should it be MODULUS?) code uses bigger 'integers'. This is why I wrote it in the first place.
Regards,
Steve.
Re: TURBO anomaly with mixed FP and INT expression...
We all have the source code, Steve. Its available here: http://www.wlenerz.com/smsqe/
Its obvious whats going on: DIV accepts long word parameters, but only returns a signed (short) word result, same as an SBASIC integer%. I guess I was just shocked because it doesnt seem like an obvious implementation choice to me. As every other ql-er, I wrote my own LDIV and LMOD functions in assembler and mine return a long word result (converted to FP on return to BASIC, of course)
Its obvious whats going on: DIV accepts long word parameters, but only returns a signed (short) word result, same as an SBASIC integer%. I guess I was just shocked because it doesnt seem like an obvious implementation choice to me. As every other ql-er, I wrote my own LDIV and LMOD functions in assembler and mine return a long word result (converted to FP on return to BASIC, of course)
Per
dont be happy. worry
- ?
dont be happy. worry
- ?
Re: TURBO anomaly with mixed FP and INT expression...
That is maybe not the whole of the problem - for some arguments (like $80000 DIV 2) we get correct (long integer) results.pjw wrote: Its obvious whats going on: DIV accepts long word parameters, but only returns a signed (short) word result, same as an SBASIC integer%.
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: TURBO anomaly with mixed FP and INT expression...
Hence the disclaimer under my signature I guess the next step will be to actually peek at the source code to see whats going on..tofro wrote:That is maybe not the whole of the problem - for some arguments (like $80000 DIV 2) we get correct (long integer) results.
Per
dont be happy. worry
- ?
dont be happy. worry
- ?