TURBO anomaly with mixed FP and INT expression...

[martyn_hill]

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?

[martyn_hill]

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...

[tofro]

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

[martyn_hill]

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

[stevepoole]

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.

[pjw]

<>

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

<>

I was going to suggest the following MODification which is slightly faster (But DIV only works on long ints in SBASIC, IIRC):

Code: Select all

120 DEFine FuNction ModL(ms, md)
130 RETurn ms - (ms DIV md) * md
140 END DEFine
150 :

But on checking whether the two functions returned identical results, I came across the following anomaly:

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?

[stevepoole]

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.

[pjw]

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)

[tofro]

Its obvious whats going on: DIV accepts long word parameters, but only returns a signed (short) word result, same as an SBASIC integer%.

That is maybe not the whole of the problem - for some arguments (like $80000 DIV 2) we get correct (long integer) results.

Tobias

[pjw]

That is maybe not the whole of the problem - for some arguments (like $80000 DIV 2) we get correct (long integer) results.

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..