Re: -dateWithTimeIntervalSinceNow: 64-bits may overflow
Jerry Krinock wrote: Not necessarily. Multiple overflows tend toward a random number generator. Doubles overflow to +INF, as do floats. Arithmetic on INFs typically yields one of the INFs (+INF or -INF). It is decidedly non-random. It would be an interesting experiment, though. -- GG ___ 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
Re: -dateWithTimeIntervalSinceNow: 64-bits may overflow
On 2011 Oct 12, at 14:40, Sean McBride wrote: > Strange since NSTimeInterval is double in both 32 and 64 bit. Why did you > use FLT_MAX and not DBL_MAX? Oh, probably when I wrote that code I wasn't aware DBL_MAX, and FLT_MAX was more than enough. > No doubt the latter would be even worse. :) Not necessarily. Multiple overflows tend toward a random number generator. ___ 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
Re: -dateWithTimeIntervalSinceNow: 64-bits may overflow
On Sat, 8 Oct 2011 21:09:15 -0700, Jerry Krinock said: >Don't do this: > >-[NSDate dateWithTimeIntervalSinceNow:FLT_MAX] ; > >Expected result: A date far off into the future which will always behave >as though it is later than or equal to any other date. > >No problem ever in 32-bit executable. > >In 64-bit, -[NSDate compare:] and -[NSDate laterDate:] still work as >expected. But other methods may not. For example, -[NSConditionLock >lockWhenCondition:beforeDate:] seems to think that such a "float max >date" has already past and returns NO immediately, regardless of its >'condition'. > >I filed a bug, 10256461, but am posting here because I suppose Apple may >consider this to be a programming error and not a bug. Strange since NSTimeInterval is double in both 32 and 64 bit. Why did you use FLT_MAX and not DBL_MAX? No doubt the latter would be even worse. :) -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: -dateWithTimeIntervalSinceNow: 64-bits may overflow
On Sun, Oct 9, 2011 at 1:51 PM, Jerry Krinock wrote:
>
> On 2011 Oct 08, at 21:12, Stephen J. Butler wrote:
>
>> What's wrong with +[NSDate distantFuture]?
>
> Nothing. It's only [NSDate -dateWithTimeIntervalSinceNow:FLT_MAX] which
> sometimes gives unexpected results.
It's not, at least not on 10.6 with Xcode 3.2.5. This program...
#import
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSLog( @"distantFuture: %@", [NSDate distantFuture] );
NSLog( @"FLT_MAX: %@", [NSDate dateWithTimeIntervalSinceNow:FLT_MAX] );
[pool drain];
return 0;
}
Gives the output (in 32 and 64 bit):
2011-10-09 14:46:41.639 Untitled[60937:a0f] distantFuture: 4000-12-31
18:00:00 -0600
2011-10-09 14:46:41.640 Untitled[60937:a0f] FLT_MAX: 5828963-12-19
18:00:00 -0600
I think you'll find distantFuture much less buggy than your solution,
seeing as how it isn't going to overflow or run into boundary
situations.
___
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
Re: -dateWithTimeIntervalSinceNow: 64-bits may overflow
On 2011 Oct 08, at 21:12, Stephen J. Butler wrote: > What's wrong with +[NSDate distantFuture]? Nothing. It's only [NSDate -dateWithTimeIntervalSinceNow:FLT_MAX] which sometimes gives unexpected results. ___ 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
Re: -dateWithTimeIntervalSinceNow: 64-bits may overflow
On Sat, Oct 8, 2011 at 11:09 PM, Jerry Krinock wrote: > Don't do this: > > -[NSDate dateWithTimeIntervalSinceNow:FLT_MAX] ; > > Expected result: A date far off into the future which will always behave as > though it is later than or equal to any other date. What's wrong with +[NSDate distantFuture]? ___ 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
