[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isEqual: and hash in NSDate

From: Richard Frith-Macdonald
Subject: Re: isEqual: and hash in NSDate
Date: Fri, 22 Jul 2005 19:56:54 +0100

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]:
    return abs(selfVal - other->selfVal) < epsilon;
    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.

though this might preclude some practical uses. However OS X compatibility seems the better way to go at this point.

(While we're on this subject, could we change NSEvent timestamps to be in seconds like OS X (and OpenStep for that matter), instead of milliseconds?)

OS X and OPENSTEP return an NSTimeInterval just like GNUstep ... and they don't round to the second either. The documentatiuon says 'in seconds', but I think this just means that the unit of measurement is the second.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]