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

Re: numerical conditioning MAGNITUDE and /



 | 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.