[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: numerical conditioning MAGNITUDE and /

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.



 | From: William D Clinger <will@xxxxxxxxxxx>
 | Date: Wed, 21 Jun 2006 13:42:08 -0400
 | 
 | Aubrey Jaffer wrote:
 | > The correct versions are unlikely to be much slower than naive
 | > ones; correct-/ is perhaps faster.  So the arguments for
 | > implementing these procedures incorrectly are weak.
 | 
 | I haven't heard any arguments at all for implementing
 | those procedures incorrectly.

I got ahead of myself.  (where is that strawman!)

 | On the other hand, it often happens that people fail
 | to distinguish between arguments for incorrectness
 | and arguments against attempting to require correctness.
 | 
 | We often see this in the political and legal arenas.
 | If you oppose a constitutional amendment to make
 | flag-burning a capital offense, someone will say you
 | want people to burn flags.

Requiring MAGNITUDE and / to work over their full ranges is good
because it provides more portability between implementations.

Objections I can think of are:

 * the full-range implementation might run more slowly;

 * implementations should be free to restrict the range of arithmetic
   functions; and

 * that MAGNITUDE and / should work over their full ranges is too
   obvious to state in a specification.

How would such a constraint be expressed?  The tangent function proved
a counterexample to general statements about the output range of
functions.  But specifics seem workable:

  The procedure MAGNITUDE returns a finite real nonnegative number for
  every argument whose (mathematical) magnitude is less than the
  most-positive-finite-flonum in the implementation.

  The procedure / applied to z1 and z2 returns a finite number when
  (/ (magnitude z1) (magnitude z2)) is less than the
  most-positive-finite-flonum in the implementation.

Both of these constraints are compatible with both polar and
rectangular representations of complex numbers.