Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: hashCode

Reply
Thread Tools

Re: hashCode

 
 
Lew
Guest
Posts: n/a
 
      08-13-2012
To: Arne Vajhj
From: "Lew" <lew@1:261/38.remove-nlb-this>

To: Arne Vajhoj
From: "Lew" <lew@1:261/38.remove-m2z-this>

To: Arne Vajhoj
From: Lew <(E-Mail Removed)>

On 08/10/2012 04:30 PM, Arne Vajh-,j wrote:
> On 8/10/2012 6:32 PM, Lew wrote:
>> bob smith wrote:
>>> Now, there are cases where you HAVE to override it, or your code is very
>>> broken.

>>
>> No.

>
>> As long as 'hashCode()' fulfills the contract, your code will work -
>> functionally. But a bad
>> 'hashCode()' could and likely will noticeably affect performance. There is
>> more to correctness
>> than mere functional conformance.

>
> If the code per specs is guaranteed to work then it is correct.
>
> Good (or just decent) performance is not necessary for code to
> be correct.
>
> At least not in the traditional programming terminology.
>
> In plain English maybe.


I see your point, but that is not to say that the specs exclude performance
considerations.

In the case of 'hashCode()', the Javadocs do say, "This method is supported for
the benefit of hash tables such as those provided by HashMap."
<http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()>

The key question here is how you define "benefit". I argue that a hash code
that is constant does not benefit, say, a 'HashMap' because one of our desired
uses is constant-order retrieval.

"This implementation provides constant-time performance for the basic
operations (get and put), assuming the hash function disperses the elements
properly among the buckets."
<http://docs.oracle.com/javase/7/docs/api/java/util/HashMap.html>

Each specification refers to the other. Ergo they are meant to be considered
together. Taken together, the documentation clearly specifies that "correct" or
"proper" includes performance considerations. Therefore, by what you say, the
simple "return 1;" is not correct.

It certainly would not be correct for the 'Object' implementation. "As much as
is reasonably practical, the hashCode method defined by class Object does
return distinct integers for distinct objects." [op. cit.]

As you say, Arne, "correct" means it follows the spec. The OP's suggested
implementation violates the spec on two fronts.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      08-13-2012
To: Lew
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
ove-nlb-this>

To: Lew
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
ove-m2z-this>

To: Lew
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <(E-Mail Removed)>

On 8/11/2012 7:24 PM, Lew wrote:
> On 08/10/2012 04:30 PM, Arne Vajh-,j wrote:
>> On 8/10/2012 6:32 PM, Lew wrote:
>>> bob smith wrote:
>>>> Now, there are cases where you HAVE to override it, or your code is
>>>> very
>>>> broken.
>>>
>>> No.

>>
>>> As long as 'hashCode()' fulfills the contract, your code will work -
>>> functionally. But a bad
>>> 'hashCode()' could and likely will noticeably affect performance.
>>> There is
>>> more to correctness
>>> than mere functional conformance.

>>
>> If the code per specs is guaranteed to work then it is correct.
>>
>> Good (or just decent) performance is not necessary for code to
>> be correct.
>>
>> At least not in the traditional programming terminology.
>>
>> In plain English maybe.

>
> I see your point, but that is not to say that the specs exclude
> performance considerations.
>
> In the case of 'hashCode()', the Javadocs do say, "This method is
> supported for the benefit of hash tables such as those provided by
> HashMap."
> <http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()>
>
> The key question here is how you define "benefit". I argue that a hash
> code that is constant does not benefit, say, a 'HashMap' because one of
> our desired uses is constant-order retrieval.


Object having the method defined to support effective hashing does not imply
that it has to it just means that the potential is there.

> "This implementation provides constant-time performance for the basic
> operations (get and put), assuming the hash function disperses the
> elements properly among the buckets."


Yes. And here it makes an assumption. Not that hashCode is implemented correct,
but that it is implemented in a certain way.

> Each specification refers to the other. Ergo they are meant to be
> considered together. Taken together, the documentation clearly specifies
> that "correct" or "proper" includes performance considerations.
> Therefore, by what you say, the simple "return 1;" is not correct.


> As you say, Arne, "correct" means it follows the spec. The OP's
> suggested implementation violates the spec on two fronts.


No it does not.

It follows exactly the explicit stated contract in the Java doc:

<quote>
The general contract of hashCode is:

Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently return
the same integer, provided no information used in equals comparisons on the
object is modified. This integer need not remain consistent from one execution
of an application to another execution of the same application.
If two objects are equal according to the equals(Object) method,
then calling the hashCode method on each of the two objects must produce the
same integer result.
It is not required that if two objects are unequal according to the
equals(java.lang.Object) method, then calling the hashCode method on each of
the two objects must produce distinct integer results. However, the programmer
should be aware that producing distinct integer results for unequal objects may
improve the performance of hashtables.
</quote>

The ability to support something does not make it part of the contract.

