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

Benjamin Root ben.root@ou....
Fri Sep 16 13:20:41 CDT 2011


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

>
>
> On Friday, September 16, 2011, Charles R Harris <charlesr.harris@gmail.com>
> wrote:
> >
> >
> > On Fri, Sep 16, 2011 at 9:11 AM, Benjamin Root <ben.root@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.scipy.org/pipermail/numpy-discussion/attachments/20110916/aaa5982d/attachment.html 


More information about the NumPy-Discussion mailing list