[Numpy-discussion] NumPy date/time types and the resolution concept

[Francesc Alted]

A Monday 14 July 2008, Anne Archibald escrigué:
> 2008/7/14 Francesc Alted <faltet@pytables.org>:
> > After pondering about the opinions about the first proposal, the
> > idea we are incubating is to complement the ``datetime64`` with a
> > 'resolution' metainfo.  The ``datetime64`` will still be based on a
> > int64 type, but the meaning of the 'ticks' would depend on a
> > 'resolution' property.
>
> This is an interesting idea. To be useful, though, you would also
> need a flexible "offset" defining the zero of time. After all, the
> reason not to just always use (say) femtosecond accuracy is that
> 2**64 femtoseconds is only about five hours. So if you're going to
> use femtosecond steps, you really want to choose your start point
> carefully. (It's also worth noting that there is little need for more
> time accuracy than atomic clocks can provide, since anyone looking
> for more than that is going to be doing some tricky metrology
> anyway.)

That's a good point indeed.  Well, to start with, I suppose that 
picosecond resolution is more than enough for nowadays precision 
standards (even when using atomic clocks).  However, provided that 
atomic clocks are always improving its precision [1], having a 
femtosecond resolution is not going to bother people, I think.

[1] http://en.wikipedia.org/wiki/Image:Clock_accurcy.jpg

But the time origin is certainly an issue, yes.  See later.

> One might take guidance from the FITS format, which represents
> (arrays of) quantities as (usually) fixed-point numbers, but has a
> global "scale" and "offset" parameter for each array. This allows one
> to accurately represent many common arrays with relatively few bits.
> The FITS libraries transparently convert these quantities. Of course,
> this isn't so convenient if you don't have basic machine datatypes
> with enough precision to handle all the quantities of interest.

That's pretty interesting in that the "scale" is certainly something 
similar to the "resolution" concept that we want to introduce.  And 
definitely, "offset" would be similar to "origin".  So yes, we will try 
to introduce both concepts.

However, one thing that we would try to avoid is to use fixed-point 
arithmetic (we plan to use integer arithmetic only).  The rational is 
that fixed-point arithmetic is computationally more complex (it has to 
implemented in software, while integer arithmetic is implemented in 
hardware) and that would slow down things too much.

Thanks!

-- 
Francesc Alted