This is a classic test question in basic Java SE. And that returning a constant
is correct but not smart should be in most Java SE text books.

Arne

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      08-13-2012
To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
ove-nlb-this>

To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
ove-m2z-this>

To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <(E-Mail Removed)>

On 8/11/2012 10:15 PM, Arne Vajh-,j wrote:
> This is a classic test question in basic Java SE. And that returning
> a constant is correct but not smart should be in most Java SE
> text books.


Effective Java / Joshua Bloch:

<quote>
// The worst possible legal hash function - never use!
public int hashCode() { return 42; }

It is legal because it ensures that equal objects have the same hash code. It's
atrocious because ...
</quote>

Java 2 SUN Certified Programmer & Developer / Kathy Sierra & Bert Bates:

<quote>
A hashCode() that returns the same value for all instances whether they're
equal or not is still a legal - even appropriate - hashCode() method! For
example,
public int hashCode() {
return 1492;
}
would not violate the contract
....
This hashCode() method is horrible inefficient, ... ... Nontheless, this
one-hash-fits-all method would be considered appropriate and even correct
because it doesn't violate the contract. Once more, correct does not
necessarily mean good.
</quote>

Arne

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-13-2012
To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: "Eric Sosman" <eric.sosman@1:261/38.remove-nlb-this>

To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: "Eric Sosman" <eric.sosman@1:261/38.remove-m2z-this>

To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: Eric Sosman <(E-Mail Removed)>

On 8/11/2012 10:29 PM, Arne Vajh-,j wrote:
> On 8/11/2012 10:15 PM, Arne Vajh-,j wrote:
>> This is a classic test question in basic Java SE. And that returning
>> a constant is correct but not smart should be in most Java SE
>> text books.

>
> Effective Java / Joshua Bloch:
>
> <quote>
> // The worst possible legal hash function - never use!
> public int hashCode() { return 42; }
>
> It is legal because it ensures that equal objects have the
> same hash code. It's atrocious because ...
> </quote>
>
> Java 2 SUN Certified Programmer & Developer / Kathy Sierra & Bert Bates:
>
> <quote>
> A hashCode() that returns the same value for all instances whether
> they're equal or not is still a legal - even appropriate - hashCode()
> method! For example,
> public int hashCode() {
> return 1492;
> }
> would not violate the contract
> ...
> This hashCode() method is horrible inefficient, ...
> ...
> Nontheless, this one-hash-fits-all method would be
> considered appropriate and even correct because it
> doesn't violate the contract. Once more, correct does
> not necessarily mean good.
> </quote>


All this means is that people know how to describe a "correct"
hashCode(), but nobody knows how to describe a "usable" hashCode() in terms
that apply testably to all circumstances.

The O.P. asked whether it would "be potentially better" if
Object's hashCode() returned a constant. He did *not* ask whether such an
implementation would be correct; he only asked if it would "be potentially
better." Upon prompting he explained what he meant by "better," and in light
of that explanation the answer to his original question is NO. Discussions
about "Oh, but it's CORRECT" are just red herrings; it's still not "better."

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      08-13-2012
To: Eric Sosman
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
ove-nlb-this>

To: Eric Sosman
From: "=?UTF-8?B?QXJuZSBWYWpow7hq?=" <=?utf-8?b?qxjuzsbwywpow7hq?=@1:261/38.rem
ove-m2z-this>

To: Eric Sosman
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <(E-Mail Removed)>

On 8/11/2012 10:43 PM, Eric Sosman wrote:
> The O.P. asked whether it would "be potentially better" if
> Object's hashCode() returned a constant. He did *not* ask whether
> such an implementation would be correct; he only asked if it would
> "be potentially better." Upon prompting he explained what he
> meant by "better," and in light of that explanation the answer
> to his original question is NO. Discussions about "Oh, but it's
> CORRECT" are just red herrings; it's still not "better."



The original questions were:

#Is it always technically correct to override the hashCode function
#like so:
#
# @Override
# public int hashCode() {
# return 1;
# }

For which the answer is YES. Per documentation.

But with really poor performance in many relevant cases.

#Would it be potentially better if that was Object's implementation?

Which was clarified to:

#Better in the sense that you would never HAVE to override hashCode.

For which the answer is also YES. Per the previous.

But with the same performance note. And a big sigh because it seems to want to
broaden bad performance from a single class to the entire programming style
(multiple classes).

Arne

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

-+- BBBS/Li6 v4.10 Dada-1
+ Origin: Prism bbs (1:261/3
-+- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/3
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hashcode of primitive types Dimitri Pissarenko Java 5 01-29-2004 11:05 PM
Improving hashCode() to match equals() Marco Java 10 01-17-2004 09:55 PM
Designing hashCode() methods kelvSYC Java 1 12-24-2003 02:56 AM
equals and hashCode Gregory A. Swarthout Java 2 12-20-2003 12:34 AM
hashCode for byte[] Roedy Green Java 1 08-22-2003 02:08 AM



Advertisments