On 04/01/2013 5:44 PM, Nathaniel Smith wrote:
> On Fri, Jan 4, 2013 at 11:36 PM, Raul Cota wrote:
>> On 04/01/2013 2:33 PM, Nathaniel Smith wrote:
>>> On Fri, Jan 4, 2013 at 6:50 AM, Raul Cota wrote:
On 02/01/2013 7:56 AM, Nathaniel Smith wrote:
> But, it's almost certainly possible to o
On Sat, 2013-01-05 at 00:17 +0100, Sebastian Berg wrote:
> Hey,
>
> this is probably just because I do not have any experience with bisect
> and the like, but when I try running a bisect keep running into:
>
Nevermind that. Probably I just stumbled on some bad versions...
> ImportError:
> /hom
On Fri, Jan 4, 2013 at 11:36 PM, Raul Cota wrote:
> On 04/01/2013 2:33 PM, Nathaniel Smith wrote:
>> On Fri, Jan 4, 2013 at 6:50 AM, Raul Cota wrote:
>>> On 02/01/2013 7:56 AM, Nathaniel Smith wrote:
But, it's almost certainly possible to optimize numpy's float64 (and
friends), so that
On 04/01/2013 2:33 PM, Nathaniel Smith wrote:
> On Fri, Jan 4, 2013 at 6:50 AM, Raul Cota wrote:
>> On 02/01/2013 7:56 AM, Nathaniel Smith wrote:
>>> But, it's almost certainly possible to optimize numpy's float64 (and
>>> friends), so that they are themselves (almost) as fast as the native
>>> py
Hey,
this is probably just because I do not have any experience with bisect
and the like, but when I try running a bisect keep running into:
ImportError:
/home/sebastian/.../lib/python2.7/site-packages/numpy/core/multiarray.so:
undefined symbol: PyDataMem_NEW
or:
RuntimeError: module compiled a
On Fri, Jan 4, 2013 at 6:50 AM, Raul Cota wrote:
>
> On 02/01/2013 7:56 AM, Nathaniel Smith wrote:
>> But, it's almost certainly possible to optimize numpy's float64 (and
>> friends), so that they are themselves (almost) as fast as the native
>> python objects. And that would help all the code tha
Hiall,
I am trying to embed numerical code in a mexFunction,
as called by MATLAB, written as a Cython function.
NumPy core functions and BLAS work fine, but calls to LAPACK
function such as SVD seem to be made against to MATLAB's linked
MKL, and this generates MKL errors. When I try this with
Oc
On Fri, Jan 4, 2013 at 11:09 AM, Matthew Brett wrote:
> In any case, can anyone remember the original use-cases well enough to
> record them for future decision making?
Heh. Everything new is old again. Here's a discussion from 2002 which
quotes the rationale:
http://mail.scipy.org/pipermail/nu
In my previous email I sent an image but I just thought that maybe the
mailing list does not accept attachments or need approval.
I put a couple of images related to my profiling results (referenced to
my previous email) here.
Sorted by time per function with a graph of calls at the bottom
ht
Hi,
> In fact in 1.6 there is no assignment of a dtype to '1' which makes
> the way 1.6 handles it consistent with the array rules:
I guess I'm a little out of my depth here... what are the array rules?
> # Ah-hah, it looks like '1' has a uint8 dtype:
> (np.ones(2, dtype=np.uint8) / np.ones(
Hi,
> (sorry, no time for full reply, so for now just answering what I
> believe is the main point)
Thanks for taking the time to discuss/explain this at all... I appreciate it.
> The evilness lies in the silent switch between the rollover and upcast
> behavior, as in the example I gave previous
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
wrote:
> Hi Olivier,
>
>> A key difference is that with arrays, the dtype is not chosen "just
>> big enough" for your data to fit. Either you set the dtype yourself,
>> or you're using the default inferred dtype (int/float). In both cases
>> you shou
Hi,
On Fri, Jan 4, 2013 at 4:01 PM, Andrew Collette
wrote:
> >From a more basic perspective, I think that adding a number to an
> array should never raise an exception. I've not used any other
> language in which this behavior takes place. In C, you have rollover
> behavior, in IDL you roll ove
(sorry, no time for full reply, so for now just answering what I
believe is the main point)
2013/1/4 Andrew Collette :
>> The ValueError is here to warn you that the operation may not be doing
>> what you want. The rollover for smaller values would be the documented
>> (and thus hopefully expected
Hi Olivier,
> A key difference is that with arrays, the dtype is not chosen "just
> big enough" for your data to fit. Either you set the dtype yourself,
> or you're using the default inferred dtype (int/float). In both cases
> you should know what to expect, and it doesn't depend on the actual
> n
Hello,
I posted some time ago that I need Numpy for .NET for a C# DLR app.
Has anyone made any progress on this?
May I suggest this as a project?
Thank you.
Sincerely,
William Johnston
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
htt
2013/1/4 Nathaniel Smith :
> On Fri, Jan 4, 2013 at 11:09 AM, Matthew Brett
> wrote:
>> Hi,
>>
>> Reading the discussion on the scalar casting rule change I realized I
>> was hazy on the use-cases that led to the rule that scalars cast
>> differently from arrays.
>>
>> My impression was that the
2013/1/3 Andrew Collette :
>> 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,
On 01/04/2013 02:46 PM, Nathaniel Smith wrote:
> On Fri, Jan 4, 2013 at 11:09 AM, Matthew Brett
> wrote:
>> Hi,
>>
>> Reading the discussion on the scalar casting rule change I realized I
>> was hazy on the use-cases that led to the rule that scalars cast
>> differently from arrays.
>>
>> My impr
On Fri, Jan 4, 2013 at 11:09 AM, Matthew Brett wrote:
> Hi,
>
> Reading the discussion on the scalar casting rule change I realized I
> was hazy on the use-cases that led to the rule that scalars cast
> differently from arrays.
>
> My impression was that the primary use-case was for lower-precisio
Hi,
Reading the discussion on the scalar casting rule change I realized I
was hazy on the use-cases that led to the rule that scalars cast
differently from arrays.
My impression was that the primary use-case was for lower-precision
floats. That is, when you have a large float32 arr, you do not wa
On 01/04/2013 09:00 AM, Dag Sverre Seljebotn wrote:
> On 01/04/2013 07:29 AM, Mike Anderson wrote:
>> 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
On 01/04/2013 07:29 AM, Mike Anderson wrote:
> 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
23 matches
Mail list logo
