Nitpick with FLOOR etc. Michael Sperber (07 Jul 2005 08:46 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (09 Jul 2005 00:50 UTC)
Re: Nitpick with FLOOR etc. Michael Sperber (11 Jul 2005 06:55 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (16 Jul 2005 02:01 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (16 Jul 2005 08:38 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (16 Jul 2005 17:42 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (16 Jul 2005 09:12 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (16 Jul 2005 18:19 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (17 Jul 2005 17:23 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (17 Jul 2005 17:35 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (17 Jul 2005 22:43 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 01:43 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 02:31 UTC)
Re: Nitpick with FLOOR etc. bear (18 Jul 2005 05:59 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (18 Jul 2005 18:57 UTC)
Re: Nitpick with FLOOR etc. bear (19 Jul 2005 01:35 UTC)
Re: Nitpick with FLOOR etc. Alan Watson (19 Jul 2005 20:30 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (21 Jul 2005 17:35 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (24 Jul 2005 23:15 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 03:24 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (18 Jul 2005 18:24 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 18:41 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (21 Jul 2005 23:36 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (22 Jul 2005 00:50 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (25 Jul 2005 00:54 UTC)
Re: Nitpick with FLOOR etc. bear (27 Jul 2005 15:56 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (01 Aug 2005 16:33 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (25 Jul 2005 01:16 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (25 Jul 2005 02:38 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (28 Jul 2005 01:11 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (28 Jul 2005 18:15 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (01 Aug 2005 16:59 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (02 Aug 2005 13:58 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (18 Jul 2005 17:39 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (18 Jul 2005 18:15 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (20 Jul 2005 19:24 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (20 Jul 2005 21:35 UTC)
Re: Nitpick with FLOOR etc. bear (20 Jul 2005 22:41 UTC)
Re: Nitpick with FLOOR etc. Paul Schlie (20 Jul 2005 22:47 UTC)
Re: Nitpick with FLOOR etc. Aubrey Jaffer (21 Jul 2005 01:31 UTC)

Re: Nitpick with FLOOR etc. bear 27 Jul 2005 15:55 UTC


On Sun, 24 Jul 2005, Aubrey Jaffer wrote:

> | Date: Thu, 21 Jul 2005 20:50:05 -0400
> | From: Paul Schlie <xxxxxx@comcast.net>
> |
> | 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 take that measure unless someone can provide an
> example from practice where the ranges being unequal caused bad
> software behavior.

The comment was made half in jest; but the observation is
that many of the inconsistencies of infinity mathematics
are predicated on the fact that inexact math invokes infinity
while exact math just goes to bigger exact numbers.

In practical terms, I think that "infinity" as it's being
discussed here is properly an error object rather than a
numeric value, and I would be satisfied with a scheme
where numeric operations returned an error object if asked
to do anything involving a range overflow, underflow, or
where an argument were an error object.  But naming an
error object "infinity" is misleading, since the value the
user sees may be nine or ninety operations further down
the pipeline after the "overflow" has been divided,
subtracted, inverted, etc.

> | - 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.

Agreed.  This produces truly execrable behavior and should not
be done.

> | 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.  What would (/ 0 0) do?  What would (/ 0.0) return (exact or
> inexact)?  (/ 0 0.0)?

I think that:
 (/ 0) => error-object  ;; this EO could be called infinity, I guess
 (* 0 error-object) => error-object  ;; but not this one.

This brings up an important distinction in "infinities;"
When you divide by exact zero you get an absolute infinity.
(which, perversely, is neither positive nor negative, because
exact zero isn't positive or negative.) Call this EO1.

When you divide 1 by (say) 5e-323, you get a different kind of
EO, which is "results too large to represent" but which
is often mistaken for an actual infinity.   Call this EO2.

The kick is that (* 0 EO1) => EO3  ;; EO3 is a NaN or something.
while (* 0 E02) => 0 .

Modeling this behavior in programming language mathematics is
not simple.

				Bear