[Numpy-discussion] The date/time dtype and the casting issue

[Ivan Vilata i Balaguer]

Pierre GM (el 2008-07-29 a les 12:38:19 -0400) va dir::

> > Relative time versus relative time
> > ----------------------------------
> >
> > This case would be the same than the previous one (absolute vs
> > absolute).  Our proposal is to forbid this operation if the time units
> > of the operands are different.  
> 
> Mmh, less sure on this one. Can't we use a hierarchy of time units, and force 
> to the lowest ? 
> For example:
> >>>numpy.ones(3, dtype="t8[Y]") + 3*numpy.ones(3, dtype="t8[M]")
> >>>array([15,15,15], dtype="t8['M']")
> 
> I agree that adding ns to years makes no sense, but ns to s ? min to
> hr or days ?  In short: systematically raising an exception looks a
> bit too drastic. There are some simple unambiguous cases that sould be
> allowed (Y+M, Y+Q, M+Q, H+D...)

Do you mean using the most precise unit for operations with "near
enough", different units?  I see the point, but what makes me doubt
about it is giving the user the false impression that the most precise
unit is *always* expected.  I'd rather spare the user as many surprises
as possible, by simplifying rules in favour of explicitness (but that
may be debated).

> > Introducing a time casting function
> > -----------------------------------
> 
> > change_unit(time_object, new_unit, reference)
> >
> > where 'time_object' is the time object whose unit is to be
> > changed, 'new_unit' is the desired new time unit, and 'reference' is an
> > absolute date that will be used to allow the conversion of relative
> > times in case of using time units with an uncertain number of smaller
> > time units (relative years or months cannot be expressed in days).  
> 
> reference default to the POSIX epoch, right ?
> So this function could be a first step towards our problem of frequency 
> conversion...
> 
> > Note: we refused to use the ``.astype()`` method because of the
> > additional 'time_reference' parameter that will sound strange for other
> > typical uses of ``.astype()``.
> 
> A method would be really, really helpful, though...
> [...]

Yay, but what doesn't seem to fit for me is that the method would only
have sense to time values.  NumPy is pretty orthogonal in that every
method and attribute applies to every type.  However, if "units" were to
be adopted by NumPy, the method would fit in well.  In fact, we are
thinking of adding a ``unit`` attribute to dtypes to support time units
(being ``None`` for normal NumPy types).  But full unit support in NumPy
looks so far away that I'm not sure to adopt the method.

Thanks for the insights.  Cheers,

::

  Ivan Vilata i Balaguer   @ Intellectual Monopoly hinders Innovation! @
  http://www.selidor.net/  @     http://www.nosoftwarepatents.com/     @
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080729/e9855e19/attachment.sig>