I don't think the details would vary so much (beyond setting eps). The
point really is that people who want to compare floating point numbers
will (if the read documentation) be put on notice that using equal() or
if a=b ... is NOT usually what you want in a program. Some people
offer ideas like "fuzzy" comparison as in Mathematica. But that is
usually not the right thing, and is in some cases very bad. So
providing relative and absolute errors is a kind of pre-emptive strike
against bad practice.
So I think we can "help the others."
Perhaps a chapter on numerical analysis in a context where you can do
exact arithmetic and arbitrary precision floats, as well as the
commonplace machine floats. There are many books on numerical analysis,
but they almost uniformly deal with the last case.
There's some documentation now on arb. prec. floats (e.g. MPFR). I don't
know what to say about exacts arithmetic except that in some sense
obviates the need for numerical analysis if you can avoid inefficiencies.
RJF
Robert Dodier wrote:
> On 4/13/07, Richard Fateman <fateman at cs.berkeley.edu> wrote:
>
>> Maybe we can promote
>>
>> RelativeErrorBound(a,b,eps):= if equal(a,b) then true else
>> is(abs((a-b)/max(a,b))< eps);
>> AbsoluteErrorBound(a,b,eps):= is (abs(a-b)<eps);
>>
>> Or some such constructions.
>
>
> I dunno. The details of such constructs would depend pretty
> strongly on what the user wants to achieve. Users who know
> what they want can make such things on their own, and I doubt
> that we can help the others. I'm inclined to steer away from
> stuff like the above.
>
> Robert