Re: ratio implementation

[Marius Vollmer]

Bill Schottstaedt <address@hidden> writes:

>  > With your new files, I now get
>  >  guile> (inexact->exact 123456789123456789.0)
>  >  0
>
> I noticed this, but wasn't sure how to proceed;
> in the previous guile, you'd get (in a sense) equally
> bogus results:
>
> guile> (inexact->exact 17452826108659293487.0)
> 17452826108659294208

Hmm, I'd say that this is not nearly as bogus.  It is not very
accurate (since doubles do not have that much precision), but much
better than zero.  (Did I use 'accurate' and 'precise' correctly? :)

> I wasn't even sure whether you wanted inexact->exact to
> be changed -- I left the old code in place.

Yes, it needs to be changed.  People who have assumed that
inexact->exact always returns an integer need to think again (I'm
afraid I'm one of them...).

> I wrote a gmp version of the continued fraction code about 10 years
> ago -- I think I can still find it.

Hmm, what about a SCM version of the code?  I'm about to write such a
thing, but I first needed a proper scm_floor...

>  >  guile> (define pi (* 2 (acos 0)))
>  >  guile> (- (inexact->exact pi) pi)
>  >  3.31628058347633e-10
>  > Shouldn't we be able to do better than this?
>
> I think so; but in the current version, I'm setting the
> minimum error to 1/INT_MAX, which looks like it's in the
> ballpark of e-10.

The SCM version of rationalize can work to arbitrary error margins
(hopefully), by using generic SCM arithmetic instead of the longs and
doubles that your version uses.  That will make rationalize a bit
slower, but hey.