[Numpy-discussion] Difficulty using special types like timedelta and Decimal

[Benjamin Root]

On Fri, Sep 16, 2011 at 11:35 AM, Benjamin Root <ben.root at ou.edu> wrote:

>
>
> On Friday, September 16, 2011, Charles R Harris <charlesr.harris at gmail.com>
> wrote:
> >
> >
> > On Fri, Sep 16, 2011 at 9:11 AM, Benjamin Root <ben.root at ou.edu> wrote:
> >>
> >> Certain numerical types in Python that support accurate fractional
> calculations such as timedelta and Decimal do not allow for multiplication
> or division by a floating point number, but do allow for use with an
> integer.  This can cause difficulties with some functions such as
> np.gradient() which has a division by 2.0 as part of the algorithm.
> >>
> >> My question is: with Py3k's division always resulting in a floating
> point result regardless of the denominator's type, would it be possible to
> change some of these common denominators over to integers in order to better
> facilitate support for these special types?
> >>
> >> Obviously, I don't think we could expect full support of these types,
> but maybe a mechanism could be developed to better handle these?
> >>
> >
> > Timedelta seems to work in master:
> >
> > In [1]: timedelta64(5)
> > Out[1]: numpy.timedelta64(5)
> >
> > In [2]: timedelta64(5)/2.0
> > Out[2]: numpy.timedelta64(2)
> >
> > In [3]: timedelta64(5)/2
> > Out[3]: numpy.timedelta64(2)
> >
> > I think making the change to 2 is a reasonable thing to do, but you
> should put a
> >
> > from __future__ import division
> >
> > at the beginning of the module containing gradient and make sure
> everything still works.
> >
> > Chuck
> >
> >
>
> I am referring to a numpy array of python timedeltas, not numpy's.
>
> Ben Root


A couple of additional bugs I have encountered with np.gradient().  First,
the documentation says that the input data can be "array-like", yet the
first line of the function calls the shape() method (and later uses the
dtype() method).  Second, there is a check in the code that sees if the
input array is not 'd', 'f', 'D', or 'F'.  If it isn't one of those, then it
forces the output type to be 'd'.  I am not entirely sure I understand the
reasoning here, but at the very least, if I pass in an object array,
wouldn't it be expected that I get an object array back?

As an interesting sidenote, usually, one would expect the same type going in
as going out, however, with python datetime objects, datetime goes in and
timedeltas come out in functions like np.diff() and (theoretically)
np.gradient().  Don't know how much that would impact the prospect of
supporting python datetime and/or timedelta objects, but I thought I should
mention that.

Furthermore, in light of the recent addition of datetime to numpy itself,
maybe we ought to consider an automatic coercion of a list of python
datetime/timedelta objects into a numpy array of the numpy equivalents?  We
do this right now with lists of floats and integers.  Just a thought.

Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110916/aaa5982d/attachment.html>