[Numpy-discussion] NumPy date/time types and the resolution concept
Mon Jul 14 12:18:28 CDT 2008
A Monday 14 July 2008, Anne Archibald escrigué:
> 2008/7/14 Francesc Alted <firstname.lastname@example.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
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 , having a
femtosecond resolution is not going to bother people, I think.
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.
More information about the Numpy-discussion