[egenix-users] mx.DateTime 3.2.x and numpy

[M.-A. Lemburg]

Christian Marquardt wrote:
> Hello,
> 
> I hope this is the right place to ask this question...
> 
> We are in the process of upgrading our mx.Base installation from 3.1.3 to 3.2.1, and while testing, we ran into a problem with the following script (which is also attached)::
> 
>    import numpy       as np
>    import mx.DateTime as dt
> 
>    print "Numpy version:   ", np.__version__
>    print "DateTime version:", dt.__version__
> 
>    delta_t = np.arange(5) * dt.oneHour
>    t0 = dt.now()
> 
>    t = t0 + delta_t
> 
>    print t
> 
> For mx.DateTime v3.1.3 (was the version string ever updated in the release?), the output is as expected:
> 
>    TCLXS9 (mx) /homespace/marq/python/work/mx>python ../object_arrays/mx_problem.py 
>    Numpy version:    1.5.1
>    DateTime version: 3.1.2
>    [2011-12-11 22:39:38.60 2011-12-11 23:39:38.60 2011-12-12 00:39:38.60
>     2011-12-12 01:39:38.60 2011-12-12 02:39:38.60]
> 
> i.e. the addition of a single mx.DateTime object and a numpy array of mx.DateTimeDelta objects just works. But in v3.2.0 and later, we get
> 
>    TCLXS9 (mx) /homespace/marq/python/work/mx>python ../object_arrays/mx_problem.py 
>    Numpy version:    1.5.1
>    DateTime version: 3.2.1
>    Traceback (most recent call last):
>      File "../object_arrays/mx_problem.py", line 12, in <module>
>        t = t0 + delta_t
>    TypeError: only length-1 arrays can be converted to Python scalars
> 
> This is independent from the numpy version (it fails with the more recent numpy 1.6.1 as well), so I think the problem is in mx.DateTime. It also surfaces in other circumstances, for example when trying to compare as scalar mx.DateTime object with an array of such objects.
> 
> A workaround is to wrap the mx.DateTime scalar in an np.asarray() - but I think it's a bug anyway - and we have a large number of uses cases like the two described, so I would prefer if there would be a way to fix it within mx.DateTime.
> 
> Any ideas what introduced this bug in 3.2.0?

I'm not sure it's a bug. In mxDateTime 3.2 we replaced the old
coercion hack we'd been using in the days before our coercion
patches got integrated into Python, with the new methods.

Since the error is created by numpy, it looks like numpy is not
aware of the change. If there's something we can do to help,
let me know.

-- 
Marc-Andre Lemburg
eGenix.com Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/