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".
<|>   
/|\   
/|    
 |