On Tue, Jun 5, 2012 at 11:51 AM, Zachary Pincus <zachary.pincus@yale.edu>wrote:
> > It isn't just the array() calls which end up getting problems. For
> > example, in 1.5.x
> >
> > sage: f = 10; type(f)
> > <type 'sage.rings.integer.Integer'>
> > sage: numpy.arange(f)
> > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) #int64
> >
> > while in 1.6.x
> >
> > sage: numpy.arange(f)
> > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9], dtype=object)
> >
> > We also see problems with calls like
> >
> > sage: scipy.stats.uniform(0,15).ppf([0.5,0.7])
> > array([ 7.5, 10.5])
> >
> > which work in 1.5.x, but fail with a traceback "TypeError: array
> > cannot be safely cast to required type" in 1.6.x.
>> I'm getting problems like this after a 1.6 upgrade as well. Lots of object
> arrays being created when previously there would either be an error, or an
> array of floats.
>> Also, lots of the "TypeError: array cannot be safely cast to required
> type" are cropping up.
>> Honestly, most of these are in places where my code was lax and so I just
> cleaned things up to use the right dtypes etc. But still a bit unexpected
> in terms of having more code to fix than I was used to for 0.X numpy
> revisions.
>
There is a fine line here. We do need to make people clean up lax code in
order to improve numpy, but hopefully we can keep the cleanups reasonable.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120605/bbfb4f88/attachment.html