Re: isEqual: and hash in NSDate

[Markus Hitter]

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 = 1
>
> This 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/