Re: ratio implementation

[Bill Schottstaedt]

> That is, instead of using "long", I'd say we simply use "SCM" and
> instead of "+", "==", etc, we use use "scm_sum", "scm_num_eq_p", etc.
> Also, instead of mallocing scm_t_ratio, we can use double cells, which
> should be more efficient.
>
> Any takers?

Looks straightforward, but I may not get around to it right away.
Should I wait for Dirk's type-related changes?  Also, I haven't
looked closely at double cells, though I assume (from a glance
at the scm_t_double stuff) that I can include my "reduce" flag
as well as the numerator and denominator.  The point being to
reduce calls on gcd as much as possible (this being Guile's integer
divide, there's some desire to keep it from crawling).  But, it's
an optional optimization.


> (Also I didn't really check whether your rationals behave like R5RS
> demands it.  Did you?  We should be sure to follow R5RS.)

Yes, I think it follows R5RS.  See test-ratios.scm for some tests.
I could make these fit into 'make check'.


> A ratio is exact, while a real is not.  Thus, I'd say that ratio? is
> not really necessary.  There should be no reason to add anything eyond
> R5RS for ratios.

Ok -- "exact?" used to return #f for 3/4 -- hence the confusion.


>> An alternative would be to make "rational?"  rational.
> That would violate R5RS, wouldn't it?

I don't think so.  You are allowed to make rational? be the same
as real?, but you can also distinguish them.  My druthers would
be for rational? to return #t for a ratio, #f for a float.
Why have it at all if it is just a synonym for "real?"?