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

Re: comparison operators and *typos

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



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

 | Date: Tue, 28 Jun 2005 02:38:14 -0400
 | From: Paul Schlie <schlie@xxxxxxxxxxx>
 | 
 | > From: Aubrey Jaffer <agj@xxxxxxxxxxxx>
 | >  | Date: Mon, 27 Jun 2005 18:09:04 -0400
 | >  | From: Paul Schlie <schlie@xxxxxxxxxxx>
 | >  | ...
 | > ...
 | > 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.