On Wed, Jun 6, 2012 at 5:11 AM, Travis Oliphant tra...@continuum.io 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
On Mon, Jun 4, 2012 at 10:12 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 06/04/2012 09:06 PM, Mike Hansen wrote:
On Mon, May 28, 2012 at 3:15 AM, Mike Hansenmhan...@gmail.com wrote:
In trying to upgrade NumPy within Sage, we notices some differences in
behavior between 1.5
On Tue, Jun 5, 2012 at 8:34 AM, Nathaniel Smith n...@pobox.com 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
On Tue, Jun 5, 2012 at 11:51 AM, Zachary Pincus zachary.pin...@yale.eduwrote:
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])
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
On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus zachary.pin...@yale.eduwrote:
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
On Tue, Jun 5, 2012 at 7:47 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus zachary.pin...@yale.edu
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
On Tue, Jun 5, 2012 at 8:41 PM, Zachary Pincus zachary.pin...@yale.edu
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
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
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
On Mon, May 28, 2012 at 3:15 AM, Mike Hansen mhan...@gmail.com 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)
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.
off-topic
Given the lack of availability of time from enough experts in NumPy, this is
the sort of thing that can
On Mon, Jun 4, 2012 at 9:30 PM, Travis Oliphant tra...@continuum.io 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
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
14 matches
Mail list logo
