> From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
>  | Date: Thu, 21 Jul 2005 20:50:05 -0400
>  | From: Paul Schlie <xxxxxx@comcast.net>
>  |
>  | After attempting to digest everything discusses, although realizing
>  | your desire to not require any corresponding impact to either rsrx
>  | or exact semantics; I don't believe it's reasonably possible, as it
>  | seems that the only way to achieve what you desire, and maintain
>  | reasonable consistency with mixed exact/inexact arithmetic would be
>  | to:
>  |
>  | - as suggested by "bear", define the requirement that exact and
>  | inexact value representations be constrained to the same value
>  | range.
>
> I am reluctant to add that requirement unless someone can provide an
> example from practice where the ranges being unequal caused bad
> software behavior.

- which is easy to construct, but as no such equivalence is presently
  required, all existing SW either accepts, detects and corrects, or
  is not aware of the potential consequence of the resulting potential
  comparison errors. (so an existing practical example is not likely).

>  | - define infinites and their reciprocals to abstractly commonly
>  | represent the greatest/smallest values at bounds of the
>  | representable numerical range,
>
> As I written previously, using the boundary for the nominal value is
> the worst choice from that neighborhood.  Doing so means that nearly
> every calculation which projects into #i+/0 is larger than the nominal
> value.

- yes, nearly all possible values.

>  | exclusive of 0 representing an absolute 0, who's reciprocal is
>  | itself 0.
>
> This would mean (* 0 (/ 0)) would no longer signal an error or return
> 0/0, thus failing to meet some of the original goals of SRFI-70.

- as below, as I don't believe it's a good idea to require exceptions
  where a default value may be reasonable, therefore basically proposed
  that function may optionally signal an exception for any circumstance
  considered sufficiently interesting, which may include 0/0 if desired.

> What would (/ 0.0) return (exact or inexact)?

- as I consider 0.0 :: +0.0, I'd say 1/0.0 :: +Inf.0 <inexact>

> What would (/ 0 0) do?

- as I believe a good default value as the average value of it's limit
  values, I'd say 0 and/or optionally signal an error if enabled to do so.
  (as I would tend to define 0 to be exclusive of both exact -0/1 +0/1,
   and inexact -0.0 and +0.0, thereby #e0 :: #i0 :: 0).

> How about (/ 0 0.0)?

- personally I'd say: (* 0 (/ 0.0)) :: (* 0 +Inf.0) => 0, if +Inf.0
  is defined to have a value defined as being = inexact boundary value,
  or 0.0 if defined to be the interval of all values beginning at it's
  boundary value and beyond.

>  | - thereby the range of all numerical transforms map to a
>  | correspondingly representable domain (although may optionally
>  | signal a run-time exception as may be desired in certain
>  | circumstances).
>
> This would have been nice, but the smallest (unnormalized) numbers in
> IEEE-754 are not symmetrical with the largest magnitude numbers:

- which would imply that unnormalized values would be invalid inexact
  values. (as only normalized floats would satisfy the symmetry specified)

> (/ 179.76931348623157e306) ==> 5.562684646268003e-309
> (/ 5.562684646268003e-309) ==> #i+/0
>
> There are unnormalized numbers down to 4.0e-324, all of whose
> reciprocals are #i+/0.
>
>  | Which overall seems to eliminate all the contentious issues, as
>  | long as one is willing to accept the consequences saturating
>  | arithmetic, in lieu of an typically arguably less useful more
>  | abstract treatment of infinites.
>  |
>  | Effectively resulting in:
>  |
>  |        .. -1.0 ..      |      .. +1.0 ..
>  |   -1/0 .. -1/1 .. -0/1 | +0/1 .. +1/1 .. +1/0
>  |   -------------------- 0 --------------------- (multiplicative inverse
> axis)
>  |   -0/1 .. -1/1 .. -1/0 | +1/0 .. +1/1 .. +0/1
>  |        .. -1.0 ..      |      .. +1.0 ..
>  |                        |
>  |             (additive inverse axis)
>
> How is this different from your "more abstract treatment of
> infinities"?

- only in as much as that all values beyond an implementation's infinite
  boundary are considered equivalent to the boundary value, as opposed to
  being the entire infinite interval beyond and inclusive of that boundary,
  thereby having no distinct value itself. (which I thought you desired?)
  [where if exact and inexact boundaries are equivalent, there's no
  technical necessity for an inexact infinity, as it will be by definition
  equivalent to it's exact counterpart]