Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #17837 > unrolled thread

Re: hashCode

Back to article view | Back to comp.lang.java.programmer

Contents

  Re: hashCode "Lew" <lew@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000
    Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000
      Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000
        Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000
          Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-odu-this> - 2012-08-13 19:38 +0000

#17837 — Re: hashCode

  To: Arne Vajhøj
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 <noone@lewscanon.com>

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/wikipedia/commons/c/cf/Friz.jpg

-+- BBBS/Li6 v4.10 Dada-1
 + Origin: Prism bbs (1:261/38)
-+- 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/38)
-+- 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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]

#17843

  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?= <arne@vajhoej.dk>

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/38)
-+- 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/38)
-+- 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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17845

  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?= <arne@vajhoej.dk>

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/38)
-+- 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/38)
-+- 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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17846

  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 <esosman@ieee-dot-org.invalid>

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
esosman@ieee-dot-org.invalid

-+- BBBS/Li6 v4.10 Dada-1
 + Origin: Prism bbs (1:261/38)
-+- 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/38)
-+- 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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17849

  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?= <arne@vajhoej.dk>

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/38)
-+- 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/38)
-+- 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/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web