Division by zero: float vs. int

[Joseph Daniel Zukiger]

Joseph Daniel Zukiger coughed up:

Go try it and report back to us the compilation error you get. Double is
final.

Okay, wrap the stupid class. If you need it that bad, make it. If you
don't need it that bad, why the complaining?

 

[Joseph Daniel Zukiger]

Joseph Daniel Zukiger coughed up:

So no. It's final.

Nothing's final if you're willing to do a little drudge work. Wrap the class.

 

[Joseph Daniel Zukiger]

Actually, Double.equals() treats *all* NaNs as equal,
even if they have different bit patterns. The method is
defined in terms of Double.doubleToLongBits(), which yields
the "canonical" form 0x7ff8000000000000L for every NaN, no
matter what its actual bit pattern is.

There's another method, Double.doubleToRawLongBits(),
if you actually need to discriminate the bit patterns of
different NaNs -- but Double.equals() doesn't use it.

No kidding. I'm shocked. Okay, I take it back. It's easier than I
thought. If somebody wants the NaNs to be equal, they don't even have
to use isNaN() in a little compound conditional or wrap classes to do
artificial subclasses. They can just use the equals method.

Seems counter-intuitive to me, but what the hey. Depending on bit
patterns in NaNs is even more bizzare than wanting NaN to == NaN.

JouDanDattaKa

 

[Thomas G. Marshall]

Joseph Daniel Zukiger coughed up:

"Thomas G. Marshall"


Double, maybe?

Try it. From the 1.5 source:

public *final* class Double extends Number implements
Comparable<Double> {

 

[Thomas G. Marshall]

Joseph Daniel Zukiger coughed up:

"Thomas G. Marshall"


Okay, wrap the stupid class. If you need it that bad, make it. If you
don't need it that bad, why the complaining?

You're wrong on so many levels here.

First, I /don't/ need it that bad, never said or implied that. I was
pointing out that your suggestion doesn't work.

Secondly, I'm not complaining. We're /discussing/, and I have a (not very
strong) opinion on this, and about the primitive floating points.

Third, (from the API docs) for Double:

If d1 and d2 both represent Double.NaN, then the
equals method returns true, even though
Double.NaN==Double.NaN has the value false.

So the equals method /already/ does what you were suggesting.

 

[Thomas G. Marshall]

Joseph Daniel Zukiger coughed up:

"Thomas G. Marshall"


Nothing's final if you're willing to do a little drudge work. Wrap
the class.

(Double).equals() already works. Let's stop this---I don't want us moving
into circles of already (usually) understood behavior.

 

[Joseph Daniel Zukiger]

Joseph Daniel Zukiger coughed up:

(Double).equals() already works. Let's stop this---I don't want us moving
into circles of already (usually) understood behavior.

Oh, come on. Moving in circles is soooo much fun!

Just kidding.

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?

I mean, your argument has enlightened me on one little dark corner I'm
not going to like about Java (more of the implications of envelope
classes for primitive types being final), but was that your purpose?

JouDanDeshita

 

[Thomas G. Marshall]

Joseph Daniel Zukiger coughed up:

"Thomas G. Marshall"

Joseph Daniel Zukiger coughed up:

....[rip]...

(Double).equals() already works. Let's stop this---I don't want us
moving into circles of already (usually) understood behavior.

Oh, come on. Moving in circles is soooo much fun!

Just kidding.

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

That the .equals() method happens to get that right, is a side issue.

In light of the wars I'm willing to fight to the death, this is certainly
not one of them.


....[rip]...

 

[Tony Morris]

And, lest there be any confusion, the Java specs mandate the observed

behavior, regardless of what the underlying hardware may or may not do.

John Bollinger
(e-mail address removed)

And even less confusion, IEEE754 mandates this behaviour.
Java mandates that floating-point types behave as per IEEE754.

 

[Joseph Daniel Zukiger]

Joseph Daniel Zukiger coughed up:

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.

That the .equals() method happens to get that right, is a side issue.

I'm not sure the equals() method "gets it right"., but, yes, it's a
side issue.

In light of the wars I'm willing to fight to the death, this is certainly
not one of them.

Perhaps the reason it doesn't matter that much to you is that you
don't work with NaNs that much?

JouDanJaNehYa

 

[Thomas G. Marshall]

Joseph Daniel Zukiger coughed up:

"Thomas G. Marshall"


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.

Again, this argument has already been made by me and another upthread.
We're going in circles.

I really don't care much about this topic. See ya.


....[rip]...



--
Iamamanofconstantsorrow,I'veseentroubleallmydays.Ibidfarewelltoold
Kentucky,TheplacewhereIwasbornandraised.ForsixlongyearsI'vebeenin
trouble,NopleasureshereonearthIfound.ForinthisworldI'mboundtoramble,
Ihavenofriendstohelpmenow....MaybeyourfriendsthinkI'mjustastrangerMyface,
you'llneverseenomore.ButthereisonepromisethatisgivenI'llmeetyouonGod's
goldenshore.

 

[Joseph Daniel Zukiger]

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]

Joseph Daniel Zukiger coughed up:

"Thomas G. Marshall"

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?

I told you already that I don't care much about this.

But you've made your point clearly, and I accept it.

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?

 

[Tor Iver Wilhelmsen]

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]

Tor Iver Wilhelmsen coughed up:

"Thomas G. Marshall"


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>

 

[Tor Iver Wilhelmsen]

"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]

Tor Iver Wilhelmsen coughed up:

"Thomas G. Marshall"


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
api's, and (again), don't really care that much about this issue at all.

 

[Joseph Daniel Zukiger]

Joseph Daniel Zukiger coughed up:

"Thomas G. Marshall"

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?

I told you already that I don't care much about this.

But you've made your point clearly, and I accept it.

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