```Paul Duncan wrote:

> Neither 0/0 nor 0.0/0.0 are defined.  You can't test the equality of
> infinite values, and you can't test the equality of NaNs either.  That
> doesn't have anything to do with the underlying logic; that's basic
> mathematics.

They're very clearly defined, and they're defined differently.  0/0 is
defined, ispo facto, to be an error.  0.0/0.0 returns an Object of type
Float, who's value is "NaN".  You can even do operations with this:

1/(0.0/0.0)  => "NaN"

.... for as much use as it is.  Furthermore:

(1/0.0) + 1   => "Infinity"
(-1/0.0) * 100 => "-Infinity"
(-1/0.0) * (1/0.0) => "-Infinity"
(1/0.0) / (1/0.0) => "NaN"

The same isn't true of Integers, because while you can divide by 0 with
floats (and get an undefined number), you can't divide by zero with
Integers without getting an error.

> The implementation makes sense if you look at it from a differential
> calculus perspective.  The {+,-}Infinity definitions come from the limit
> of equations as they approach 1.0/0.0 and -1.0/0.0 over a continuous
> domain.  Limits only make sense over a continuous range (eg a continuous
> set of real numbers).  Calculating the limit of a series of natural
> numbers or integers doesn't make a whole lot of sense.

This is exactly what I'm talking about: this is an arbitrary distinction
imposed by the underlying processing mechanism.  The point I'm trying to
illustrate is the lack of transitive logic between equalities:

1 == 1.0
1/0 == 1/0  (in that they both throw exceptions)
1/0.0 == 1/0.0

but

0/0 != 0/0.0

I don't see how this can be rationalized except by an appeal to "that's the
way it has to be because of how computers work".

--
|..  I put the "fun" in "dysfunctional".
<|>
/|\
/|
|
```