# Re: Quirky behavior (added PS)

Moderator

By the way, I got "not equal" with DEFDBL A-Z in qb64 also. Any discrepancy between qbasic and qb64 would indicate a bug in qb64. However, I think they both use the x87 FPU, so there shouldn't be any discrepancy.

--------

However, try this:

CLS
DEFDBL A-Z
a = 1: b = 9: c = 9: d = 5
e = (10 * a + b) / (10 * c + d)
PRINT e, a / d
f = a / d
PRINT
PRINT e = f
PRINT e = a / d
PRINT f = a / d
PRINT
PRINT e - (a / d)
PRINT
PRINT hexdouble(e), MKD\$(e)
PRINT hexdouble(a / d), MKD\$(a / d)
PRINT MKD\$(e) = MKD\$(a / d)

----

f = a / d
e = f is true.

qbasic 1.1 and qb64 0.951 produce the same output for that program.

Somehow it's not equal until it's assigned to a variable. Perhaps the math is being done in 80 bits, and the value doesn't become 64 bits until assigned to a DOUBLE? The x87 usually does floating point math in 80 bits, even if the variable is stored as 64 bits or 32 bits. That might account for why assigning it to a variable makes a difference.

If you are using qb64 0.942, and it produces different results, it's probably due to:

http://www.qb64.net/forum/index.php?topic=5123.0

which is fixed in qb64 0.951.

Regards,
Michael

P.S.

I've gotten used to copying the whole program out in QB64, and forgot to copy the function:

FUNCTION hexdouble\$ (d AS DOUBLE)
DIM t AS STRING
DIM t1 AS STRING * 16
DIM t2 AS INTEGER
DIM i AS INTEGER
t = MKD\$(d)
t1 = STRING\$(&H10, &H30)
FOR i = 1 TO 8
t2 = ASC(MID\$(t, i, 1))
MID\$(t1, i + i + (t2 >= &H10), 1 - (t2 >= &H10)) = HEX\$(t2)
NEXT
hexdouble = LCASE\$(t1)
END FUNCTION

I'm pretty sure what was happening is this:

e, a, and d are all 64 bit variables.

a / d causes the 64 bit variables to be loaded into the x87 FPU registers as 80 bit values. The division is performed. The result is, of course, 80 bits.

Then the 64 bit e is loaded as an 80 bit value to compare with the result of the division, which has not yet been rounded. Since e's value has been previously rounded, but the division result has not, the two are not equal.

When the division result is saved to f, it is rounded to a 64 bit variable. When e is compared with f, they are both converted from 64 bits back to 80 bits, and compared. Since they were both previously rounded to 64 bits, they are equal.

I think that's what's happening.

 This message has been edited by MCalkins on Feb 19, 2012 4:13 PM

Posted on Feb 19, 2012, 12:22 PM

Respond to this message