Velocity Reviews > Java > Division by zero: float vs. int

# Division by zero: float vs. int

Thomas G. Marshall
Guest
Posts: n/a

 10-13-2004
Joseph Daniel Zukiger coughed up:
> "Thomas G. Marshall"
> <(E-Mail Removed). com> wrote in
>> Joseph Daniel Zukiger coughed up:
>>> ...
>>> But I'm still wondering, if you knew the functionality was
>>> available, why argue in favor of making a floating point primitive
>>> do non-primitive things?

>>
>> It /should/ be a "primitive thing" IMHO.
>>
>> The argument I'm making is that the floating point primitive
>> operations should hold
>>
>> NaN == NaN, for all values NaN

>
> Well, let me see. I have a rocket for launching satellites, and a
> routine that calculates my trajectory involving a string of
> calculations in which the lengths of two hypotenii (hypotenuses?) are
> calculated and compared. The programmer, of course, is checking the
> sums of two sides for out-of-bounds conditions, right?
>
> if ( Math.sqrt( displacement1 ) != Math.sqrt( displacement2 ) )
> Rocket.courseChange( displacement1 - displacement2 );
>
> (Way over simplified, and someone will complain about the brackets not
> being there.)
>
> Which approach is going to be more likely to tell me on the test rig
> that something is amiss when displacement1 and displacement2 are both
> Double.POSITIVE_INFINITY?
>
> Of course it should never happen.

"it should never happen".

In both of our approaches, if NaN is possible, then I would much prefer my
solution.

Why? Because in your solution, if it mattered at all, you would /still/
need to check *which* of the two displacements gacked. It depends upon the
logic you need, obviously.

For example, I might *require* knowing that both methods produce NaN and are
therefore both failing.

We're going in circles.

....[rip]...

--
Iamamanofconstantsorrow,I'veseentroubleallmydays.I bidfarewelltoold
Kentucky,TheplacewhereIwasbornandraised.Forsixlong yearsI'vebeenin
trouble,NopleasureshereonearthIfound.Forinthisworl dI'mboundtoramble,
Ihavenofriendstohelpmenow....Maybeyourfriendsthink I'mjustastrangerMyface,
you'llneverseenomore.Butthereisonepromisethatisgiv enI'llmeetyouonGod's
goldenshore.

Joseph Daniel Zukiger
Guest
Posts: n/a

 10-15-2004
"Thomas G. Marshall" <(E-Mail Removed). com> wrote in message news:<EZ9bd.14\$Q%6.2@trndny03>...
> Joseph Daniel Zukiger coughed up:
> > [a bunch of stuff about wishing that NaN == NaN in Java,
> > for all values NaN]

Okay, let me ask. Do you really want Java to change the behavior of
Doubles to match your style and break with the IEEE floating point
standard on which it bases the behavior of Double calculations (and
the mathematical theory on which that standard was based)? Or are you
just bellyaching?

If you are just bellyaching, I'll offer you this, instead: Rather than
break with the standard, I'd wish for an easily extend-able version of
the Double class, separate, of course, from the wrapper class, to keep
from mucking with the security assumptions about primitives.

JouDanZuki

Thomas G. Marshall
Guest
Posts: n/a

 10-15-2004
Joseph Daniel Zukiger coughed up:
> "Thomas G. Marshall"
> <(E-Mail Removed). com> wrote in
> message news:<EZ9bd.14\$Q%6.2@trndny03>...
>> Joseph Daniel Zukiger coughed up:
>>> [a bunch of stuff about wishing that NaN == NaN in Java,
>>> for all values NaN]

>
> Okay, let me ask. Do you really want Java to change the behavior of
> Doubles to match your style and break with the IEEE floating point
> standard on which it bases the behavior of Double calculations (and
> the mathematical theory on which that standard was based)? Or are you
> just bellyaching?

> If you are just bellyaching, I'll offer you this, instead: Rather than
> break with the standard, I'd wish for an easily extend-able version of
> the Double class, separate, of course, from the wrapper class, to keep
> from mucking with the security assumptions about primitives.

So you are saying then that it was a mistake to have Double.equals() hold
NaN's equal to each other?

>
> JouDanZuki

--
Forgetthesong,I'dratherhavethefrontallobotomy...

Tor Iver Wilhelmsen
Guest
Posts: n/a

 10-15-2004
"Thomas G. Marshall" <(E-Mail Removed). com> writes:

> So you are saying then that it was a mistake to have Double.equals() hold
> NaN's equal to each other?

No, that's not what he's saying. equals() is not about mathematical
equivalence.

Thomas G. Marshall
Guest
Posts: n/a

 10-16-2004
Tor Iver Wilhelmsen coughed up:
> "Thomas G. Marshall"
> <(E-Mail Removed). com> writes:
>
>> So you are saying then that it was a mistake to have Double.equals()
>> hold NaN's equal to each other?

