Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #17577 > unrolled thread
| Started by | bob smith <bob@coolfone.comze.com> |
|---|---|
| First post | 2012-08-10 08:47 -0700 |
| Last post | 2012-08-12 17:11 -0400 |
| Articles | 6 on this page of 106 — 20 participants |
Back to article view | Back to comp.lang.java.programmer
hashCode bob smith <bob@coolfone.comze.com> - 2012-08-10 08:47 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 12:13 -0400
Re: hashCode markspace <-@.> - 2012-08-10 10:13 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 13:38 -0400
Re: hashCode rossum <rossum48@coldmail.com> - 2012-08-11 10:36 +0100
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-10 12:34 -0400
Re: hashCode bob smith <bob@coolfone.comze.com> - 2012-08-10 15:22 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-10 15:32 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:30 -0400
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:24 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:15 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:29 -0400
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 22:43 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:54 -0400
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 21:46 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 16:53 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:00 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:27 -0400
Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-12 17:06 +0200
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 16:59 -0400
Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-13 19:17 +0200
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-19 19:42 -0400
Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-21 10:30 +0000
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-19 19:47 -0400
Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-21 10:43 +0000
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 19:04 -0400
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-27 16:55 -0700
Re: hashCode markspace <-@.> - 2012-08-27 17:03 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-27 17:49 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 21:37 -0400
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-27 18:58 -0700
Re: hashCode markspace <-@.> - 2012-08-27 21:19 -0700
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-28 01:06 -0700
Re: hashCode markspace <-@.> - 2012-08-28 09:19 -0700
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-28 16:33 -0700
Re: hashCode markspace <-@.> - 2012-08-28 17:02 -0700
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 11:06 -0700
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 14:49 -0400
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 13:40 -0700
Re: hashCode Gene Wirchenko <genew@ocis.net> - 2012-08-29 18:02 -0700
Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-08-31 00:52 +0200
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-30 21:43 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-30 21:52 -0400
Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-08-31 04:18 +0200
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:08 -0600
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 11:38 -0400
Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-31 17:55 +0200
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:56 -0600
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 14:32 -0400
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 14:38 -0600
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-31 15:33 -0700
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 16:41 -0600
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-31 16:26 -0700
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-09-02 11:54 -0600
Re: hashCode Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-09-03 00:47 +0200
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-09-03 21:44 -0600
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-31 09:08 -0600
Re: hashCode Robert Klemme <shortcutter@googlemail.com> - 2012-08-31 17:58 +0200
Re: hashCode markspace <-@.> - 2012-08-29 11:51 -0700
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 13:28 -0700
Re: hashCode markspace <-@.> - 2012-08-29 16:05 -0700
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-29 16:23 -0700
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 20:56 -0400
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-30 11:19 +0200
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-30 10:03 -0700
Re: hashCode Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2012-08-30 18:34 +0000
Re: hashCode Jim Janney <jjanney@shell.xmission.com> - 2012-08-30 08:11 -0600
Re: hashCode Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-08-30 10:06 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-30 19:16 -0400
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 13:58 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 13:56 -0700
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-28 14:07 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-28 14:38 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-27 21:12 -0400
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 07:58 -0400
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:29 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:16 -0400
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 03:46 -0700
Re: hashCode Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-08-12 12:23 -0400
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 09:40 -0700
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-12 13:59 -0400
Re: hashCode Patricia Shanahan <pats@acm.org> - 2012-08-12 11:17 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:02 -0400
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 19:03 +0200
Re: hashCode Roedy Green <see_website@mindprod.com.invalid> - 2012-08-10 12:17 -0700
Re: hashCode Lew <lewbloch@gmail.com> - 2012-08-10 12:45 -0700
Re: hashCode Roedy Green <see_website@mindprod.com.invalid> - 2012-08-11 04:54 -0700
Re: hashCode Joerg Meier <joergmmeier@arcor.de> - 2012-08-11 18:25 +0200
Re: hashCode Mike Winter <usenet@michael-winter.me.invalid> - 2012-08-11 18:53 +0100
Re: hashCode Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-08-11 09:56 -0700
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 18:58 +0200
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:40 -0400
Re: hashCode rossum <rossum48@coldmail.com> - 2012-08-11 18:47 +0100
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-10 19:25 -0400
Re: hashCode Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-11 08:00 -0400
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 09:49 -0400
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 15:33 +0200
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-11 15:34 +0200
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:34 -0700
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 16:37 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-11 22:19 -0400
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-11 21:48 -0700
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 12:08 +0200
Re: hashCode Jan Burse <janburse@fastmail.fm> - 2012-08-12 12:18 +0200
Re: hashCode Lew <noone@lewscanon.com> - 2012-08-12 11:27 -0700
Re: hashCode Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 17:11 -0400
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-08-11 22:19 -0400 |
| Message-ID | <502712b5$0$292$14726298@news.sunsite.dk> |
| In reply to | #17717 |
On 8/11/2012 7:34 PM, Lew wrote: > Jan Burse wrote: >> Maybe it would make sense to spell out what the contract >> for hashCode() is. Well the contract is simply, the >> following invariant should hold: >> >> /* invariant that should hold */ >> if a.equals(b) then a.hashCode()==b.hashCode() > > True, but if you read the specification for 'hashCode()' fully, that is > not the entire contract, only the compiler-enforceable part of it. > > The entire specification requires that as much as feasible, the 'Object' > implementation distinguish distinct instances, and that the method > generally support 'HashMap', which promises O(1) 'get()' and 'put()' > with a "proper" (i.e., compliant) 'hashCode()'. Two wrong statements. It says that the method is defined to support HashMap And HashMap does not guarantee O(1) with a correct hashCode - it guarantee that for one that return good distributed values. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-08-11 21:48 -0700 |
| Message-ID | <k07cj9$62g$2@news.albasani.net> |
| In reply to | #17722 |
Arne Vajhøj wrote: > Lew wrote: >> Jan Burse wrote: >>> Maybe it would make sense to spell out what the contract >>> for hashCode() is. Well the contract is simply, the >>> following invariant should hold: >>> >>> /* invariant that should hold */ >>> if a.equals(b) then a.hashCode()==b.hashCode() >> >> True, but if you read the specification for 'hashCode()' fully, that is >> not the entire contract, only the compiler-enforceable part of it. >> >> The entire specification requires that as much as feasible, the 'Object' >> implementation distinguish distinct instances, and that the method >> generally support 'HashMap', which promises O(1) 'get()' and 'put()' >> with a "proper" (i.e., compliant) 'hashCode()'. > > Two wrong statements. > > It says that the method is defined to support HashMap > > And HashMap does not guarantee O(1) with a correct > hashCode - it guarantee that for one that return > good distributed values. Granted. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2012-08-12 12:08 +0200 |
| Message-ID | <k07vbk$k2g$1@news.albasani.net> |
| In reply to | #17677 |
Jan Burse schrieb:
> Maybe it would make sense to spell out what the contract
> for hashCode() is.
Those who are interested can read the original text.
It is found here:
http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode%28%29
---------------------------------------------------------------
"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."
That is:
/* invariant that should hold */
if a.equals(b) then a.hashCode()==b.hashCode()
----------------------------------------------------------------
"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 hash tables."
That is:
/* not implied and thus not required by the invariant */
if a.hashCode()==b.hashCode() then a.equals(b)
It is also quite unlikely that a hashCode() would satisfy
the later, although the closer it comes to the later, the
better it works for HashMap, etc..
----------------------------------------------------------------
There is no reference to Comparable and the compareTo. If I am not
using HashMap or HashSet in my application, and still override
equals, I do not need to implement hashCode(). I could for example
use TreeMap or TreeSet and implement the Comparable interface. There
is a reference to equals() back from Comparable though.
http://docs.oracle.com/javase/6/docs/api/java/lang/Comparable.html
Bye
[toc] | [prev] | [next] | [standalone]
| From | Jan Burse <janburse@fastmail.fm> |
|---|---|
| Date | 2012-08-12 12:18 +0200 |
| Message-ID | <k07vu6$l6u$1@news.albasani.net> |
| In reply to | #17730 |
Jan Burse schrieb: > /* not implied and thus not required by the invariant */ > if a.hashCode()==b.hashCode() then a.equals(b) This is logically equivalent to what is formulated in the Javadoc by the so called contraposition: if !a.equals(b) then a.hashCode()!=b.hashCode() http://en.wikipedia.org/wiki/Contraposition
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-08-12 11:27 -0700 |
| Message-ID | <k08sio$f6d$1@news.albasani.net> |
| In reply to | #17730 |
Jan Burse wrote: > There is no reference to Comparable and the compareTo. If I am not True. > using HashMap or HashSet in my application, and still override > equals, I do not need to implement hashCode(). I could for example True. > use TreeMap or TreeSet and implement the Comparable interface. There > is a reference to equals() back from Comparable though. This requires a detailed knowledge of the implementation of the particular 'Map' or 'Set'. If its searches do not employ hash codes, then you do not need to implement 'hashCode()' for value-equal types. In the general case one prefers to underspecify the mechanics, that is, allow a client of the type to deploy either 'equals()'-based or hash-based algorithms, by ensuring the methods are consistent with each other per Joshua Bloch and other notables. > http://docs.oracle.com/javase/6/docs/api/java/lang/Comparable.html Even for cases where one predicts the use will not require one or another of the consistency practices, it is harmless to enforce them. There are four methods a type might use to represent equality or identity and deviations therefrom: 'equals()' of course, and 'hashCode()', 'compareTo()', and 'toString()'. There may be external 'Comparator's on that type. All these methods on or of a type, where they exist, should be consistent, absent an overwhelming and sound reason not to be. The default case from 'Object' is that 'equals()' implements ==, 'hashCode()' returns something sort of like an address of the instance which is nearly always unique within a given JVM run, 'toString()' returns a decorated string version of the hash code, and 'compareTo()' doesn't exist. To express value equality in a type, one must override 'equals()'. The rest are optional in Arne's strictest and most correct use of that notion. It is also harmless to keep the rest consistent and nearly always (as in you might encounter one instance per career otherwise) useful. One generally chooses 'TreeMap' for its sorting capability, not its reliance on 'equals()' vs. 'hashCode()' to achieve that. (Assuming it has such a reliance.) Unless there's a compelling argument to rely on 'TreeMap''s undocumented non-use of hash codes, why do so? Yes, I am aware that the 'TreeMap' documentation makes it clear that 'hashCode()' shouldn't be involved. Without promising it isn't. But a 'Comparator' might use hash codes under the hood in a naive attempt to shortcut a comparison, not knowing that the base type assumes no one would do such a thing. Or some later client might need only equality and not order, and throw the base type into a 'HashMap' with surprising results. Should you design anything that violates the consistency rule, then please do both Javadoc and code-comment it properly. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-08-12 17:11 -0400 |
| Message-ID | <50281c14$0$293$14726298@news.sunsite.dk> |
| In reply to | #17739 |
On 8/12/2012 2:27 PM, Lew wrote:
> Even for cases where one predicts the use will not require one or
> another of the consistency practices, it is harmless to enforce them.
>
> There are four methods a type might use to represent equality or
> identity and deviations therefrom: 'equals()' of course, and
> 'hashCode()', 'compareTo()', and 'toString()'. There may be external
> 'Comparator's on that type.
>
> All these methods on or of a type, where they exist, should be
> consistent, absent an overwhelming and sound reason not to be.
> Should you design anything that violates the consistency rule, then
> please do both Javadoc and code-comment it properly.
I agree.
(well toString is not high on my priority list for what needs to
behave certain ways, but ...)
To make it easier to get them consistent, then I think it would
be nice with syntactic sugar.
Like:
public class Data {
@ValueId
private int iv;
@ValueId
private String sv;
// the rest of the class
}
which would cause the compiler to emit equals and hashCode methods
that are test of the @ValueId fields are equal and creates a "decent"
hash.
public class Data implements Comparable<Data> {
@ValueId
private int iv;
@ValueId
private String sv;
// the rest of the class
}
could cause the compiler to output a compareTo as well.
It is invisible code, but we already got that with the
default constructor.
And it will help make those methods consistent.
Of course explicit override should still be possible.
Arne
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.java.programmer
csiph-web