This thread arose on srfi-73@srfi.schemers.org, but wandered into
inexact infinities.

 | Date: Tue, 28 Jun 2005 02:38:14 -0400
 | From: Paul Schlie <xxxxxx@comcast.net>
 |
 | > From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
 | >  | Date: Mon, 27 Jun 2005 18:09:04 -0400
 | >  | From: Paul Schlie <xxxxxx@comcast.net>
 | >  | ...
 | > ...
 | > My point is that (expt 0 0) is unlikely to occur when EXPT is being
 | > used as a continuous function; its occurrences will be exponentiating
 | > integers.  In the integer context, arguments about limits of
 | > continuous functions are irrelevant.
 |
 | - Typically it seem more broadly accepted that (expt 0 0) == 1
 | particularly for integers,...

Hmm... "Concrete Mathematics" p.162 (R. Graham, D. Knuth,
O. Patashnik) argues that 0^0=1 for the sake of the binomial
theorem. I will change SRFI-70 to return 1 for 0^0.

 | ...
 | >  |
 | >  | - only if it's not considered important that inexact
 | >  | infinities have corresponding reciprocals;
 | >
 | > Inexact infinities have reciprocals: zero.  Their reciprocals are
 | > not unique, but that is already the case with IEEE-754
 | > floating-point representations:
 |
 | - yes, among other idiosyncrasies.
 |
 | >   179.76931348623151e306  ==> 179.76931348623151e306
 | >   179.76931348623157e306  ==> 179.76931348623157e306
 | >   (/ 179.76931348623151e306)  ==> 5.562684646268003e-309
 | >   (/ 179.76931348623157e306)  ==> 5.562684646268003e-309
 | >
 | >  | which seems clearly desirable as otherwise any expression
 | >  | which may overflow the dynamic range of the number system
 | >  | can't preserve the sign of it's corresponding infinitesimal
 | >  | value, which if not considered important, there's no reason to
 | >  | have signed infinities, either, etc. ?
 | >
 | > #i+1/0 is the half-line beyond the largest floating-point value.
 | > The projection of that interval through / is a small open
 | > interval bordering 0.0.  That interval overlaps the interval of
 | > floating-point numbers closer to 0.0 than to any other.  Thus the
 | > reciprocal of #i+1/0 is 0.0.
 |
 | - but the problem seems to be the reciprocal of #i-1/0?

#i-1/0 is the half-line beyond the most negative floating-point value.
The projection of that interval through / is a small open interval
bordering 0.0.  That interval overlaps the interval of floating-point
numbers closer to 0.0 than to any other.  Thus the reciprocal of
#i-1/0 is 0.0.

 |   And it's reciprocal?, which should be where one began?

In IEEE-754, the reciprocal of the reciprocal is not always equal to
the original:

  (/ 179.76931348623149e306)		==> 5.56268464626801e-309
  (/ (/ 179.76931348623149e306))	==> 179.76931348623143e306
  (/ 179.76931348623151e306)		==> 5.562684646268003e-309
  (/ (/ 179.76931348623151e306))	==> #i+1/0

This can be seen as the consequence of the inexact intervals projected
through functions not aligning with the inexact intervals on the real
line.

 |   (where it one introduces -0.0 then 0.0 is implied as being +0.0
 |   leaving one with ether a + or - 0, but nothing which is either?
 |   unless one introduces yet another 0, 0 (or ~0 hypothetically,
 |   which then implies ~inf)?

Zero is at the center of 0.0's neighborhood.  R5RS division by 0.0 is
an error; leaving latitude for SRFI-70's response.  If we make
(/ +1 0.0) ==> #i+1/0, then (/ -1 0.0) ==> #i-1/0.  This choice is
arbitrary; but the other way is confusing.

Most neighborhoods mapping through functions project onto adjacent
neighborhoods.  But / near 0 is not the only function which does not.
TAN near pi/2 is another example.