eoyang@A.DARPA.MIL (12/28/89)
Hello all of you out there in explorer-land.
I was doing some Q/A on my system and tried this:
(setq number 1111.7)
And what did I get?
1111.7001
I tried this on 2 microexplorers. Can anyone duplicate this? Is there
another number that will exhibit the same bug/feature? Don't ask me why
I picked that number, I just did. Help!heger@ARIEL.UNM.EDU (A. Sharif Heger CHNE) (12/28/89)
Try 2223.4, 4446.8, and so on.
Rice@SUMEX-AIM.STANFORD.EDU (James Rice) (12/28/89)
>> Hello all of you out there in explorer-land. >> I was doing some Q/A on my system and tried this: >> (setq number 1111.7) >> And what did I get? >> 1111.7001 >> I tried this on 2 microexplorers. Can anyone >> duplicate this? Is there another number that will >> exhibit the same bug/feature? Don't ask me why I >> picked that number, I just did. Help! This is perfectly normal behaviour. What may be confusing you is that numbers like 1111.7 are REAL numbers in the real world but not on any machine (that I know of). They are not REAL numbers, they are FLOATING POINT, fixed precision numbers. Unlike BIGNUMs, which are big enough to represent the value needed with absolute precision, FLOATS are subject to all sorts of rounding errors on the last bit. Don't forget also that, on Explorers, numbers are represented in binary. Because there is not a perfect mapping between binary and base 10 representations you will likely see some strange effects too. I seem top recall that in Algol 68 it is, in fact, illegal to compare two floating point values (A68 wrongly calls them REALs) with the = operator, forcing you always to state the tolerance that you believe to be adequate to denote equality in your eyes. I have a lot of sympathy with this argument. It seems pretty bogus to me that (= 1 1.0). Rice. P.S. If you aren't satisfied by this then you can always force the FLOAT value to be represented as a double precision value: (print (setq number 1111.7D0)) 1111.7d0 ;;; not 1111.7001
acuff@SUMEX-AIM.STANFORD.EDU (Richard Acuff) (12/30/89)
-> P.S. If you aren't satisfied by this then you can always -> force the FLOAT value to be represented as a double -> precision value: -> (print (setq number 1111.7D0)) -> 1111.7d0 ;;; not 1111.7001 Or, of course, use 11117/10 (ie. a rational rather than a float).