TURBO anomaly with mixed FP and INT expression...

Anything QL Software or Programming Related.
martyn_hill
Gold Card
Posts: 381
Joined: Sat Oct 25, 2014 9:53 am

TURBO anomaly with mixed FP and INT expression...

Postby martyn_hill » Fri Oct 27, 2017 10:35 pm

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
Gold Card
Posts: 381
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO anomaly with mixed FP and INT expression...

Postby martyn_hill » Fri Oct 27, 2017 10:53 pm

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


User avatar
tofro
QL Wafer Drive
Posts: 1368
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TURBO anomaly with mixed FP and INT expression...

Postby tofro » Fri Oct 27, 2017 11:40 pm

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
Gold Card
Posts: 381
Joined: Sat Oct 25, 2014 9:53 am

Re: TURBO anomaly with mixed FP and INT expression...

Postby martyn_hill » Fri Oct 27, 2017 11:48 pm

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
Trump Card
Posts: 161
Joined: Mon Nov 24, 2014 2:03 pm

Re: TURBO anomaly with mixed FP and INT expression...

Postby stevepoole » Sat Oct 28, 2017 6:23 am

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.


User avatar
pjw
Gold Card
Posts: 375
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: TURBO anomaly with mixed FP and INT expression...

Postby pjw » Sat Oct 28, 2017 10:54 am

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

<>

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?


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
stevepoole
Trump Card
Posts: 161
Joined: Mon Nov 24, 2014 2:03 pm

Re: TURBO anomaly with mixed FP and INT expression...

Postby stevepoole » Sat Oct 28, 2017 2:11 pm

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.


User avatar
pjw
Gold Card
Posts: 375
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: TURBO anomaly with mixed FP and INT expression...

Postby pjw » Sat Oct 28, 2017 5:55 pm

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)


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
User avatar
tofro
QL Wafer Drive
Posts: 1368
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: TURBO anomaly with mixed FP and INT expression...

Postby tofro » Sat Oct 28, 2017 6:32 pm

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


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

Tobias


User avatar
pjw
Gold Card
Posts: 375
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: TURBO anomaly with mixed FP and INT expression...

Postby pjw » Sun Oct 29, 2017 12:32 am

tofro wrote: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..


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken

Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 3 guests