Chuck, I provided a little more context in another email. The user is using numpy 1.6.1 with python 2.6. I asked him to try an earlier version -- we'll see how it goes. This is code that has worked for a long time. It still works on my laptop and on our test platforms.
The behavior on the user's system appears to be consistent, as far as I can tell. -Bill On Feb 16, 2012, at 11:50 PM, Charles R Harris wrote: > On Thu, Feb 16, 2012 at 10:09 AM, Spotz, William F <wfsp...@sandia.gov> wrote: > I have a user who is reporting tests that are failing on his platform. I > have not been able to reproduce the error on my system, but working with him, > we have isolated the problem to unexpected results when PyArray_FromObject() > is called. Here is the chain of events: > > In python, an integer is calculated. Specifically, it is > > len(result.errors) + len(result.failures) > > where result is a unit test result object from the unittest module. I had > him verify that this value was in fact a python integer. In my extension > module, this PyObject gets passed to the PyArray_FromObject() function in a > routine that comes from numpy.i. What I expect, and what I typically get, is > a numpy scalar array of type C long. I had my user print the result using > PyObject_Print() and what he got was > > array([0:00:00], dtype=timedelta64[us]) > > > That's strange. Is the output always a zero and the type a timedelta64? In > the absence of better info I'd quess a stray pointer or, unlikely, byte > order. The numpy version would be nice to know. If you have an old version of > numpy you could also give it a shot to see what happens. > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion