Re: Quirky behavior (added PS)

by Michael Calkins (Login MCalkins)
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)

----

By adding:
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   

Return to Index

Response TitleAuthor and Date
I see what you meanlawgin on Feb 19
 *I started adding a PS to my earlier post before I saw your response.Michael Calkins on Feb 19
Comment on Michael's responseMoneo on Feb 19
 * :-P :-)Michael Calkins on Feb 19
 I second the motion.Solitaire on Feb 20
  Re: I second the motion.Michael Calkins on Feb 22
   Regarding that specific topic...ChronoKitsune on Feb 22
Thanks for clarifyinglawgin on Feb 20
 Re: Thanks for clarifyingMichael Calkins on Feb 22

 Copyright © 1999-2014 Network54. All rights reserved.   Terms of Use   Privacy Statement