![]() |
why in class Boolean, hashcode() of "true" is 1231 and of "false" is1237?
3ks
|
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? |
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 |
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 |
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 |
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. |
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 |
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'. |
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 |
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.