why in class Boolean, hashcode() of "true" is 1231 and of "false" is1237? - Java

On Tue, 11 Nov 2008 00:39:29 -0800, <junzhang1983@gmail.com> wrote:

> 3ks

Is "3ks" supposed to be a signature?

As for the question, why _shouldn't_ the hash code for those values be
1231 and 1237? I mean, my guess is that someone picked those two prime
numbers because they work well in some common Java case, but the fact is
that a class can define its hash code however it likes, as long as it
follows the basic rules of equality/inequality/consistency for all hash
codes.

I definitely would not want the hash codes to be 0 and 1.

Pete

On Nov 11, 1:39 pm, junzhang1...@gmail.com wrote:
>     3ks

Is this a spam or really a question?

> On Tue, 11 Nov 2008 00:39:29 -0800, <junzhang1983@gmail.com> wrote:
>

Please include a body to your posts.

Peter Duniho wrote:
> I definitely would not want the hash codes to be 0 and 1.

Why not?

--
Lew

Lew wrote:
>> On Tue, 11 Nov 2008 00:39:29 -0800, <junzhang1983@gmail.com> wrote:
>>
>
> Please include a body to your posts.
>
> Peter Duniho wrote:
>> I definitely would not want the hash codes to be 0 and 1.
>
> Why not?
>

The Integer hashCode() is the primitive int the Integer represents. 0
and 1 are particularly common int values. Given the lack of any
advantage to choosing those values for the Boolean hash codes, it makes
sense to me to pick a different pair of values.

Patricia

On Tue, 11 Nov 2008, Lew wrote:

>> On Tue, 11 Nov 2008 00:39:29 -0800, <junzhang1983@gmail.com> wrote:
>
> Please include a body to your posts.
>
> Peter Duniho wrote:
>> I definitely would not want the hash codes to be 0 and 1.
>
> Why not?

Because they only differ in one bit. It is often thought a good thing for
hashes of different objects to differ in as many bits as possible.
The low-order bits are particularly important, given that hashes are
often reduced to a smaller range by modding, but all the bits might be
used for something, so having them be different is a useful hedge.

That argument suggests that 0 and -1 might be the best values. I wonder
what Peter would think of that?

tom

--
Someone may observe that no doubt the conclusion preceded the
'proofs'. For who gives himself up to looking for proofs of something
he does not believe in, or the predication of which he does not care
about? -- Jorge Luis Borges

On Tue, 11 Nov 2008 06:41:28 -0800, Lew <noone@lewscanon.com> wrote:

> Peter Duniho wrote:
>> I definitely would not want the hash codes to be 0 and 1.
>
> Why not?

See Patricia's reply. Also, 0 is especially problematic IMHO because it
will more easily reveal a problem in a poorly chosen hash code composition
algorithm.

In a perfect world, I think 0 and 1 would be just as good as any other
hash code. After all, the person using the boolean hash code should only
be using in a context relative to other boolean hash codes, and where the
value is composited with other hash codes correctly. If one makes those
assumptions, I don't think any particular hash codes would have an
advantage over any others.

But that's not the world we live in, and I think when one is designing a
language/framework like Java it's that much more important to assume that
the occasional moron is going to be using your stuff.

Pete

On Nov 11, 2:04 pm, Tom Anderson <t...@urchin.earth.li> wrote:
> On Tue, 11 Nov 2008, Lew wrote:
> >> On Tue, 11 Nov 2008 00:39:29 -0800, <junzhang1...@gmail.com> wrote:
>
> > Please include a body to your posts.
>
> > Peter Duniho wrote:
> >> I definitely would not want the hash codes to be 0 and 1.
>
> > Why not?
>
> Because they only differ in one bit. It is often thought a good thing for
> hashes of different objects to differ in as many bits as possible.

By how many bits is it possible for a universe of two values to
differ?

1231 and 1237 differ in three bits. If differing in as many bits as
possible is good, why didn't they choose values that differed by
more? 11 and 17 differ by the exact same bits, after all.

>   The low-order bits are particularly important, given that hashes are
> often reduced to a smaller range by modding, but all the bits might be
> used for something, so having them be different is a useful hedge.
>
> That argument suggests that 0 and -1 might be the best values. I wonder
> what Peter would think of that?

Patricia's argument that Boolean hashes need to differ from common
Integer hashes might apply, assuming that there's any benefit to
that. How often are Boolean hashes compared to Integer hashes? How
often are hashcodes picked for a class so that it can be compared to a
different class?

I suspect that some early Java implementor decided that two arbitrary
prime numbers were just fine, and didn't happen to like 17.

--
Lew
Any time I need a random number, I pick 17.

Lew wrote:
> How often are Boolean hashes compared to Integer hashes?  

Answering my own question: as often as Integer and Boolean members
appear together in a class for which one must design a hash code that
distributes well over arbitrary-size hash lists.

--
Lew

On Tue, 11 Nov 2008 12:22:25 -0800, Lew <lew@lewscanon.com> wrote:

> Lew wrote:
>> How often are Boolean hashes compared to Integer hashes?  
>
> Answering my own question: as often as Integer and Boolean members
> appear together in a class for which one must design a hash code that
> distributes well over arbitrary-size hash lists.

I'm not sure what you mean there. Ideally, just because a class has both
Integer and Boolean members, that wouldn't mean you'd actually be
_comparing_ Integer hashes to Boolean hashes.

It seems to me that the values chosen are really more a form of defensive
programming on the part of the Java framework. If everyone could be
trusted to do hashing correctly, I believe that 0 and 1 would be fine
values. But not everyone can be, as we all know too well.

Pete