(resending, sorry -- I forgot to change the Subject line)
A couple of years ago (Feb 2005!) we discussed changing ratepsilon to a
smaller value.
When Maxima converts a float to a rational, it finds the
smallest-denominator rational within ratepsilon of the float (using the
classic continued-fraction algorithm). With the current value, rat(
0.333333327)=rat(0.33333333)=rat(0.33333334)=1/3 and
The current value (2.0e-8) represents <3 units in the last place (ulps) in
the PDP-10 architecture. This value was selected so that a small amount of
rounding error would preserve the rational value.
Our current implementations all run (afaik) on IEEE double arithmetic, where
an ULP = 2.2e-16. I believe we should have a ratepsilon which is a small
number of ulps, as before, perhaps 10*ulp = 2.0e-15.
Changing this would change the behavior of rat and other functions depending
on it, e.g. cf(<float>). It would require updating 5 tests in the test
suite.
This was discussed two years ago (see emails below). CY and I agreed it was
a good idea and Fateman says he "won't argue"; there were no objections. Do
I hear any objections now?
If not, I will go ahead and change ratepsilon to 2.0e-15 and adjust the
relevant tests.
-s
-------------------------------------------------------------------------------------------------
On 2/22/05, Richard Fateman <fateman at cs.berkeley.edu> wrote:
>
> > --- Stavros Macrakis <macrakis at gmail.com> wrote:
> >>The conversion of floats to fractions is controlled by the global
> >>parameter ratepsilon. By default, this is 2.0e-8. I have argued for
> >>a long time that this should be much smaller, perhaps 1.0e-15 (5
> >>ulps).
> C Y wrote:
> > Are there any downsides anyone can see to this? If not, I move we
> > change it pronto.
> The downside to this is that the numerator and denominator sizes
> of the arithmetic results from adding/multiplying,
> etc the rational numbers grows, generally exponentially in the
> number of operations. If you set ratepsilon to a very small quantity
> then there is a danger that some computations will get slower, sooner.
>
> If ratepsilon is set to a small multiple of double-float-epsilon, I
> won't argue, but you asked... what was the downside.
>
> RJF
>