P Witte wrote: > Marcel Kilgus writes: > > <> > >> Still it's a bug and I'll try to investigate when I find the time. But >> > > n = -32768/1: n% = n > > throws an overflow error > > n = -32768: n% = n > > is ok > > Doing a > > PRINT FLOAT$(-32768/1) gives $0810 C000 0000 >
**** You've detected the cause of the bug! SMSQ/E has allowed a unnormalised value to get on the stack. This is a disaster. Indeed, it's a creeping disaster, as once one unnormal value gets onto the arithmetic stack, it might get progressively worse. It's clear now why the overflow error occurs. The value placed into "n" by "n=-32768/1" is unnormal (it isn't totally zero and the top two bits of the significand are the same). When this value is to be placed into "n%" by "n%=n", what happens is that the exponent is immediately checked. As soon as "0810" is seen, this /must/ overflow an integer, as it's greater that "080F". Where this bug can start creeping is ... what happens to "n=-32768/1:n2=n*n":PRINT n2"? I'd hazard a guess that one might get something like "$0821 2000 0000". To a degree, calculations on the stack /may/ normalise values, but there's no guarantee. Also, it will be no surprise that one of "m=32768:n=-m/1:PRINT m=n" or "m=-32768:n=m/1:PRINT m=n" is going to print zero. I rather suspect it will be the latter, as a result of bad tokenisation of the "-32768". **** > while > > PRINT FLOAT$(-32768 DIV 1) gives $080F 8000 0000 > > ... -- L _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
