On Dec 10, 2008, at 9:03 PM, Brian Will wrote:
btw, you'll see a few notes I left in the text in square brackets where I wasn't sure on some point. If someone could address those questions, I'd appreciate it.
[hmm, what are the chances of a false positive due to hash collision? are the odds astronomical and therefore acceptable?
A correct use of hash codes in equality testing would be only to enable returning false (indicating not equal) quickly. Hash codes cannot be used to ensure that objects are equal. If two objects have the same hash code, they need to be checked in more detail to determine whether or not they are also equal.
For the Java take on this, please see: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode() In particular: 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.
The chances of a false positive on an equality test due to hash collision is zero.
and what about Java strings; is it simply a call to equals?]
A non-trivial call to clojure.core/= reduces to a series of one or more calls to clojure.core/= with two arguments. The two argument case is handled by clojure.lang.Util.equals. After a quick return of "true" if the objects are identical and some check whether this is a comparison involving nil or numbers (which get a bit of special treatment), the general case eventually calls the equals method of the first object with the second as its argument. If the first object is a string, that does boil down to a call to the string's equals method.
--Steve
smime.p7s
Description: S/MIME cryptographic signature
