2013/12/24 Bradley Lucier lucier@math.purdue.edu
On 12/23/2013 07:44 PM, Mikael wrote:
Dear Marc or Brad,
First - Happy Holidays! :))
A Q:
#e0.3
3/10
(inexact->exact 0.3)
5404319552844595/18014398509481984
#e0.2
1/5
(inexact->exact 0.2)
3602879701896397/18014398509481984
Why the different results? Is there any way to get the #e behavior in a more effective way than (string-append "#e" (number->string n))?
I don't think so. inexact->exact works on numbers, the #e notation works on strings. The reader turns "0.3" by default into 5404319552844595/18014398509481984, the closest floating-point 64-bit binary number to 0.3.
Aha so it boils down to be two completely different underlying algorithms - interesting.
Wait, just curious, what is the actual FP 64bit representation of 0.3 and why does it turn out differently like this?
(and (exact->inexact 5404319552844595/18014398509481984) become .3 rather than 0.299[something] or 0.3000[something])
Am having a use case where exact arithmetics are wanted and the precision in decimals is fixed anyhow.
Perhaps using integers and using the lowest digits as decimals makes the most sense?
(as using FP:s seem to lead to weird complexities like this one, automatic disappearance of digits in some cases, and perhaps some potential formatting issue re automatic switching over to scientific notation)
Is a bit unfortunate as integers-as-decimal-numbers isn't too concise, needing to remember that 2345 really means 23.45 and so on.
I did exactly the trick of appending "#e" to the front of numerical
strings for a homework-on-the-web system that I wrote when the students expected to use exact decimal arithmetic.
Mhm.
See:
(- .3 3/10)
(= .3 3/10)
#f
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list