Hi, Travis
I can pack my scripts into an executable with py2exe, but errors occur
once it runs:
No scipy-style subpackage 'random' found in D:\test\dist\numpy.
Ignoring: No module named info
import core -> failed: No module named _internal
import lib -> failed: 'module' object has no attribute '_
Travis Oliphant wrote:
> Christopher Barker wrote:
>> HI all,
>>
>> File
>> "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py",
>> line 2814, in SetDataBuffer
>> return _core_.Image_SetDataBuffer(*args, **kwargs)
>> TypeError: non-character array cannot be interpreted as chara
Folks,
I keep running into the following problem since some recent update (I'm
currently running 1.0b3, but the problem occurred roughly around 0.9.8):
>>> import numpy.core.ma as MA
>>> x=MA.array([[1],[2]],mask=False)
>>> x.sum(None)
/usr/lib64/python2.4/site-packages/numpy/core/ma.py in reduc
On 8/29/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Example:
>
> If a.shape is (3,4,5)
> and b.shape is (4,3,2)
>
> Then
>
> tensordot(a, b, axes=([1,0],[0,1]))
>
> returns a (5,2) array which is equivalent to the code:
>
> c = zeros((5,2))
> for i in range(5):
> for j in range(2):
>
Simon Burton wrote:
numpy.dot.__doc__
> matrixproduct(a,b)
> Returns the dot product of a and b for arrays of floating point types.
> Like the generic numpy equivalent the product sum is over
> the last dimension of a and the second-to-last dimension of b.
> NB: The first argumen
> The C-code is basically a directy "translation" of the original Python
> code.
...
> If I had to do it over again, I would place the std implementation there where
> it could be appropriately optimized.
Isn't C-code a good place for optimizations?
//Torgil
On 8/27/06, Travis Oliphant <[EMAIL
This is really a matplotlib problem.
>From matplotlib users mailing-list archives:
> From: Charlie Moad <[EMAIL PROTECTED]>
> Snapshot build for use with numpy-1.0b3
> 2006-08-23 06:11
>
> Here is a snapshot of svn this morning for those wanting to work with
the numpy beta. Both builds are for
Christopher Barker wrote:
> While I'm a great advocate of the new array protocol, it seems
> supporting the buffer protocol also would be a good idea. I've enclosed
> some simple test code. It works with numarray, but not numpy 1.0b4
Instead of
I.SetDataBuffer(some_array)
you can use
I
Christopher Barker wrote:
> HI all,
>
> File
> "/usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core.py",
> line 2814, in SetDataBuffer
> return _core_.Image_SetDataBuffer(*args, **kwargs)
> TypeError: non-character array cannot be interpreted as character buffer
>
> If I try to pass
HI all,
Robin Dunn has been working on adding better support for dumping data
directly to wxPython from the num* packages. I've been talking to him
about the new array interface, and he might well support it
(particularly if one of us contributes code), but in the meantime, he's
got a number
Travis Oliphant wrote:
> I think I prefer to just add the float, bool, object, unicode, str names
> to the "non-imported" numpy
> name-space.
which mean you get it with:
import numpy as N
N.float
but not with
from numpy import *
?
If that's what you mean, then I'm all for it!
-Chris
--
[EMAIL PROTECTED] wrote:
> On 8/25/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>> [EMAIL PROTECTED] wrote:
>>
>>> Message: 4
>>> Date: Thu, 24 Aug 2006 14:17:44 -0600
>>> From: Travis Oliphant <[EMAIL PROTECTED]>
>>> Subject: Re: [Numpy-discussion] (no subject)
>>> To: Discussion of Nu
On 8/25/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Message: 4
> > Date: Thu, 24 Aug 2006 14:17:44 -0600
> > From: Travis Oliphant <[EMAIL PROTECTED]>
> > Subject: Re: [Numpy-discussion] (no subject)
> > To: Discussion of Numerical Python
> >
> > Message-I
Hi all!I'm rewriting some swig-based extensions that implement intensive inner loops dealing with numeric/numpy arrays. The intention is to build these extensions by means of weave inline, ext_module, ext_function, etc. I'm not sure about how to point weave to my numpy instalation. By default it tr
Andrew Straw wrote:
> The following code indicates there is a problem adding a numpy scalar
> type to a Numeric array. Is this expected behavior or is there a bug
> somewhere?
>
There was a bug in the __array_struct__ attribute of array flags wherein
the NOTSWAPPED flag was not being set as it
Travis Oliphant <[EMAIL PROTECTED]> [2006-08-28 12:42]:
> rex wrote:
> > ImportError: /usr/lib/python2.4/site-packages/numpy/core/multiarray.so:
> > undefined symbol: PyUnicodeUCS2_FromUnicode
> >
> >
> >
>
> This error usually means that NumPy was built and linked against a
> Python build wh
The following code indicates there is a problem adding a numpy scalar
type to a Numeric array. Is this expected behavior or is there a bug
somewhere?
This bit me in the context of updating some of my code to numpy, while
part of it still uses Numeric.
import Numeric
import numpy
print 'Numeric._
Christopher Barker wrote:
> Travis Oliphant wrote:
>
>
>> Instead, I like better the idea of adding abs, round, max, and min to
>> the "non-import-*" namespace of numpy.
>>
>
> Another I'd like is the built-in data types. I always use:
>
> import numpy as N
>
> so then I do:
>
> a = zeros(
rex wrote:
> Numpy builds, but fails to run with the error message:
>
>
>> python
>>
> Python 2.4.2 (#1, Apr 24 2006, 18:13:30)
> [GCC 4.1.0 (SUSE 10.1 Linux)] on linux2
>
import numpy
> Traceback (most recent call last):
> File "", line 1, in ?
> File "/usr/lib/py
Travis Oliphant wrote:
> Instead, I like better the idea of adding abs, round, max, and min to
> the "non-import-*" namespace of numpy.
Another I'd like is the built-in data types. I always use:
import numpy as N
so then I do:
a = zeros(shape, float)
or
a = zeros(shape, N.float_)
but for non
Numpy builds, but fails to run with the error message:
> python
Python 2.4.2 (#1, Apr 24 2006, 18:13:30)
[GCC 4.1.0 (SUSE 10.1 Linux)] on linux2
>>> import numpy
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/site-packages/numpy/__init__.py", line 35, in ?
>>Matt Knox wrote:>>> Hi there. I'm in the unfortunate situation of trying to track down a >> memory error in someone elses code, and to make matters worse I don't >> really know jack squat about C programming. The problem seems to arise >> when several numpy arrays are created from C arrays in t
Nope, that's the way python works in general for any type other than
basic scalar types.
>>> a = [1,2,3,4]
>>> b = a
>>> b[1] = 99
>>> print a
[1, 99, 3, 4]
>>> print b
[1, 99, 3, 4]
Also the issue never comes up for types like tuples or strings because
they aren't mutable.
--bb
On 8/28/06, Sven
Charles R Harris schrieb:
> +1. I too suspect that what you have here is a reference/copy problem.
> The only thing that is local to the class is the reference (pointer),
> the data is global.
>
> Chuck
Ok, so you guys were right, turns out that my problem was caused by the
fact that a local assi
Martin Spacek wrote:
>
> Actually, your original version is just as fast as the take() version.
> Both are about 9X faster than numpy.mean() on my system. I prefer the
> take() version because you only have to pass a single argument to
> mean_accum()
I forgot to mention that all my indices ar
Tim Hochberg wrote:
> I'm actually surprised that the take version is faster than my original
> version since it makes a big ol' copy. I guess this is an indication
> that indexing is more expensive than I realize. That's why nothing beats
> measuring!
Actually, your original version is just
26 matches
Mail list logo
