coconut-palm-software.com— Much to my surprise yesterday, I discovered that Java 5 believes that 0 != 0 in certain situations. Try the following in Java 5.
Nov 13, 2006View in Crawl 4
It made it to the front page because some other ignorant person submitted it, then dozens and dozens of others dugg it.Personally, I found this thread informative, because I'm not a Java programmer, and knowing things like this interest me.
This is stupid. Equals() can implement any one of a number of equality tests (refer to the number of different equality tests in LISP, for example). Java can only implement one of the possible options and its the programmer's job to know which contract is being met and not to just assume.
According to my COBOL professor and a few others I have talked to, most financial code is still written in COBOL. Just thought you might want to know ;P
I don't claim to be an expert in Java, in fact I don't particularly care for it, but I'm going to put my 2 cents in anyways. Conceptually, zero is always equal to zero, whether it's an integer, a long, a float, or a double. Of course when dealing with floating point numbers you have to consider precision ( abs(number1 - number2) < some_acceptable_precision ) If we are testing for the equality of not only the number value, but also all of the object semantics, then I can see why it would return false, as in this case where 0 is an integer and therefore not an instance of Long. A method named "equals" in an integer class is a horrible horrible horrible name for a method comparing both object semantics and the value. Intuitively, the equals method should have IDENTICAL semantics to operator==. If you read the code to yourself, it makes perfect sense that x == 0 should be identical to x.equals(0), in fact it's commonplace in other languages (eg C++) to disregard the operator overload mechanism and use named functions such as this. When dealing with numbers (which are the epitome of value semantics), it should be smart enough to know that a number is a number, compare them for equality and return the result. If someone is crazy enough to want to compare semantics of the wrapper classes then they create their own "completelyUselessEquals" method. In my world, 0 == 0L == 0UL, and never ever ever ever do I want to compare anything but their values.This is a perfect example of introducing unnecessary complexity. It's even more laughable when you consider the fact that 98% of computers today are 32bit machines and there is no difference between a long and an int to begin with. Hell, even the 64bit platform is keeping 32bit integers, only pointers are being extended.
Just because it is in the docs doesn't mean it wasn't quick, and I said repeatedly that I did not think it was a bug.I dunno about you, but every .Equals definition I write starts withif (!(obj is TYPE)) return false; //I know, evil C# code :PThat is what the statement was based off of, and while they probably did put some thought forth into it, I wouldn't be surprised if version 1.0 of the method took the above approach, and then they discussed the methodology afterward.Although in theory they may have discussed the appropriate implementation before coding anything, in which case I would be wrong, but either way my comment was more a quick one as an introduction, not to be taken as the fundamental part of what I was trying to say.
richardiscoolNov 14, 2006
A consultants job is to promise the clients the impossible, then expect the programmers to accomplish it.
msgyrdNov 14, 2006
It made it to the front page because some other ignorant person submitted it, then dozens and dozens of others dugg it.Personally, I found this thread informative, because I'm not a Java programmer, and knowing things like this interest me.
kaffieneNov 14, 2006
This is stupid. Equals() can implement any one of a number of equality tests (refer to the number of different equality tests in LISP, for example). Java can only implement one of the possible options and its the programmer's job to know which contract is being met and not to just assume.
proglottisNov 14, 2006
sorry
pgouyNov 14, 2006
In Soviet Russia, Java owns YOU!
dycacianNov 14, 2006
According to my COBOL professor and a few others I have talked to, most financial code is still written in COBOL. Just thought you might want to know ;P
littlemantamuNov 14, 2006
You've shown that you know about as much about programming, and maybe less about numerical representation, as the author of the article. Try reading up on IEEE 754 (<a class="user" href="http://www.psc.edu/general/software/packages/ieee/ieee.html">http://www.psc.edu/general/software/packages/ieee/ieee.html</a> or <a class="user" href="http://en.wikipedia.org/wiki/IEEE_754).">http://en.wikipedia.org/wiki/IEEE_754).</a> Note that the standard specifically says there are two zeroes, +0 and -0. Again, it's a basic programming concept, the difference between floating point and integer.
zacmccormickNov 28, 2006
I don't claim to be an expert in Java, in fact I don't particularly care for it, but I'm going to put my 2 cents in anyways. Conceptually, zero is always equal to zero, whether it's an integer, a long, a float, or a double. Of course when dealing with floating point numbers you have to consider precision ( abs(number1 - number2) < some_acceptable_precision ) If we are testing for the equality of not only the number value, but also all of the object semantics, then I can see why it would return false, as in this case where 0 is an integer and therefore not an instance of Long. A method named "equals" in an integer class is a horrible horrible horrible name for a method comparing both object semantics and the value. Intuitively, the equals method should have IDENTICAL semantics to operator==. If you read the code to yourself, it makes perfect sense that x == 0 should be identical to x.equals(0), in fact it's commonplace in other languages (eg C++) to disregard the operator overload mechanism and use named functions such as this. When dealing with numbers (which are the epitome of value semantics), it should be smart enough to know that a number is a number, compare them for equality and return the result. If someone is crazy enough to want to compare semantics of the wrapper classes then they create their own "completelyUselessEquals" method. In my world, 0 == 0L == 0UL, and never ever ever ever do I want to compare anything but their values.This is a perfect example of introducing unnecessary complexity. It's even more laughable when you consider the fact that 98% of computers today are 32bit machines and there is no difference between a long and an int to begin with. Hell, even the 64bit platform is keeping 32bit integers, only pointers are being extended.
guvanteJun 10, 2008
Just because it is in the docs doesn't mean it wasn't quick, and I said repeatedly that I did not think it was a bug.I dunno about you, but every .Equals definition I write starts withif (!(obj is TYPE)) return false; //I know, evil C# code :PThat is what the statement was based off of, and while they probably did put some thought forth into it, I wouldn't be surprised if version 1.0 of the method took the above approach, and then they discussed the methodology afterward.Although in theory they may have discussed the appropriate implementation before coding anything, in which case I would be wrong, but either way my comment was more a quick one as an introduction, not to be taken as the fundamental part of what I was trying to say.