| Date: Tue, 16 Aug 2005 20:06:43 -0700 (PDT)
 | From: bear <xxxxxx@sonic.net>
 |
 | 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
performed.

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

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

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

Yes, I think inexactness should be contagious without exception.