>
> No, that's not what he's saying. equals() is not about mathematical
> equivalence.

No? For the Double, or any other arithmetic class it had /better/ be.

"equals()" is about whatever version of equivalence the author intended it
to be, mathematical or otherwise.

Here's the comment for (Double).equals(): I've marked the equivalence rule
with its exceptions.

<yank>

Compares this object against the specified object. The result is true if and
only if the argument is not null and is a Double object that represents a
double that has the same value as the double represented by this object. For
this purpose, two double values are considered to be the same if and only if
the method doubleToLongBits(double) returns the identical long value when
applied to each.
Note that in most cases, for two instances of class Double, d1 and d2, the
value of d1.equals(d2) is true if and only if
* d1.doubleValue() == d2.doubleValue() *

also has the value true. However, there are *two exceptions* :
If d1 and d2 both represent Double.NaN, then the equals method returns true,
even though Double.NaN==Double.NaN has the value false.
If d1 represents +0.0 while d2 represents -0.0, or vice versa, the equal
test has the value false, even though +0.0==-0.0 has the value true.

</yank>

--
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

Tor Iver Wilhelmsen
Guest
Posts: n/a

 10-16-2004
"Thomas G. Marshall" <(E-Mail Removed). com> writes:

> "equals()" is about whatever version of equivalence the author
> intended it to be, mathematical or otherwise.

No, it is about conforming to the "contract" specified by
Object.equals(). And the docs for it states:

"It is reflexive: for any non-null reference value x, x.equals(x)
should return true."

If Java had support for pre- and postconditions, this would be easier
to enforce. As it stands, only the Javadocs indicate the contract.

So unless you want to claim that new Double(Double.NaN) should be
treated like null, they will be equal.

Thomas G. Marshall
Guest
Posts: n/a

 10-16-2004
Tor Iver Wilhelmsen coughed up:
> "Thomas G. Marshall"
> <(E-Mail Removed). com> writes:
>
>> "equals()" is about whatever version of equivalence the author
>> intended it to be, mathematical or otherwise.

>
> No, it is about conforming to the "contract" specified by
> Object.equals().

That's correct. And the "contract" /is/ the verion of mathematical
equivalence set in place by sun. There are null issues to take into account
of course, since equals() is passed, after all, an object.

> And the docs for it states:
>
> "It is reflexive: for any non-null reference value x, x.equals(x)
> should return true."
>
> If Java had support for pre- and postconditions, this would be easier
> to enforce. As it stands, only the Javadocs indicate the contract.
>
> So unless you want to claim that new Double(Double.NaN) should be
> treated like null, they will be equal.

I would never make that claim. You have an interesting take on this, but
you've over complicated this issue enormously.

With regard to primitive floating point types, NaN /does not equal/ NaN.

With regard to the java's notion of object representations of those
primitive types, NaN /does equal/ NaN.

I happen to agree with the .equals() contract set in place in the Java

--
"His name was Robert Paulson. His name was Robert Paulson. His name was
Robert Paulson..."

Joseph Daniel Zukiger
Guest
Posts: n/a

 10-19-2004
"Thomas G. Marshall" <(E-Mail Removed). com> wrote in message news:<LSQbd.9\$TU5.4@trndny06>...
> Joseph Daniel Zukiger coughed up:
> > "Thomas G. Marshall"
> > <(E-Mail Removed). com> wrote in
> > message news:<EZ9bd.14\$Q%6.2@trndny03>...
> >> Joseph Daniel Zukiger coughed up:
> >>> [a bunch of stuff about wishing that NaN == NaN in Java,
> >>> for all values NaN]

> >
> > Okay, let me ask. Do you really want Java to change the behavior of
> > Doubles to match your style and break with the IEEE floating point
> > standard on which it bases the behavior of Double calculations (and
> > the mathematical theory on which that standard was based)? Or are you
> > just bellyaching?

>
>
>
>
> > If you are just bellyaching, I'll offer you this, instead: Rather than
> > break with the standard, I'd wish for an easily extend-able version of
> > the Double class, separate, of course, from the wrapper class, to keep
> > from mucking with the security assumptions about primitives.

>
> So you are saying then that it was a mistake to have Double.equals() hold
> NaN's equal to each other?

My gut instinct would say, don't do that! Without thinking too deeply,
I'd have expected (drawing a corrolary from the comparison of objects
in general and Strings in particular) the == comparison to do a
bit-by-bit comparison and the equals() method to do a proper IEEE spec
conformant comparison.

But gut instincts are known to miss a point on occasion.

I don't know what their reasoning was. It was definitely one of the
paths they could have taken, and a path that would be useful in some
contexts. Perhaps they took this path to postpone the need for
extending the wrapper classes for a while. (I'm thinking Java 5
actually addresses that need, to an extent.)