[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comparison operators and *typos
This thread arose on srfi-73@xxxxxxxxxxxxxxxxx, but wandered into
| 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
(/ 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
| (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.