Re: guile & r5rs

[hjstein@bfr.co.il (Harvey J. Stein)]

Jim Blandy <jimb@red-bean.com> writes:

 > First off, let me make it clear that 1) I agree with you that it's
 > undesirable behavior, and 2) I've thought of a way to fix it that I
 > really like, so I will do that.
 > 
 > So now I can split hairs without people thinking I'm a jerk.  :)
 > 
 > I think it would be a mistake for R5RS to dictate the precision with
 > which inexact conversions like the ones we're discussing take place.
 > When looking at these problems, I just barely managed to come up with
 > solutions, using the frayed edges of floating-point support.  I can
 > imagine some cases where this simply won't be possible.

It doesn't dictate precision.  It just says that when functions
produce inexacts, they should be "as precise as practical".  

 > For example, both of the solutions I described involve doing the
 > computation in bignums, and then converting to double at the very end.
 > There may not be any other way to win.  I'm simply not going to bother
 > with that for the complex trig functions.  And I'll bet nobody else
 > has, either.

Will you accept patches for it?

 > guile> (sin (expt 10 500))
 > +#.#
 > 
 > I think this is definitely, and deliberately, conforming behavior.

There's not much you can do with trig fcns on bignums.  For that
matter, there's not much you can do with trig fcns on huge doubles.
Once the number is bigger than about 10^17, the lack of precision
spans the periodicity of sin, so even if your sin fcn is completely
accurate, you're still effectively computing random numbers.

However, all numerical fcns are supposed to produce either exact or
inexact numbers or signal an exception.  Since +#.# is neither exact
nor inexact, I wouldn't call this conforming.

On the other hand, there is talk in R5RS of using the underlying IEEE
float code for inexacts, so it's not clear exactly where they stand on
this.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il