Time, floating points and python modules handling time
Some memory in the back of my mind tells I've once read a rant about storing time that argued you should never store time in floating point variables. My memory seems to think the rant convinced me and it does indeed seem better to store time in integers so that time doesn't go and change little bits due to rounding etc. and indeed the C library seems to stick to that, mostly (difftime() returns a double for example).
When looking at Python the stdlib datetime module seems to do this too. However ofter people scoff at the datetime module and recommend the use of mxDateTime instead, it is a lot better supposedly. But looking at how it stores time it seems to use double values interally.
So I am wondering, if mxDateTime gets away with storing time as floating points is there really a disadvantage to it? Is there a point to avoiding floating point numbers while handling time?
3 comments:
Unknown said...
Well, mxDateTime does not store time as a (single) floating point number. It stores a time as an integer (days since some time) and seconds of the day. And similarly, you can store time differences as ((integer) day + (double) second of the day). Of course, the trick is that the time representation is normalized whenever some operation takes place.
A disadvantage of the datetime module in this context is that its temporal resolution, by construction, is limited to 1 microsecond (or 10^{-6} seconds). With mxDateTime, and assuming that double precision numbers have a relative roundoff error in the order of 10^{-16} (that's 16 digits) or so, the roundoff error in mxDateTime is in the order of at most 86400 seconds/day * 10^{-16}, or about 10^{-11} seconds - that's about 10 picoseconds. Or a factor of 10000 better than what you get with Python's datetime.
If that matters to you does of course depend on your application. For example, I'm using mxDateTime in GPS applications, where time measurements are expected to be precise to something like a nanosecond (or 10^{-9} seconds). Obviously, code dealing with these measurements must be able to represent time with a sufficient resolution. With the core datetime module, this type of applications wouldn't even be possible; with mxDateTime, I'm fine...
That all said - if you would represent time as single double, e.g. as (seconds since some reference date), and use it in applications like GPS (where time is often multiplied by the speed of light), roundoff can indeed become sufficiently large to be a problem. Again, it depends on your application...
Marius Gedminas said...
Interesting: I haven't encountered any scoffing. People tend to complain sometimes that the datetime module is pretty bare in terms of functionality, but it has the blessing of being in the stdlib and is therefore usually preferred.
casey said...
You might find this interesting about visualizing how floats actually work:
http://cowboyprogramming.com/2007/01/05/visualizing-floats/
This discusses it in a game context, but I think it is applicable generally as well. It also centers around single floats, but this applies equally to doubles when the precision requirements and scale are high enough.
New comments are not allowed.