Prev: how to spawn and expect multiple processes "in parallel"
Next: single quote problem
From: Donald Arseneau on 9 Sep 2009 20:25
On Sep 9, 5:58 am, Kevin Kenny <kenn...(a)acm.org> wrote:
> Donald Arseneau wrote:
> > I will join in encouraging fuzzy comparisons for floating point numbers,
> > but am still disappointed that hypot is inexact. (Knowing the floating-
> > point hardware in use would clarify the deficiency... most fp processors
> > today carry extra precision to eliminate round-off error in the final
> > answer.)
>
> Reiterating what I've said before:
>
> The hardware is any x86. The library is MS Visual C++ runtime,

Then the fp hardware uses 80 bits precision internally, so the RTL
has
less excuse for the imprecise answer with 64 bits.

> As I said before, hypot(a,b) isn't a simple sqrt(a*a+b*b)

Yes, I know. Yet even the naive implementation should give
an exact answer for 20,99 if it is using extra precision
internally.

And how am I getting sucked onto the other side? I just dropped in
to dispute the implication that 101 was not an exact number in fp
representation.

> is less so. On the other hand, the cost to the maintainers of
> answering the ignorant postings in this thread is beginning to
> approach the amortized cost of maintaining our own hypot() in
> perpetuity.)

Why the fuss about last-bit errors? Certainly this example isn't
bad enough for Tcl to carry its own reimplementation! People need
to have the habit of using fuzzy comparisons for equality as long
as there is some source of round-off errors, and there always will
be.

Donald Arseneau
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: how to spawn and expect multiple processes "in parallel"
Next: single quote problem