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
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. :)
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.
--
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
On Sun, Oct 9, 2011 at 1:51 PM, Jerry Krinock je...@ieee.org 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
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:]
