Anne Archibald wrote:
> On 08/11/2007, David Cournapeau <[EMAIL PROTECTED]> wrote:
>
>> For copy and array creation, I understand this, but for element-wise
>> operations (mean, min, and max), this is not enough to explain the
>> difference, no ? For example, I can understand a 50 % or 100 % time
>
On 08/11/2007, David Cournapeau <[EMAIL PROTECTED]> wrote:
> For copy and array creation, I understand this, but for element-wise
> operations (mean, min, and max), this is not enough to explain the
> difference, no ? For example, I can understand a 50 % or 100 % time
> increase for simple operati
David Cournapeau wrote:
> Travis E. Oliphant wrote:
>
>> I wasn't talking about the min, mean, and max methods specifically.
>> These are all implemented with the reduce method of a ufunc.
>>
>>
> Ah, my mistake, I wrongly understood only some of them were implemented
> through ufunc
Travis E. Oliphant wrote:
>
> I wasn't talking about the min, mean, and max methods specifically.
> These are all implemented with the reduce method of a ufunc.
>
Ah, my mistake, I wrongly understood only some of them were implemented
through ufunc. But the ufunc machinery has nothing to do
David Cournapeau wrote:
> Travis E. Oliphant wrote:
>
>> Christopher Barker wrote:
>>
>>> This discussion makes me wonder if the basic element-wise operations
>>> could (should?) be special cased for contiguous arrays, reducing them to
>>> simple pointer incrementing from the start to t
Geoffrey Zhu wrote:
> On Nov 8, 2007 12:12 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>> Geoffrey Zhu wrote:
>>
>>> Good morning.
>>>
>>> I just installed the Windows binary of numpy 1.04. When I ran
>>> numpy.test() in IDLE (the Python shell that comes with Python), the
>>> program hang
Travis E. Oliphant wrote:
> Christopher Barker wrote:
>> This discussion makes me wonder if the basic element-wise operations
>> could (should?) be special cased for contiguous arrays, reducing them to
>> simple pointer incrementing from the start to the finish of the data
>> block. The same c
On Nov 8, 2007 11:32 AM, Michael McNeil Forbes <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> Is it possible or easy to add a warning and/or error when array
> assignments are made that lose information? I just got caught with
> the following type of code:
>
> def f():
> return numpy.array([1j,2.0])
>
Christopher Barker wrote:
> This discussion makes me wonder if the basic element-wise operations
> could (should?) be special cased for contiguous arrays, reducing them to
> simple pointer incrementing from the start to the finish of the data
> block. The same code would work for C and Fortran
Hans Meine wrote:
> Hi!
>
> I wonder why simple elementwise operations like "a * 2" or "a + 1" are not
> performed in order of increasing memory addresses in order to exploit CPU
> caches etc.
C-order is "special" in NumPy due to the history. I agree that it
doesn't need to be and we have taken
I often need to make a linear interpolation for a single scalar value
but this
is not very simple with numpy.interp :
>>> import numpy as n
>>> n.__version__
'1.0.5.dev4420'
>>> xp = n.arange(10)
>>> yp = 2.5 + xp**2 -x
>>> x = 3.2
>>> n.interp(x, xp, yp)
Traceback (most recent call last):
File "
On Donnerstag 08 November 2007, Christopher Barker wrote:
> This discussion makes me wonder if the basic element-wise operations
> could (should?) be special cased for contiguous arrays, reducing them to
> simple pointer incrementing from the start to the finish of the data
> block. The same code
On Nov 8, 2007 12:12 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> Geoffrey Zhu wrote:
> > Good morning.
> >
> > I just installed the Windows binary of numpy 1.04. When I ran
> > numpy.test() in IDLE (the Python shell that comes with Python), the
> > program hang (or at least is running for half a
On Thu, 08 Nov 2007 12:12:42 -0600
Robert Kern <[EMAIL PROTECTED]> wrote:
> Geoffrey Zhu wrote:
>> Good morning.
>>
>> I just installed the Windows binary of numpy 1.04. When
>>I ran
>> numpy.test() in IDLE (the Python shell that comes with
>>Python), the
>> program hang (or at least is runnin
On Nov 9, 2007 3:28 AM, Christopher Barker <[EMAIL PROTECTED]> wrote:
> This discussion makes me wonder if the basic element-wise operations
> could (should?) be special cased for contiguous arrays, reducing them to
> simple pointer incrementing from the start to the finish of the data
> block.
I
Hi,
Is it possible or easy to add a warning and/or error when array
assignments are made that lose information? I just got caught with
the following type of code:
def f():
return numpy.array([1j,2.0])
x = numpy.empty((2,),dtype=float)
x[:] = f()
I am pre-allocating arrays for speed, b
This discussion makes me wonder if the basic element-wise operations
could (should?) be special cased for contiguous arrays, reducing them to
simple pointer incrementing from the start to the finish of the data
block. The same code would work for C and Fortran order arrays, and be
pretty simp
Geoffrey Zhu wrote:
> Good morning.
>
> I just installed the Windows binary of numpy 1.04. When I ran
> numpy.test() in IDLE (the Python shell that comes with Python), the
> program hang (or at least is running for half an hour). I am using
> Windows XP, duel core intel CPU.
>
> Does anyone know
On Nov 9, 2007 1:55 AM, Hans Meine <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 08. November 2007 17:31:40 schrieb David Cournapeau:
> > This is because the current implementation for at least some of the
> > operations you are talking about are using PyArray_GenericReduce and
> > other similar func
Am Donnerstag, 08. November 2007 17:31:40 schrieb David Cournapeau:
> This is because the current implementation for at least some of the
> operations you are talking about are using PyArray_GenericReduce and
> other similar functions, which are really high level (they use python
> callable, etc..)
On Nov 9, 2007 1:31 AM, David Cournapeau <[EMAIL PROTECTED]> wrote:
> On Nov 9, 2007 12:50 AM, Hans Meine <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag, 08. November 2007 16:37:06 schrieb David Cournapeau:
> > > The problem is not F vs C storage: for element-wise operation, it does
> > > not matter
On Nov 9, 2007 12:50 AM, Hans Meine <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 08. November 2007 16:37:06 schrieb David Cournapeau:
> > The problem is not F vs C storage: for element-wise operation, it does
> > not matter at all; you just apply the same function
> > (perform_operation) over and ov
Good morning.
I just installed the Windows binary of numpy 1.04. When I ran
numpy.test() in IDLE (the Python shell that comes with Python), the
program hang (or at least is running for half an hour). I am using
Windows XP, duel core intel CPU.
Does anyone know what is going on?
Thanks,
Geoffrey
Am Donnerstag, 08. November 2007 16:37:06 schrieb David Cournapeau:
> The problem is not F vs C storage: for element-wise operation, it does
> not matter at all; you just apply the same function
> (perform_operation) over and over on every element of the array. The
> order does not matter at all.
Am Donnerstag, 08. November 2007 16:25:57 schrieb Martin Teichmann:
> Some more thoughts:
> * Other implementations: There is other people who have done such a thing.
> the PIL knows how to read and write PNG, but only 8 bit. The same holds
> for matplotlib.
Our VIGRA imaging library can read and
On Nov 8, 2007 10:13 PM, Hans Meine <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 08. November 2007 13:44:59 schrieb David Cournapeau:
> > Hans Meine wrote:
> > > I wonder why simple elementwise operations like "a * 2" or "a + 1" are
> > > not performed in order of increasing memory addresses in orde
Hi all,
i am working with numpy and mostly 16 bit matrices, and so I was looking
for a standard way of saving them. I found that PNG actually supports
that, but I could not find a way to use this feature from within
python. I thought that it actually is a cool way of storing matrices
and thus I wr
On Nov 8, 2007 3:28 AM, Sebastian Haase <[EMAIL PROTECTED]> wrote:
> On Nov 7, 2007 6:46 PM, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > On Nov 7, 2007 10:35 AM, Sebastian Haase <[EMAIL PROTECTED]> wrote:
> > >
> > > On Nov 7, 2007 5:23 PM, Matthieu Brucher <[EMAIL PROTECTED]>
Am Donnerstag, 08. November 2007 13:44:59 schrieb David Cournapeau:
> Hans Meine wrote:
> > I wonder why simple elementwise operations like "a * 2" or "a + 1" are
> > not performed in order of increasing memory addresses in order to exploit
> > CPU caches etc. - as it is now, their speed drops by a
Hans Meine wrote:
> Hi!
>
> I wonder why simple elementwise operations like "a * 2" or "a + 1" are not
> performed in order of increasing memory addresses in order to exploit CPU
> caches etc. - as it is now, their speed drops by a factor of around 3 simply
> by transpose()ing.
Because it is no
Hi!
I wonder why simple elementwise operations like "a * 2" or "a + 1" are not
performed in order of increasing memory addresses in order to exploit CPU
caches etc. - as it is now, their speed drops by a factor of around 3 simply
by transpose()ing. Similarly (but even less logical), copy() and
On Nov 7, 2007 6:46 PM, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Nov 7, 2007 10:35 AM, Sebastian Haase <[EMAIL PROTECTED]> wrote:
> >
> > On Nov 7, 2007 5:23 PM, Matthieu Brucher <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > I don't understand. I'm thinking of most math functions in t
32 matches
Mail list logo