On 2005-07-22 18:29:31 +0100 Adrian Robert <address@hidden>
wrote:
On Jul 22, 2005, at 12:44 PM, Richard Frith-Macdonald wrote:
On 2005-07-22 15:57:03 +0100 Adrian Robert <address@hidden>
wrote:
This really seems like a hack (not that it's any worse than the
current state :). Couldn't the implementations of -hash and
-isEqual be aligned without this loss of information? E.g.
something like [warning, sloppy first-attempt code here]:
-isEqual:other
return abs(selfVal - other->selfVal) < epsilon;
-hash
return selfVal / epsilon;
(or maybe (selfVal + epsilon/2.0) / epsilon)
No ... each NSDate has to have its own independent hash ... but
(following the OpenStep spec) dates are equal if they are within a
second of each other.
That means that with dates d1, d2, d3 which have offsets from the
reference date of 0.0, 0.7 and 1.4 seconds,
d1 is eqal to d2 and d2 is equal to d3 but d1 is not equal to d3 ...
a rather counterintuitive behavior!
Right, bad. Thisd could be fixed by changing -isEqual: to simply
return [self hash] == [other hash]
Yes, though the direct instance variable comparison is more efficient.
I don't see anything wrong conceptually with stipulating that dates
within some epsilon are isEqual and retrieve the same values as keys
in a hash table,
Really? what value would you use for the hash?
In this example, epsilon is 1 second ...
So d1 and d2 must hash to the same value ... in order for the
hash/isEqual test to work for them as dictionary keys (the two equal
keys wouldn't be found in the same hash bucket in the dictionary
otherwise).
By the same argument d2 and d3 must hash to the same value.
Similarly d3 must hash to the same value as d4 (a date greater than d3
by any value less than epsilon), and so on ...
I think you can see that this leads to a single value for hash being
required for all possible dates.
The same argument can be used for any non-zero value of epsilon.