On Wed, Jun 6, 2012 at 5:11 AM, Travis Oliphant wrote:
> During the original discussion, Gael pointed out that the changes would
> probably break some code (which might need to be cleaned up but still). I
> think it was underestimated how quickly people would upgrade and see the
> changes and t
>
> I don't think that would work, because looking more closely, I don't
> think they're actually doing anything like what
> __array_interface__/PEP3118 are designed for. They just have some
> custom class ("sage.rings.real_mpfr.RealLiteral", I guess an arbitrary
> precision floating point of some
During the original discussion, Gael pointed out that the changes would
probably break some code (which might need to be cleaned up but still). I
think it was underestimated how quickly people would upgrade and see the
changes and therefore be able to report problems.
We are talking about a
>> On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus
>> wrote:
>>>
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.
>>>
>>> Oh agreed. Somehow, though, I was surprised by this, even th
On Tue, Jun 5, 2012 at 7:47 PM, Ralf Gommers
wrote:
>
>
> On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus
> wrote:
>>
>> > 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.
>>
>> Oh agreed.
On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus wrote:
> > 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.
>
> Oh agreed. Somehow, though, I was surprised by this, even though I keep
> tabs on t
> 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.
Oh agreed. Somehow, though, I was surprised by this, even though I keep tabs on
the numpy lists -- at no point did it become clear that "big ch
On Tue, Jun 5, 2012 at 11:51 AM, Zachary Pincus wrote:
> > It isn't just the array() calls which end up getting problems. For
> > example, in 1.5.x
> >
> > sage: f = 10; type(f)
> >
> > sage: numpy.arange(f)
> > array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) #int64
> >
> > while in 1.6.x
> >
> > sage: nu
> It isn't just the array() calls which end up getting problems. For
> example, in 1.5.x
>
> sage: f = 10; type(f)
>
> 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
On Tue, Jun 5, 2012 at 8:34 AM, Nathaniel Smith wrote:
> I don't think that would work, because looking more closely, I don't
> think they're actually doing anything like what
> __array_interface__/PEP3118 are designed for. They just have some
> custom class ("sage.rings.real_mpfr.RealLiteral", I
On Mon, Jun 4, 2012 at 10:12 PM, Dag Sverre Seljebotn
wrote:
> On 06/04/2012 09:06 PM, Mike Hansen wrote:
>> On Mon, May 28, 2012 at 3:15 AM, Mike Hansen wrote:
>>> In trying to upgrade NumPy within Sage, we notices some differences in
>>> behavior between 1.5 and 1.6. In particular, in 1.5, we
On Mon, Jun 4, 2012 at 9:30 PM, Travis Oliphant wrote:
> Can you raise an issue on the Github issue tracker for NumPy? These issues
> will be looked at more closely. This kind of change should not have made it
> in to the release.
Thanks Travis! I've made this https://github.com/numpy/nump
Can you raise an issue on the Github issue tracker for NumPy? These issues
will be looked at more closely. This kind of change should not have made it
in to the release.
Given the lack of availability of time from enough experts in NumPy, this is
the sort of thing that can happen. I w
On 06/04/2012 09:06 PM, Mike Hansen wrote:
> On Mon, May 28, 2012 at 3:15 AM, Mike Hansen wrote:
>> In trying to upgrade NumPy within Sage, we notices some differences in
>> behavior between 1.5 and 1.6. In particular, in 1.5, we have
>>
>> sage: f = 0.5
>> sage: f.__array_interface__
>> {'typest
On Mon, May 28, 2012 at 3:15 AM, Mike Hansen wrote:
> In trying to upgrade NumPy within Sage, we notices some differences in
> behavior between 1.5 and 1.6. In particular, in 1.5, we have
>
> sage: f = 0.5
> sage: f.__array_interface__
> {'typestr': '=f8'}
> sage: numpy.array(f)
> array(0.5)
> sa
Hello,
In trying to upgrade NumPy within Sage, we notices some differences in
behavior between 1.5 and 1.6. In particular, in 1.5, we have
sage: f = 0.5
sage: f.__array_interface__
{'typestr': '=f8'}
sage: numpy.array(f)
array(0.5)
sage: numpy.array(float(f))
array(0.5)
In 1.6, we get the follo
16 matches
Mail list logo
