| Date: Mon, 27 Jun 2005 18:09:04 -0400
| From: Paul Schlie <xxxxxx@comcast.net>
|
| > From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
| > | Date: Mon, 27 Jun 2005 02:29:12 -0400
| > | From: Paul Schlie <xxxxxx@comcast.net>
| > | ...
| > | Thereby one could define that an unsigned 0 compares = to signed 0's to
| > | preserve existing code practices which typically compare a value against
| > | a sign-less 0. i.e.:
| > |
| > | (= 0 0.0 -0 -0.0) => #t
| > | (= 0 0.0 +0 +0.0) => #t
| > |
| > | (= -0 -0.0 +0 +0.0) => #f
| >
| > The `=' you propose is not transitive, which is a requirement of R5RS.
|
| - then alternatively one could define:
|
| (= -0 -0.0 0 0.0 +0 +0.0) => #t
|
| while retaining the remaining relationships, as it seems
| that = and < relationships need not be mutually exclusive?
R5RS says:
-- procedure: = z1 z2 z3 ...
-- procedure: < x1 x2 x3 ...
-- procedure: > x1 x2 x3 ...
-- procedure: <= x1 x2 x3 ...
-- procedure: >= x1 x2 x3 ...
These procedures return #t if their arguments are (respectively):
equal, monotonically increasing, monotonically decreasing,
monotonically nondecreasing, or monotonically nonincreasing.
These predicates are required to be transitive.
Equal cannot be monotonically increasing.
...
|
| > Mathematical division by 0 is undefined; if you return 1, then code
| > receiving that value can't detect that a boundary case occured.
|
| - yes, as above; and corrected below for unsigned 0's and 0.0's:
|
| 1/0 == inf :: 1/inf == 0 :: 0/0 == inf/inf == ~1
|
| where although inf equivalent in magnitude to +/-inf,
| it's sign is is undefined, thereby similar to nan, with
| the exception that if one were to introduce the convention
| that '~' may designate an ambiguous sign then the result of
| any division by inf or 0 may be considered to only yield
| an ambiguous sign although not necessarily magnitude, in
| in lieu of considering the value as undefined, i.e.
|
| inf => ~inf ; either +inf or -inf
| (* 3 (/ 0 0)) => ~3 ; either -3 or +3, thereby:
| (abs (* 3 (/ 0 0))) => +3
So ~ generates an algebraic field extension attaching the roots of
x^2=1. Note that ~ is not a real number because it doesn't fit in the
total ordering.
| (as this is how an implementation would behave if it considered
| +-inf and +-0 it's greatest and smallest represent-able but
| non-accumulating values; which effectively enables calculations
| to loose precision more gracefully, than falling of the edge of
| the value system potentially resulting in a run-time fault.)
Section 6.2.2 Exactness says:
If two implementations produce exact results for a computation that
did not involve inexact intermediate results, the two ultimate
results will be mathematically equivalent.
So loss of precision must not be platform dependent; thresholds of
"greatest and smallest represent-able" values can not affect
precision. Losing precision in calculation is an attribute of inexact
numbers.
| > ...
| > Nearly all of the SLIB occurences of EXPT have at least one
| > literal constant argument. In these cases, (expt 0 0) signaling
| > an error would catch coding errors. MODULAR:EXPT tests for a
| > zero base (and returns 0) before calling EXPT.
|
| - ??? The responsibility of an implementation's arithmetic
| implementation is to be generically as correct and consistent as
| reasonably possible. If slib chooses to optionally signal a
| runtime error for any arbitrary set of argument values, that's it's
| prerogative; but should have nothing to do with what the arithmetic
| value of (expt 0 0) or any other function is most consistently
| defined as being.
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.
| (all arithmetic functions should always return values).
6.2.3 Implementation restrictions:
If one of these procedures is unable to deliver an exact result when
given exact arguments, then it may either report a violation of an
implementation restriction or it may silently coerce its result to
an inexact number.
Always returning a value is a stronger requirement than R5RS or
SRFI-70, which gives the implementation a choice between returning 0/0
and signaling an error for (/ 0.0 0.0). Can you justify that mandate?
Do you consider QUOTIENT, MODULO, and REMAINDER arithmetic?
| > Grepping through a large body of Scheme code found no use of EXPT
| > where the two arguments are related.
|
| - which has nothing to do with anything, functions should be considered
| to be evaluated about static points:
|
| i.e. (f x y) == (f (+ x ~1/inf) (+ y ~1/inf))
The integer uses for EXPT should also be considered.
| there's nothing special about 0, as any function may impose
| relative trajectories for their arguments:
|
| (define (f x y) (/ x (* y y y (- y 1)))
|
| as such the only consistent thing that an implementation can
| warrant is that all primitive arithmetic expressions are
| evaluated equivalently about the static values passed to them,
| independently of whether or not the values passed to them have
| begun to loose precision due to the limited dynamic range of an
| implementation's number system. Thereby at least as a function's
| arguments begin to loose precision, the function correspondingly
| degrades in precision correspondingly and consistently, without
| after already yielding relatively inaccurate results decides it
| doesn't know the answer at all, or chooses to return a value
| which is inconsistent with it's previous results. (admittedly in
| my opinion)
SRFI-73 is about exact numbers. EXPT will only return exact numbers
for exact arguments. Loss of precision means inexact numbers.
| > (expt 0 0) ==> 1 is one of the possibilities for SRFI-70. But I
| > am leaning toward the "0/0 or signal an error" choice to catch
| > the rare coding error.
|
| - Again, in just my opinion, I'd rather a function return the most
| likely useful static value as a function of it's arguments, rather
| than it trying to pretend it knows something about the arguments
| passed to it and potentially generating a runtime fault.
|
| However it does seem potentially useful to be optionally warned
| whenever the precision of a primitive calculation drops below
| some minimal precision; i.e. it's likely much more useful to know
| when a floating point value is demoralized (as it means that the
| value now no longer has a represent-able reciprocal, or when an
| argument to an addition is less than the represented precision of
| the other operand, as these are the type of circumstances which
| result in inaccuracies, which by the time one may underflow to 0,
| or overflow to inf, and hope it gets trapped by some misguided
| function implementation which should have simply just returned
| the correct value based upon the arguments it was given and have
| the application check for what it believes is correct, it's
| already much too late, as regardless of whether some
| implementation's arithmetic system discontinuity was ticked, the
| results of a calculation are at best already suspect.
xxxxxx@sonic.net is also interested in specifying precision. See
<http://srfi.schemers.org/srfi-70/mail-archive/msg00088.html> about an
idea for latent precisions.
| > | Where I understand that all inf's are not strictly equivalent,
| > | but when expressed as inexact values it seems more ideal to
| > | consider +-inf.0 to be equivalent to the bounds of the inexact
| > | representation number system, thereby +-inf.0 are simply
| > | treated as the greatest, and +-0.0 the smallest representable
| > | inexact value;
| >
| > <http://srfi.schemers.org/srfi-70/srfi-70.html#6.2.2x> shows that
| > inexact real numbers correspond to intervals of the real number line.
| > Infinities corresponding to the remaining half-lines gives very clean
| > semantics for inexact real numbers. Infinitesimals (+-0.0) are a
| > solution in search of a problem.
|
| - 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:
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.
