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

Re: Wrapping up SRFI-70

 | Date: Tue, 16 Aug 2005 20:06:43 -0700 (PDT)
 | From: bear <bear@xxxxxxxxx>
 | On Sun, 14 Aug 2005, Aubrey Jaffer wrote:
 | > | It allows people to avoid deeply nested checks for zero,
 | > | instead testing whenever they like whether the most recent
 | > | iteration of their algorithm has produced the error object.
 | > | You can test for it and explicitly throw an exception if that's
 | > | how you want to handle it, or you can make a substitution or
 | > | correction explicitly and carry on.
 | > Infinities do all that, and keep track of the sign of overflows
 | > as well.
 | Yes.  It keeps track of the sign, even in cases where the sign
 | is ambiguous or undefined. I think this is a problem.
 | When something is divided by zero, pretending that the result
 | has any particular sign at all is misleading.  This is the
 | most common operation that results in an infinity, but it is
 | an infinity, and not an overflow;  it is the result of a
 | mathematically poorly defined operation. For example
 | (/ 32 (- 7.1 (+ 4.2 2.9)))
 | if performed using floating point arithmetic, is an overflow,
 | but has positive or negative sign depending solely on rounding
 | error.

This can be the case for any function having a singularity:

(tan 3.141592653589793)  ==>  -122.46063538223772e-18
(tan 3.141592653589794)  ==>  765.7177843178875e-18

Functions magnifying errors near singularities is one of the quirks to
deal with when computing with flonums.

 | If performed using exact arithmetic, or arithmetic in
 | BCD where no rounding is required, it is a division by a true
 | zero and the result is properly an unsigned infinity or NaN.
 | IEEE 754 may recommend a sign, but if it does, then it is
 | based on the representation, and not on any underlying
 | mathematical reality.

We can reasonably talk about mathematics with regard to the ring of
exact integers or the field of exact rationals; but flonums correspond
to no mathematical formalism that I know of.

 | An actual overflow, such as (* 2 MAXFLONUM), has an unambiguous
 | sign, but is not actually an infinity; it is merely a number
 | too large to represent in our current encoding scheme.

(* 2.0 MAXFLONUM) returns an infinity by the definition in SRFI-70:

  `+inf.0' represents real numbers greater than can be encoded by finite
  inexacts in the implementation (> 179.76931348623157e306 for IEEE-754
  64-bit flonums). `-inf.0' represents numbers less than can be encoded
  by finite inexacts in the implementation (< -179.76931348623157e306
  for IEEE-754 64-bit flonums).

 | Since
 | this isn't actually an infinity, it is quite right to state
 | that multiplying such an object by an exact zero may result
 | in an exact zero.  In fact, it *DOES* result, mathematically
 | speaking, in zero; 

Mathematically, multiplication exists only in combination with a
domain of eligible operands in a group, ring, or field.  An example of
a domain is the integers.  To talk of multiplying an integer by an
inexact number is mathematically meaningless.  One number must be
mapped into the other's domain and the appropriate operation

 | allowing implementations to return inexact
 | results in this case is just a bow to implementation
 | convenience and the desire for implementations that give
 | high speed on hardware that presents an imperfect model of
 | mathematics.

If you want to model mathematics, then use exact numbers.  SRFI-70:
"Each exact number corresponds to a single mathematical number."

 | Cases where you get an actual infinity that also has an
 | unambiguous sign are, IME, much rarer according to the laws
 | of actual mathematics than they are in software and hardware
 | approximations of mathematics.  This is a flaw in software,
 | to be tolerated perhaps in the name of convenience and speed
 | on real-life hardware and in the name of reducing the number
 | of cases that need to be handled, but not to be mandated or
 | required when someone may want to do the actual Right Thing
 | instead.

Exact number systems can do the "Right Thing".  An algorithmic
language should also provide the ability to calculate approximately.
That is the domain of inexact numbers in SRFI-70.

It is up to a language specification to decide how to perform
conversions between integers and flonums, and which numerical system
to perform mixed type/exactness operations in.

Pure inexact contagion is a simpler rule than the R5RS treatment.  It
also makes programs more portable because the exactness of results is
no longer dependent on numerical value or implementation choices.

 | > | The requirements you make of rounding for inexact numbers are
 | > | reasonable-sounding, but cannot be carried forward through any
 | > | level of abstraction.
 | >I have replaced that language with the weakest formulation yet:
 | >  In this SRFI, the definition of inexact numbers is strengthened by
 | >  their not being subject to the caution about "precision too large to
 | >  be represented in the implementation".  Only magnitudes too large
 | >  are cautioned:
 | >
 | >    For inexact numbers, it is the programmer's responsibility to
 | >    avoid using complex numbers with magnitude too large to be
 | >    represented in the implementation.
 | I empathize with your frustration, but: did you really mean
 | to use the word "complex" here, meaning numbers with real and
 | imaginary parts?  If so I don't think I see the logic or point
 | of this sentence.

The MAGNITUDE procedure is defined for complex numbers (which includes
the reals).  Talking about magnitude for other numbers is making

 | > | The SRFI also proposes to repeal an implementation's power to
 | > | return an exact number when it can prove that the result is
 | > | exactly known.  The specific example given in R5RS uses an exact
 | > | zero as an example.  This example is capital-T True, according to
 | > | laws much deeper than the surface consistency on which grounds
 | > | you object to it, because zero is a multiplicative identity
 | > | element.
 | >
 | > Exactness and inexactness are not defined mathematically by R5RS.
 | > You have objected to my attempts to define inexactness in terms
 | > of topology.  You can't have it both ways.  With as weak a
 | > formulation of inexactness as is given above, claims that exact 0
 | > trumps infinities can't appeal to mathematics.
 | You are correct that if the object being multiplied by an
 | exact zero may be an actual infinity then the result is
 | undefined.  Not only are we unable to give its exactness,
 | we are unable to give its value.  It is an unknown number.

With overflows mapping to infinities we can almost agree:

  (* 0 1.e400) ==> 0/0

 | However, multiplication by exact zero certainly does "trump"
 | mere overflows (signed numbers that are too large for the
 | current encoding to represent).  Under your current formulation,
 | are infinities distinguished from overflows?

No.  Overflows result in infinities, like in IEEE-754.

 | Do you think it would be a reasonable thing to do?

Distinguishing them in error messages might be useful, but I think the
distinction is not important enough to mandate it be testable from

 | Do you think it would be a reasonable thing to forbid anyone to do?

Yes, I think inexactness should be contagious without exception.