On Thu, Jan 29, 2015 at 12:55 AM, Eric Firing <[email protected]> wrote:
> On 2015/01/28 6:29 PM, Charles R Harris wrote: > > > > > > And as for "The 64 bits of long long really isn't enough and leads > > to all sorts of compromises". not long enough for what? I've always > > thought that what we need is the ability to set the epoch. Does > > anyone ever need picoseconds since 100 years ago? And if they did, > > we'd be in a heck of a mess with leap seconds and all that anyway. > > > > > > I was thinking elapsed time. Nanoseconds can be rather crude for that > > depending on the measurement. Of course, such short times aren't going > > to come from the system clock, but data collected in other ways, > > interference between light pulses over microscopic distances for > > instance. Such data is likely acquired as, or computed, from simple > > numbers with a unit, which gets us back to the numpy version. But that > > complicates the heck out of things when you want to start adding times > > in different units. > > Chuck, > > For any kind of data like that, I fail to see why any special numpy time > type is needed at all. Wouldn't the user just keep elapsed time as a > count, or floating point number, in whatever units the instrument spits > out? Why does it need to be treated in a different way from any other > numeric data? We don't have special types for length. It seems to me > that numpy's present experimental datetime64 type has already fallen > into the trap of overengineering--trying to be too many things to too > many people. The main reason for having a special datetime type is to > deal with the calendar mess, and conventional hours-minutes-seconds > time. For very short time intervals, all that is irrelevant. > That's probably what it comes down to in practice. If we *had* quad precision floats, it would be an easy solution, but we don't, so probably the Blaze proposal with 64 bit integers and a fixed tick unit is the easy way to go. Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
