1

Edit:

This is not strictly a Floating point question as NSTimeInterval is derived from Double. However I added Floating point to the tags as it could be related.

Problem:

When computing the difference between two identical NSTimeInterval I get a value different than zero (-0.0000013etc..).

Question:

Why is that? My understanding is that they are Double values so the behaviour should be consistent (if those where Float type it would be different).

Swift Code:

let timeDifference : NSTimeInterval = timeValue.timeIntervalSince1970 - timeStarted!.timeIntervalSince1970
mm24
  • 9,280
  • 12
  • 75
  • 170
  • 4
    is `timeStarted === timeValue` ? how were they created ? how do you know they're exactly equal ? – Wain Jan 28 '16 at 13:16
  • 1
    Possible duplicate of [Floating Point Limitations](http://stackoverflow.com/questions/406361/floating-point-limitations). To be clear, a `Double` (or `NSTimeInterval`, which is a typealias for `Double`) still has all of the same limitations as a `Float`. They're all floating point numbers. Doubles simply have double the accuracy. – nhgrif Jan 28 '16 at 13:20
  • 2
    @nhgrif: Very unlikely. If the dates _were_ identical then this difference would definitely be zero. – gnasher729 Jan 28 '16 at 13:21
  • The two values are created using NSDate() and they are identical when I look at the debugger (same date, same hour, same minute, same seconds). – mm24 Jan 28 '16 at 13:27
  • 1
    If you used `NSDate()` two times in a row, it generated two slightly different dates (a few nanoseconds off). – Tobi Nary Jan 28 '16 at 13:32
  • 2
    You can't create two identical date objects using `NSDate`'s zero-argument constructor. Please add the code where you're constructing the date objects. – nhgrif Jan 28 '16 at 13:37
  • I'm having a similar issue. If you create a date, ```[[NSDate date] timeIntervalSince1970]``` and put that into an NSTimeInterval variable. Calculations on it will return non-zero values. I've tried subtracting whole numbers from this variable and get precision errors that mess up calculations expecting a zero number. – Bill Burgess Feb 28 '19 at 16:42

0 Answers0