Creating the NSNumber objects using unsignedLongLong instead of longLong solved my problem. Thanks to everyone who participated in the lively discussion.
Sorry for being a little slow in closing the loop. -Michael On Feb 21, 2011, at 9:50 PM, Wim Lewis wrote: > > On 19 Feb 2011, at 2:17 PM, Michael Crawford wrote: >> Anyone have previous experience with this problem? Can you shed some light >> on where my thinking and assumptions are wrong. I could write a sweet of >> tests to try and prove/disprove what I think is happening but I'm hoping to >> benefit from someone else's pre-existing research, experiments, or internal >> knowledge. > > One thing to check is to find two NSNumbers which you think should be equal, > and see whether they return YES to -isEqual:. This is the form of equality > which NSSet is interested in. (-hash is an optimization.) > >> I also assumed that whether or not the value is signed or unsigned; negative >> or positive makes no difference as long as calling the same accessor method >> on both NSNumber instances returns the same result. > > I think this is the false assumption that is giving you grief. Calling an > accessor whose return type can't represent the NSNumber's value will return a > value which has been converted according to C's casting rules (as far as I > know). Consider two large numbers whose bottom 16 bits are the same; calling > -unsignedShortValue on them will return the same value, but you wouldn't > expect (or want) those numbers to compare equal. > > It looks like the contents of your noPlaySongs array were created using > numberWithLongLong:. Is there a reason not to use numberWithUnsignedLongLong: > to create them (as Greg Guerin suggests)? Or, ideally, never convert them to > a C integer representation in the first place and treat them as if they were > opaque objects (as Matt Neuburg suggests)? There's a fundamental difficulty, > which is that there is no C type which can represent the values of all > possible NSNumbers of integral types, (or even all C integers!), so > roundtripping the number through a plain integer type is fraught with peril > unless you know (or can figure out) which C type to use. > > > (IIRC, there are still a few small warts in NSNumber/CFNumber's behavior > which come from the fact that the numeric types implemented by CFNumber are > not compatible with the numeric types implemented by NSNumber, and yet > NSNumber is toll-free-bridged to CFNumber. I don't think this is related to > your problem, though.) > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
