|
From: | Markus Hitter |
Subject: | Re: isEqual: and hash in NSDate |
Date: | Fri, 22 Jul 2005 02:22:01 +0200 |
Am 21.07.2005 um 21:49 schrieb Jeremy Bettis:
I have a problem with the implementations of isEqual: and hash in NSDate.Let's say we have two dates: NSDate *a, *b;// This is actually a common case if you are doing floating point math to generate dates and get small rounding errors.a = [NSDate dateWithTimeIntervalSinceReferenceDate:100000.001]; b = [NSDate dateWithTimeIntervalSinceReferenceDate:99999.998];printf("a = %d, b=%d, equal=%d\n", [a hash] , [b hash], [a isEqual:b]);// this code will print a = 100000, b = 99999, equal = 1This breaks the NSDictionary rule that hash of two objects must equal if they are -isEqual:.
While you are true with this rule and obviously true with -isEqual: being broken, you shouldn't compare dates with -isEqual: but with - isEqualToDate: and/or handle rounding errors more consciously:
if (fabs([a timeIntervalSinceReferenceDate] - [b timeIntervalSinceReferenceDate]) < someAmountOfSecondsYouConsiderNeglible) {
// they are equal } else { // they differ }
- (BOOL) isEqual: (id)other { [...] if ([other isKindOfClass: abstractClass] && (int)(otherTime(self)+0.5) == (int)(otherTime(other)+0.5) )
Any reason why you don't want to compare [self hash] to [other hash]? my $0.02 Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
[Prev in Thread] | Current Thread | [Next in Thread] |