On Wed, Jan 2, 2013 at 11:24 AM, Nathaniel Smith n...@pobox.com wrote:
This discussion seems to have petered out without reaching consensus
one way or another. This seems like an important issue, so I've opened
a bug:
https://github.com/numpy/numpy/issues/2878
Hopefully this way we'll at
Consensus in that bug report seems to be that for array/scalar operations
like:
np.array([1], dtype=np.int8) + 1000 # can't be represented as an int8!
we should raise an error, rather than either silently upcasting the
result (as in 1.6 and 1.7) or silently downcasting the scalar (as in
On 01/04/2013 12:39 AM, Andrew Collette wrote:
Consensus in that bug report seems to be that for array/scalar operations
like:
np.array([1], dtype=np.int8) + 1000 # can't be represented as an int8!
we should raise an error, rather than either silently upcasting the
result (as in 1.6 and
On 3 Jan 2013 23:39, Andrew Collette andrew.colle...@gmail.com wrote:
Consensus in that bug report seems to be that for array/scalar
operations like:
np.array([1], dtype=np.int8) + 1000 # can't be represented as an int8!
we should raise an error, rather than either silently upcasting the
On Fri, Jan 4, 2013 at 12:11 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 01/04/2013 12:39 AM, Andrew Collette wrote:
Nathaniel Smith wrote:
Consensus in that bug report seems to be that for array/scalar operations
like:
np.array([1], dtype=np.int8) + 1000 # can't be
On 4 Jan 2013 00:39, Peter Cock p.j.a.c...@googlemail.com wrote:
I agree with Dag rather than Andrew, Explicit is better than implicit.
i.e. What Nathaniel described earlier as the apparent consensus.
Since I've actually used NumPy arrays with specific low memory
types, I thought I should
On Fri, Jan 4, 2013 at 12:39 AM, Peter Cock p.j.a.c...@googlemail.com wrote:
Since I've actually used NumPy arrays with specific low memory
types, I thought I should comment about my use case if case it
is helpful:
I've only used the low precision types like np.uint8 (unsigned) where
I
Hi Dag,
If neither is objectively better, I think that is a very good reason to
kick it down to the user. Explicit is better than implicit.
I agree with you, up to a point. However, we are talking about an
extremely common operation that I think most people (myself included)
would not expect
On Fri, Jan 4, 2013 at 12:49 AM, Nathaniel Smith n...@pobox.com wrote:
On 4 Jan 2013 00:39, Peter Cock p.j.a.c...@googlemail.com wrote:
I agree with Dag rather than Andrew, Explicit is better than implicit.
i.e. What Nathaniel described earlier as the apparent consensus.
Since I've actually
2013/1/3 Andrew Collette andrew.colle...@gmail.com:
Hi Dag,
If neither is objectively better, I think that is a very good reason to
kick it down to the user. Explicit is better than implicit.
I agree with you, up to a point. However, we are talking about an
extremely common operation that
Hi Olivier,
Another solution is to forget about trying to be smart and always
upcast the operation. That would be my 2nd preferred solution, but it
would make it very annoying to deal with Python scalars (typically
int64 / float64) that would be upcasting lots of things, potentially
breaking
On Thu, Jan 3, 2013 at 7:54 AM, Robin robi...@gmail.com wrote:
Hi All,
When using Numpy from an embedded Python (Python embedded in a Matlab
mex function) I get a lot of test failures (see attached log).
I am using CentOS 6.3, distribution packaged Python (2.6) and Numpy
(1.4.1). Running
Hello all,
In the Clojure community there has been some discussion about creating a
common matrix maths library / API. Currently there are a few different
fledgeling matrix libraries in Clojure, so it seemed like a worthwhile
effort to unify them and have a common base on which to build on.
On 02/01/2013 7:56 AM, Nathaniel Smith wrote:
On Fri, Dec 21, 2012 at 7:20 PM, Raul Cota r...@virtualmaterials.com wrote:
Hello,
On Dec/2/2012 I sent an email about some meaningful speed problems I was
facing when porting our core program from Numeric (Python 2.2) to Numpy
(Python 2.6). Some
On 02/01/2013 7:58 AM, Nathaniel Smith wrote:
On Wed, Jan 2, 2013 at 2:56 PM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Dec 21, 2012 at 7:20 PM, Raul Cota r...@virtualmaterials.com wrote:
b.1)
I noticed that PyFloat * Float64 resulted in an unnecessary on the fly
conversion of the
15 matches
Mail list logo
