John Cowan wrote > Alaric Snell-Pym scripsit: > > > I think it's bad to have multiple different things that (+ > > 99999999999999999999999 99999999999999999) could do. The result of > > that should either be 100000099999999999999998, or a condition being > > raised if the implementation can't stretch to that, in my view of the > > world. > > Okay, I certainly accept that -- as one position. > > > If I can accept approximate answers like 1.000001e+23, then I should > > tell the implementation this by explicitly asking for it with (f+ > > 99999999999999999999999 99999999999999999) or some such, I think. > > Note that the "approximate answer" is a consequence of Chicken's junk > C-library output routines. (Someone's working on replacing them, I > think.) The result really is exact, as you can see by evaluating (eqv? (+ > 99999999999999999999999 99999999999999999) 100000099999999999999998.0) > in plain Chicken.
> (inexact->exact 100000099999999999999998.0) 100000099999999999344640 The answer is not "exact" in the R5RS sense, nor in your sense. And Chicken's output routines give precisely the answer they're supposed to give, using the minimum number of decimal digits needed to preserve read-write invariance. Brad _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
