numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] upcast

[Lars F. <lfr...@im...>]

> To answer the original question, you need to use a higher precision
> array or explicitly cast it to higher precision.
> 
> In [49]:(a.astype(int)*100)/100 
> Out[49]:array([200])

Thank you. This is what I wanted to know.

Lars

Re: [Numpy-discussion] Use of numarray from numpy package [# INC NO 24609]

[Sebastian H. <ha...@ms...>]

Andrew Straw wrote:
> LANDRIU David SAp wrote:
>> Hello,
>>   
>>   I come back to my question : how to use numarray 
>>  with the numpy installation ? 
>>   
>> {ccali22}~(0)>setenv PYTHONPATH /usr/local/lib/python2.3/site-packages/numpy
>>   
> Here's where you went wrong. You want:
> 
> setenv PYTHONPATH /usr/local/lib/python2.3/site-packages
> 
>> {ccali22}~(0)>python
>> Python 2.3.5 (#2, Oct 17 2005, 17:20:02)
>> [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-52)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>   
>>>>> from numarray import *
>>>>>         
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>   File "/usr/local/lib/python2.3/site-packages/numpy/numarray/__init__.py", line 1, in ?
>>     from util import *
>>   File "/usr/local/lib/python2.3/site-packages/numpy/numarray/util.py", line 2, in ?
>>     from numpy import geterr
>> ImportError: No module named numpy
>>   
> 
> Note that you're actually importing a numarray within numpy's directory
> structure. That's because of your PYTHONPATH. numpy ships numpy.numarray
> to provide backwards compatibility. To use it, you must do "import
> numpy.numarray as numarray"
> 

Just to explain -- there is only a numarray directory inside numpy
to provide some special treatment for people that do the transition from 
numarray to numpy  - meaning: they can do somthing like
from numpy import numarray
and get a "numpy(!) version"  that behaves more like numarray than the 
straight numpy ...

Similar for
"from numarray import oldnumaric as Numeric" (for people coming from 
Numeric )

Yes - it is actually confusing, but that's the baggage when there are 2 
(now 3) numerical python packages is human history.
The future will be much brighter  - forget all of the above, and just use
import numpy
(I like "import numpy as N" for less typing - others prefer even
"from numpy import *"
)

Hope that helps,
- Sebastian Haase

Re: [Numpy-discussion] amd64 support

[Sebastian H. <ha...@ms...>]

Keith Goodman wrote:
> I plan to build an amd64 box and run debian etch. Are there any big,
> 64-bit, show-stopping problems in numpy? Any minor annoyances?
> 
I am not aware of any - we use fine on 32bit and 64bit with debian sarge 
and etch.
-Sebastian Haase

Re: [Numpy-discussion] upcast

[Charles R H. <cha...@gm...>]

On 8/30/06, Lars Friedrich <lfr...@im...> wrote:
>
> Hello,
>
> I would like to discuss the following code:
>
> #***start***
> import numpy as N
>
> a = N.array((200), dtype = N.uint8)
> print (a * 100) / 100
>
> b = N.array((200, 200), dtype = N.uint8)
> print (b * 100) / 100
> #***stop***
>
> The first print statement will print "200" because the uint8-value is
> cast "upwards", I suppose. The second statement prints "[0 0]". I
> suppose this is due to overflows during the calculation.
>
> How can I tell numpy to do the upcast also in the second case, returning
> "[200 200]"? I am interested in the fastest solution regarding execution
> time. In my application I would like to store the result in an
> Numeric.UInt8-array.
>
> Thanks for every comment


To answer the original question, you need to use a higher precision array or
explicitly cast it to higher precision.

In [49]:(a.astype(int)*100)/100
Out[49]:array([200])

Chuck

Re: [Numpy-discussion] upcast

[Charles R H. <cha...@gm...>]

On 8/30/06, Lars Friedrich <lfr...@im...> wrote:
>
> Hello,
>
> I would like to discuss the following code:
>
> #***start***
> import numpy as N
>
> a = N.array((200), dtype = N.uint8)
> print (a * 100) / 100


This is actually a scalar, i.e., a zero dimensional array. N.uint8(200)
would give you the same thing, because (200) is a number, not a tuple like
(200,). In any case

In [44]:a = array([200], dtype=uint8)
In [45]:a*100
Out[45]:array([32], dtype=uint8)
In [46]:uint8(100)*100
Out[46]:10000

i.e. , the array arithmetic is carried out in mod 256 because Numpy keeps
the array type when multiplying by scalars. On the other hand, when
multiplying a *scalar* by a number, the lower precision scalars are
upconverted in the conventional way. Numpy makes the choices it does for
space efficiency. If you want to work in uint8 you don't have to recast
every time you multiply by a small integer. I suppose one could demand using
uint8(1) instead of 1, but the latter is more convenient.

Integers can be tricky once the ordinary precision is exceeded and modular
arithmetic takes over, it just happens more easily for uint8 than for
uint32.

Chuck

Re: [Numpy-discussion] Changing Fatal error into ImportError?

[Fernando P. <fpe...@gm...>]

On 8/30/06, Robert Kern <rob...@gm...> wrote:

> I don't see where we're calling Py_FatalError. The problem might be in Python or
> mwadap. Indeed, import_array() raises a PyExc_ImportError.

Sorry for the noise: it looks like this was already fixed:

http://projects.scipy.org/scipy/numpy/changeset/3044

since the code causing problems had been built /before/ 3044, we got
the FatalError.

But with modules built post-3044, it's all good (I artificially hacked
the number to force the error):

In [1]: import mwadap
Overwriting info=<function info at 0x4158402c> from scipy.misc (was
<function info at 0x4067410c> from numpy.lib.utils)
---------------------------------------------------------------------------
exceptions.RuntimeError                              Traceback (most
recent call last)


RuntimeError: module compiled against version 1000001 of C-API but
this version of numpy is 1000002
---------------------------------------------------------------------------
exceptions.ImportError                               Traceback (most
recent call last)

/home/fperez/research/code/mwadap-merge/mwadap/test/<ipython console>

/home/fperez/usr/lib/python2.3/site-packages/mwadap/__init__.py
      9 glob,loc = globals(),locals()
     10 for name in __all__:
---> 11     __import__(name,glob,loc,[])
     12
     13 # Namespace cleanup

/home/fperez/usr/lib/python2.3/site-packages/mwadap/Operator.py
     18
     19 # Our own packages
---> 20 import mwrep
     21 from mwadap import mwqmfl, utils, Function, flinalg
     22

ImportError: numpy.core.multiarray failed to import

In [2]:


Cheers,

f

Re: [Numpy-discussion] Changing Fatal error into ImportError?

[Robert K. <rob...@gm...>]

Fernando Perez wrote:
> Hi all,
> 
> this was mentioned in the past, but I think it fell through the cracks:
> 
> Python 2.3.4 (#1, Mar 10 2006, 06:12:09)
> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import mwadap
> Overwriting info=<function info at 0xb77198b4> from scipy.misc (was
> <function info at 0xb7704bc4> from numpy.lib.utils)
> RuntimeError: module compiled against version 90909 of C-API but this
> version of numpy is 1000002
> Fatal Python error: numpy.core.multiarray failed to import... exiting.
> 
> I really think that this should raise ImportError, but NOT kill the
> python interpreter.  If this happens in the middle of a long-running
> interactive session, you'll lose all of your current state/work, where
> a simple ImportError would have been enough to tell you that this
> particular module needed recompilation.
> 
> FatalError should be reserved for situations where the internal state
> of the Python VM itself can not realistically be expected to be sane
> (corruption, complete memory exhaustion for even internal allocations,
> etc.)  But killing the user's session for a failed import is a bit
> much, IMHO.

I don't see where we're calling Py_FatalError. The problem might be in Python or 
mwadap. Indeed, import_array() raises a PyExc_ImportError.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[Numpy-discussion] Changing Fatal error into ImportError?

[Fernando P. <fpe...@gm...>]

Hi all,

this was mentioned in the past, but I think it fell through the cracks:

Python 2.3.4 (#1, Mar 10 2006, 06:12:09)
[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import mwadap
Overwriting info=<function info at 0xb77198b4> from scipy.misc (was
<function info at 0xb7704bc4> from numpy.lib.utils)
RuntimeError: module compiled against version 90909 of C-API but this
version of numpy is 1000002
Fatal Python error: numpy.core.multiarray failed to import... exiting.

I really think that this should raise ImportError, but NOT kill the
python interpreter.  If this happens in the middle of a long-running
interactive session, you'll lose all of your current state/work, where
a simple ImportError would have been enough to tell you that this
particular module needed recompilation.

FatalError should be reserved for situations where the internal state
of the Python VM itself can not realistically be expected to be sane
(corruption, complete memory exhaustion for even internal allocations,
etc.)  But killing the user's session for a failed import is a bit
much, IMHO.

Cheers,

f

Re: [Numpy-discussion] stumped numpy user seeks help

[Bill B. <wb...@gm...>]

On 8/30/06, Sven Schreiber <sve...@gm...> wrote:
> Mathew Yeates schrieb:
> will be a numpy matrix, use <asarray> if you don't like that. But here
> it's really nice to work with matrices, because otherwise .sum() will
> give you a 1-d array sometimes, and that will suddenly look like a row
> to <hstack> (instead of a nice column vector) and wouldn't work --
> that's why matrices are so great and everybody should be using them ;-)

column_stack would work perfectly in place of hstack there if it only
didn't have the silly behavior of transposing arguments that already
are 2-d.

For reminders, here's the replacement implementation of column_stack I
proposed on July 21:

def column_stack(tup):
   def transpose_1d(array):
        if array.ndim<2: return _nx.transpose(atleast_2d(array))
        else: return array
   arrays = map(transpose_1d,map(atleast_1d,tup))
   return _nx.concatenate(arrays,1)

This was in a big ticket I submitted about overhauling r_,c_,etc,
which was largely ignored.  Maybe I should resubmit this by itself...

--bb

[Numpy-discussion] (no subject)

[Thilo W. <thi...@gm...>]

Hi,
currently I´m trying to compile the latest numpy version (1.0b4) under an SGI IRIX 6.5 environment. I´m using the gcc 3.4.6 compiler and python 2.4.3 (self compiled). During the compilation of numpy.core I get a nasty error message:

...
copying build/src.irix64-6.5-2.4/numpy/__config__.py -> build/lib.irix64-6.5-2.4/numpy
copying build/src.irix64-6.5-2.4/numpy/distutils/__config__.py -> build/lib.irix64-6.5-2.4/numpy/distutils
running build_ext
customize UnixCCompiler
customize UnixCCompiler using build_ext
customize MipsFCompiler
customize MipsFCompiler
customize MipsFCompiler using build_ext
building 'numpy.core.umath' extension
compiling C sources
C compiler: gcc -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -fmessage-length=0 -Wall -O2

compile options: '-Ibuild/src.irix64-6.5-2.4/numpy/core/src -Inumpy/core/include -Ibuild/src.irix64-6.5-2.4/numpy/core -Inumpy/core/src -Inumpy/core/include -I/usr/local/include/python2.4 -c'
gcc: build/src.irix64-6.5-2.4/numpy/core/src/umathmodule.c
numpy/core/src/umathmodule.c.src: In function `nc_sqrtf':
numpy/core/src/umathmodule.c.src:602: warning: implicit declaration of function `hypotf'
numpy/core/src/umathmodule.c.src: In function `nc_sqrtl':
numpy/core/src/umathmodule.c.src:602: warning: implicit declaration of function `fabsl'
...
... lots of math functions ...
...
numpy/core/src/umathmodule.c.src: In function `LONGDOUBLE_frexp':
numpy/core/src/umathmodule.c.src:1940: warning: implicit declaration of function `frexpl'
numpy/core/src/umathmodule.c.src: In function `LONGDOUBLE_ldexp':
numpy/core/src/umathmodule.c.src:1957: warning: implicit declaration of function `ldexpl'
In file included from numpy/core/src/umathmodule.c.src:2011:
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c: At top level:
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:15: error: `acosl' undeclared here (not in a function)
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:15: error: initializer element is not constant
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:15: error: (near initialization for `arccos_data[2]')
...
... lots of math functions ...
...
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:192: error: initializer element is not constant
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:192: error: (near initialization for `tanh_data[2]')
numpy/core/include/numpy/ufuncobject.h:328: warning: 'generate_overflow_error' defined but not used
numpy/core/src/umathmodule.c.src: In function `nc_sqrtf':
numpy/core/src/umathmodule.c.src:602: warning: implicit declaration of function `hypotf'
...
... lots of math functions ...
...
numpy/core/src/umathmodule.c.src: In function `FLOAT_frexp':
numpy/core/src/umathmodule.c.src:1940: warning: implicit declaration of function `frexpf'
numpy/core/src/umathmodule.c.src: In function `FLOAT_ldexp':
numpy/core/src/umathmodule.c.src:1957: warning: implicit declaration of function `ldexpf'
numpy/core/src/umathmodule.c.src: In function `LONGDOUBLE_frexp':
numpy/core/src/umathmodule.c.src:1940: warning: implicit declaration of function `frexpl'
numpy/core/src/umathmodule.c.src: In function `LONGDOUBLE_ldexp':
numpy/core/src/umathmodule.c.src:1957: warning: implicit declaration of function `ldexpl'
In file included from numpy/core/src/umathmodule.c.src:2011:
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c: At top level:
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:15: error: `acosl' undeclared here (not in a function)
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:15: error: initializer element is not constant
...
... lots of math functions ...
...
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:192: error: initializer element is not constant
build/src.irix64-6.5-2.4/numpy/core/__umath_generated.c:192: error: (near initialization for `tanh_data[2]')
numpy/core/include/numpy/ufuncobject.h:328: warning: 'generate_overflow_error' defined but not used
error: Command "gcc -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 -DHAVE_LARGEFILE_SUPPORT -fmessage-length=0 -Wall -O2 -Ibuild/src.irix64-6.5-2.4/numpy/core/src -Inumpy/core/include -Ibuild/src.irix64-6.5-2.4/numpy/core -Inumpy/core/src -Inumpy/core/include -I/usr/local/include/python2.4 -c build/src.irix64-6.5-2.4/numpy/core/src/umathmodule.c -o build/temp.irix64-6.5-2.4/build/src.irix64-6.5-2.4/numpy/core/src/umathmodule.o" failed with exit status 1

Can somebody explain me, what´s going wrong. It seems there is some header files missing.

thanks,
 thilo
-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [Numpy-discussion] Interfacing with PIL?

[Christopher B. <Chr...@no...>]

Tim Hochberg wrote:
> Johannes Loehnert wrote:
>>> I'm somewhat new to both libraries...is there any way to create a 2D
>>> array of pixel values from an image object from the Python Image
>>> Library? I'd like to do some arithmetic on the values.

the latest version of PIL (maybe not released yet) supports the array 
interface, so you may be able to do something like:

A = numpy.asarray(PIL_image)

see the PIL page:

http://effbot.org/zone/pil-changes-116.htm

where it says:

Changes from release 1.1.5 to 1.1.6
Added "fromarray" function, which takes an object implementing the NumPy 
array interface and creates a PIL Image from it. (from Travis Oliphant).

Added NumPy array interface support (__array_interface__) to the Image 
class (based on code by Travis Oliphant). This allows you to easily 
convert between PIL image memories and NumPy arrays:
import numpy, Image

i = Image.open('lena.jpg')
a = numpy.asarray(i) # a is readonly
i = Image.fromarray(a)

> On a related note, does anyone have a good recipe for converting a PIL 
> image to a wxPython image?

Does a PIL image support the buffer protocol? There will be a:

wx.ImageFromBuffer()

soon, and there is now;

wx.Image.SetDataBuffer()

if not, I think this will work:

I = wx.EmptyImage(width, height)
DataString = PIL_image.tostring()
I.SetDataBuffer(DataString)

This will only work if the PIL image is an 24 bit RGB image, of course. 
Just make sure to keep DataString around, so that the data buffer 
doesn't get deleted. wx.ImageFromBuffer() will do that foryou, but it's 
not available until 2.7 comes out.

Ideally, both PIL and wx will support the array interface, and we can 
just do:

I = wx.ImageFromArray(PIL_Image)

and not get any data copying as well.

Also, Robin has just added some methods to directly manipulate 
wxBitmaps, so you can use a numpy array as the data buffer for a 
wx.Bitmap. This can help prevent a lot of data copies. see a test here:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/demo/RawBitmapAccess.py?rev=1.3&content-type=text/vnd.viewcvs-markup

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] Interfacing with PIL?

[Tim H. <tim...@ie...>]

Johannes Loehnert wrote:
> Am Mittwoch, 30. August 2006 19:20 schrieb Ghalib Suleiman:
>   
>> I'm somewhat new to both libraries...is there any way to create a 2D
>> array of pixel values from an image object from the Python Image
>> Library? I'd like to do some arithmetic on the values.
>>     
>
> Yes.
>
> To transport the data:
>   
>>>> import numpy
>>>> image = <some PIL image>
>>>> arr = numpy.fromstring(image.tostring(), dtype=numpy.uint8)
>>>>         
>
> (alternately use dtype=numpy.uint32 if you want RGBA packed in one number).
>
> arr will be a 1d array with length (height * width * b(ytes)pp). Use reshape 
> to get it into a reasonable form.
>   
On a related note, does anyone have a good recipe for converting a PIL 
image to a wxPython image? The last time I tried this, the best I could 
come up with was:

        stream = cStringIO.StringIO()
        img.save(stream, "png")   # img is PIL Image
        stream.seek(0)
        image = wx.ImageFromStream(stream) # image is a wxPython Image


-tim

Re: [Numpy-discussion] Interfacing with PIL?

[Johannes L. <a.u...@gm...>]

Am Mittwoch, 30. August 2006 19:20 schrieb Ghalib Suleiman:
> I'm somewhat new to both libraries...is there any way to create a 2D
> array of pixel values from an image object from the Python Image
> Library? I'd like to do some arithmetic on the values.

Yes.

To transport the data:
>>> import numpy
>>> image = <some PIL image>
>>> arr = numpy.fromstring(image.tostring(), dtype=numpy.uint8)

(alternately use dtype=numpy.uint32 if you want RGBA packed in one number).

arr will be a 1d array with length (height * width * b(ytes)pp). Use reshape 
to get it into a reasonable form.

HTH, 
Johannes

[Numpy-discussion] Interfacing with PIL?

[Ghalib S. <gh...@se...>]

I'm somewhat new to both libraries...is there any way to create a 2D  
array of pixel values from an image object from the Python Image  
Library? I'd like to do some arithmetic on the values.

Re: [Numpy-discussion] Use of numarray from numpy package [# INC NO 24609]

[Christopher B. <Chr...@no...>]

Andrew Straw wrote:
>> {ccali22}~(0)>setenv PYTHONPATH /usr/local/lib/python2.3/site-packages/numpy
>>   
> Here's where you went wrong. You want:
> 
> setenv PYTHONPATH /usr/local/lib/python2.3/site-packages

Which you shouldn't need at all. site-packages should be on sys.path by 
default.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[Numpy-discussion] upcast

[Lars F. <lfr...@im...>]

Hello,

I would like to discuss the following code:

#***start***
import numpy as N

a = N.array((200), dtype = N.uint8)
print (a * 100) / 100

b = N.array((200, 200), dtype = N.uint8)
print (b * 100) / 100
#***stop***

The first print statement will print "200" because the uint8-value is
cast "upwards", I suppose. The second statement prints "[0 0]". I
suppose this is due to overflows during the calculation.

How can I tell numpy to do the upcast also in the second case, returning
"[200 200]"? I am interested in the fastest solution regarding execution
time. In my application I would like to store the result in an
Numeric.UInt8-array.

Thanks for every comment

Lars

Re: [Numpy-discussion] fftfreq very slow; rfftfreq incorrect?

[Stefan v. d. W. <st...@su...>]

On Wed, Aug 30, 2006 at 12:04:22PM +0100, Andrew Jaffe wrote:
> the current implementation of fftfreq (which is meant to return the=20
> appropriate frequencies for an FFT) does the following:
>=20
>      k =3D range(0,(n-1)/2+1)+range(-(n/2),0)
>      return array(k,'d')/(n*d)
>=20
> I have tried this with very long (2**24) arrays, and it is ridiculously=
=20
> slow. Should this instead use arange (or linspace?) and concatenate=20
> rather than converting the above list? This seems to result in=20
> acceptable performance, but we could also perhaps even pre-allocate the=
=20
> space.

Please try the attached benchmark.

> The numpy.fft.rfftfreq seems just plain incorrect to me. It seems to=20
> produce lots of duplicated frequencies, contrary to the actual output o=
f=20
> rfft:
>=20
> def rfftfreq(n,d=3D1.0):
>      """ rfftfreq(n, d=3D1.0) -> f
>=20
>      DFT sample frequencies (for usage with rfft,irfft).
>=20
>      The returned float array contains the frequency bins in
>      cycles/unit (with zero at the start) given a window length n and a
>      sample spacing d:
>=20
>        f =3D [0,1,1,2,2,...,n/2-1,n/2-1,n/2]/(d*n)   if n is even
>        f =3D [0,1,1,2,2,...,n/2-1,n/2-1,n/2,n/2]/(d*n)   if n is odd
>=20
>        **** None of these should be doubled, right?
>=20
>      """
>      assert isinstance(n,int)
>      return array(range(1,n+1),dtype=3Dint)/2/float(n*d)

Please produce a code snippet to demonstrate the problem.  We can then
fix the bug and use your code as a unit test.

Regards
St=E9fan

Re: [Numpy-discussion] Use of numarray from numpy package [# INC NO 24609]

[Andrew S. <str...@as...>]

LANDRIU David SAp wrote:
> Hello,
>   
>   I come back to my question : how to use numarray 
>  with the numpy installation ? 
>   
> {ccali22}~(0)>setenv PYTHONPATH /usr/local/lib/python2.3/site-packages/numpy
>   
Here's where you went wrong. You want:

setenv PYTHONPATH /usr/local/lib/python2.3/site-packages

> {ccali22}~(0)>python
> Python 2.3.5 (#2, Oct 17 2005, 17:20:02)
> [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-52)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>   
>>>> from numarray import *
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/local/lib/python2.3/site-packages/numpy/numarray/__init__.py", line 1, in ?
>     from util import *
>   File "/usr/local/lib/python2.3/site-packages/numpy/numarray/util.py", line 2, in ?
>     from numpy import geterr
> ImportError: No module named numpy
>   

Note that you're actually importing a numarray within numpy's directory
structure. That's because of your PYTHONPATH. numpy ships numpy.numarray
to provide backwards compatibility. To use it, you must do "import
numpy.numarray as numarray"

Cheers!
Andrew

[Numpy-discussion] amd64 support

[Keith G. <kwg...@gm...>]

I plan to build an amd64 box and run debian etch. Are there any big,
64-bit, show-stopping problems in numpy? Any minor annoyances?

Re: [Numpy-discussion] possible bug with numpy.object_

[Fernando P. <fpe...@gm...>]

On 8/30/06, Stefan van der Walt <st...@su...> wrote:

> The current behaviour makes sense, but is maybe not consistent:
>
> N.array([],dtype=object).size == 1
> N.array([[],[]],dtype=object).size == 2

Yes, including one more term in this check:

In [5]: N.array([],dtype=object).size
Out[5]: 1

In [6]: N.array([[]],dtype=object).size
Out[6]: 1

In [7]: N.array([[],[]],dtype=object).size
Out[7]: 2

Intuitively, I'd have expected the answers to be 0,1,2, instead of 1,1,2.

Cheers,

f

Re: [Numpy-discussion] stumped numpy user seeks help

[Stefan v. d. W. <st...@su...>]

On Tue, Aug 29, 2006 at 03:46:45PM -0700, Mathew Yeates wrote:
> My head is about to explode.
>=20
> I have an M by N array of floats. Associated with the columns are=20
> character labels
> ['a','b','b','c','d','e','e','e']  note: already sorted so duplicates=20
> are contiguous
>=20
> I want to replace the 2 'b' columns with the sum of the 2 columns.=20
> Similarly, replace the 3 'e' columns with the sum of the 3 'e' columns.
>=20
> The resulting array still has M rows but less than N columns. Anyone?=20
> Could be any harder than Sudoku.

I attach one possible solution (allowing for the same column name
occurring in different places, i.e. ['a','b','b','a']).  I'd be glad
for any suggestions on how to clean up the code.

Regards
St=E9fan

Re: [Numpy-discussion] Use of numarray from numpy package [# INC NO 24609]

[Perry G. <pe...@st...>]

On Aug 30, 2006, at 8:51 AM, LANDRIU David SAp wrote:

> Hello,
>
>   I come back to my question : how to use numarray
>  with the numpy installation ?
>
If you are using both at the same time, one thing you don't want to  
do is

from numpy import *
from numarray import *

You can do that with one or the other but not both. Are you doing that?

Perry Greenfield

Re: [Numpy-discussion] fromiter shape argument -- was Re: For loop tips

[Tim H. <tim...@ie...>]

Torgil Svensson wrote:
>>    return uL,asmatrix(fromiter((idx[x] for x in L),dtype=int))
>>     
>
> Is it possible for fromiter to take an optional shape (or count)
> argument in addition to the dtype argument? 
Yes. fromiter(iterable, dtype, count) works.

> If both is given it could
> preallocate memory and we only have to iterate over L once.
>   
Regardless, L is only iterated over once. In general you can't rewind 
iterators, so that's a requirement. This is accomplished by doing 
successive overallocation similar to the way appending to a list is 
handled. By specifying the count up front you save a bunch of reallocs, 
but no iteration.

-tim



> //Torgil
>
> On 8/29/06, Keith Goodman <kwg...@gm...> wrote:
>   
>> On 8/29/06, Torgil Svensson <tor...@gm...> wrote:
>>     
>>> something like this?
>>>
>>> def list2index(L):
>>>    uL=sorted(set(L))
>>>    idx=dict((y,x) for x,y in enumerate(uL))
>>>    return uL,asmatrix(fromiter((idx[x] for x in L),dtype=int))
>>>       
>> Wow. That's amazing. Thank you.
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Numpy-discussion mailing list
>> Num...@li...
>> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>
>>     
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>   

Re: [Numpy-discussion] eoRXwu

[Ellil R. <cy...@jn...>]

Hi,
=20
http://ikanuyunfadesun.com

, s=20

, c=20

, f=20

move. The soldier at the door looked at me, looked away. Steengo had=20
military service were mutually incompatible for the most part. I=20
Since I know next to nothing about music he is going to teach me my=20

Re: [Numpy-discussion] Use of numarray from numpy package

[Joris De R. <jo...@st...>]

Hi David,

Numeric, numarray and numpy are three different packages that can
live independently, but that can also coexist if you like so. If you're new
to this packages, you should stick to numpy, as the other ones are
getting phased out.

It's difficult to see what's going wrong without having seen how you
installed it.

I see that you tried
>>> from numarray import *

Perhaps a stupid question, but you did import numpy with 
>>> from numpy import *
didn't you?

Cheers,
Joris


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm