Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   why in class Boolean, hashcode() of "true" is 1231 and of "false" is1237? (http://www.velocityreviews.com/forums/t643936-why-in-class-boolean-hashcode-of-true-is-1231-and-of-false-is1237.html)

junzhang1983@gmail.com 11-11-2008 08:39 AM

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

Pushkaraj 11-11-2008 11:36 AM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false"is 1237?
 
On Nov 11, 1:39*pm, junzhang1...@gmail.com wrote:
> * * 3ks


Is this a spam or really a question?

Lew 11-11-2008 02:41 PM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false"is 1237?
 
> 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

Patricia Shanahan 11-11-2008 06:38 PM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false"is 1237?
 
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

Tom Anderson 11-11-2008 07:04 PM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false"is 1237?
 
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

Lew 11-11-2008 07:58 PM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false"is 1237?
 
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 11-11-2008 08:22 PM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false"is 1237?
 
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



Roedy Green 11-11-2008 09:31 PM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false" is 1237?
 
>why in class Boolean, hashcode() of "true" is 1231 and of "false" is 1237?
It is best to repeat your question in the body.

Primes scramble nicely when you xor, add or modulo them. They don't
collapse down onto a small set of values


--
Roedy Green Canadian Mind Products
http://mindprod.com
Your old road is
Rapidly agin'.
Please get out of the new one
If you can't lend your hand
For the times they are a-changin'.

Lew 11-11-2008 09:48 PM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false"is 1237?
 
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.


"Peter Duniho" wrote:
> 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.


What I mean there is that comparison is not relevant, composition is.

--
Lew


Tom Anderson 11-11-2008 10:08 PM

Re: why in class Boolean, hashcode() of "true" is 1231 and of "false"is 1237?
 
On Tue, 11 Nov 2008, Lew wrote:

> 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:
>>>
>>> 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?


A rhetorical question, i suspect, but the answer is ll of them. Pick an x,
an use ~x for the other.

> 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?


A very good question - i don't know, and i'm very surprised by those
choices.

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


True, but then why not, eg 1011818350 and -1011818351?

> 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?


Might you want to have a map keyed by arbitrary objects for some reason?

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


I suspect some kind of kabbalistic significance.

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


All times are GMT. The time now is 06:37 AM.

Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57