On 02/01/2013 7:58 AM, Nathaniel Smith wrote:
> On Wed, Jan 2, 2013 at 2:56 PM, Nathaniel Smith wrote:
>> On Fri, Dec 21, 2012 at 7:20 PM, Raul Cota wrote:
>>> b.1)
>>> I noticed that PyFloat * Float64 resulted in an unnecessary "on the fly"
>>> conversion of the PyFloat into a Float64 to extrac
On 02/01/2013 7:56 AM, Nathaniel Smith wrote:
On Fri, Dec 21, 2012 at 7:20 PM, Raul Cota 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 of our tests went from 30
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.
NumPy
On Thu, Jan 3, 2013 at 7:54 AM, Robin 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 numpy tests f
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
> brea
2013/1/3 Andrew Collette :
> 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 pe
On Fri, Jan 4, 2013 at 12:49 AM, Nathaniel Smith wrote:
> On 4 Jan 2013 00:39, "Peter Cock" 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 speci
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 expe
On Fri, Jan 4, 2013 at 12:39 AM, Peter Cock 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 needed to limit my
On 4 Jan 2013 00:39, "Peter Cock" 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 comment about my use
On Fri, Jan 4, 2013 at 12:11 AM, Dag Sverre Seljebotn
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 represented as
On 3 Jan 2013 23:39, "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
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
> 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 i
On Wed, Jan 2, 2013 at 11:24 AM, Nathaniel Smith 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 least not fo
15 matches
Mail list logo
