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)
0.
 > (= .3 3/10)
#f

Brad
_______________________________________________
Gambit-list mailing list
Gambit-list@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list