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

Re: [Numpy-discussion] scipy_distutils

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

David Grant wrote:
> Where can I find the Extension module now? In the f2py documentation,
> the following import is used:
> 
> from scipy_distutils.core import Extension
> 
> but that doesn't work, and I read that this was moved into numpy along
> with f2py. I can't seem to find it anywhere. What's the current way of
> doing this?

That documentation is no longer up-to-date wrt building. I don't think that 
Pearu has done a comprehensive update of that section. The best place to look 
for documentation is numpy/doc/DISTUTILS.txt . numpy itself and scipy provide 
excellent examples of use, too.

-- 
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] scipy_distutils

[David G. <dav...@gm...>]

Where can I find the Extension module now? In the f2py documentation,
the following import is used:

from scipy_distutils.core import Extension

but that doesn't work, and I read that this was moved into numpy along
with f2py. I can't seem to find it anywhere. What's the current way of
doing this?

-- 
David Grant
http://www.davidgrant.ca

[Numpy-discussion] f2py --include_paths from command line

[Ethan T C. <et...@co...>]

Hi all,

The following line:

f2py -c -m _test --include_paths ./include test.f

(where test.f contains the line " include 'test_inc.h' " and 
'test_inc.h' exists in the directory './include' )

results in the errors:

------------------------------------------------------------------

running build
running config_fc
running build_src
building extension "_test" sources
f2py options: []
f2py:> /tmp/tmpJqhFcQ/src.linux-i686-2.4/_testmodule.c
creating /tmp/tmpJqhFcQ
creating /tmp/tmpJqhFcQ/src.linux-i686-2.4
Reading fortran codes...
         Reading file 'test.f' (format:fix,strict)
Line #6 in test.f:"      INCLUDE 'test_inc.h'"
         readfortrancode: could not find include file 'test_inc.h'. 
Ignoring.
Post-processing...
         Block: _test
                         Block: test
In: :_test:test.f:test
         getarrlen:variable "n" undefined
Post-processing (stage 2)...
Building modules...
         Building module "_test"...
                 Constructing wrapper function "test"...
                   a = test()
         Wrote C/API module "_test" to file 
"/tmp/tmpJqhFcQ/src.linux-i686-2.4/_testmodule.c"
   adding '/tmp/tmpJqhFcQ/src.linux-i686-2.4/fortranobject.c' to sources.
   adding '/tmp/tmpJqhFcQ/src.linux-i686-2.4' to include_dirs.
copying 
/packages/lib/python2.4/site-packages/numpy/f2py/src/fortranobject.c -> 
/tmp/tmpJqhFcQ/src.linux-i686-2.4
copying 
/packages/lib/python2.4/site-packages/numpy/f2py/src/fortranobject.h -> 
/tmp/tmpJqhFcQ/src.linux-i686-2.4
running build_ext
customize UnixCCompiler
customize UnixCCompiler using build_ext
customize GnuFCompiler
customize GnuFCompiler
customize GnuFCompiler using build_ext
building '_test' extension
compiling C sources
gcc options: '-pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -fPIC'
error: unknown file type '' (from '--include_paths')

---------------------------------------------------------------



Similar versions ( --include_paths=./include  , --include_paths 
"./include"  , --include_paths `pwd`/include ) fail similarly.

Everything works fine from a distutils extension/setup call, but not from 
the command line.


Thanks,


Ethan


-------------------------------------------
Ethan Coon
DOE CSGF - Graduate Student
Dept. Applied Physics & Applied Mathematics
Columbia University
212-854-0415

http://www.ldeo.columbia.edu/~ecoon/
-------------------------------------------

Re: [Numpy-discussion] test fails

[Nils W. <nw...@ia...>]

Steve Schmerler wrote:
> The test in
>
> In [2]: numpy.__version__
> Out[2]: '1.0b2.dev3007'
>
> fails:
>
>
> [...]
> check_1D_array (numpy.lib.tests.test_shape_base.test_vstack) ... ok
> check_2D_array (numpy.lib.tests.test_shape_base.test_vstack) ... ok
> check_2D_array2 (numpy.lib.tests.test_shape_base.test_vstack) ... ok
>
> ======================================================================
> ERROR: check_ascii (numpy.core.tests.test_multiarray.test_fromstring)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File 
> "/usr/local/lib/python2.3/site-packages/numpy/core/tests/test_multiarray.py", 
> line 120, in check_ascii
>      a = fromstring('1 , 2 , 3 , 4',sep=',')
> ValueError: don't know how to read character strings for given array type
>
> ----------------------------------------------------------------------
> Ran 476 tests in 1.291s
>
> FAILED (errors=1)
>
>
>   
I cannot reproduce it here

Numpy version 1.0b3.dev3025

python
/usr/lib64/python2.4/site-packages/numpy/core/tests/test_multiarray.py
  Found 153 tests for numpy.core.multiarray
  Found 0 tests for __main__
.........................................................................................................................................................
----------------------------------------------------------------------
Ran 153 tests in 0.047s

OK


Nils

[Numpy-discussion] test fails

[Steve S. <el...@gm...>]

The test in

In [2]: numpy.__version__
Out[2]: '1.0b2.dev3007'

fails:


[...]
check_1D_array (numpy.lib.tests.test_shape_base.test_vstack) ... ok
check_2D_array (numpy.lib.tests.test_shape_base.test_vstack) ... ok
check_2D_array2 (numpy.lib.tests.test_shape_base.test_vstack) ... ok

======================================================================
ERROR: check_ascii (numpy.core.tests.test_multiarray.test_fromstring)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib/python2.3/site-packages/numpy/core/tests/test_multiarray.py", 
line 120, in check_ascii
     a = fromstring('1 , 2 , 3 , 4',sep=',')
ValueError: don't know how to read character strings for given array type

----------------------------------------------------------------------
Ran 476 tests in 1.291s

FAILED (errors=1)


-- 
cheers,
steve

Random number generation is the art of producing pure gibberish as 
quickly as possible.

Re: [Numpy-discussion] Regarding Matrices

[Alan G I. <ai...@am...>]

> Torgil Svensson wrote:=20
>> Shouldn't power() and the ** operator return the same result for matrixe=
s?=20

On Mon, 14 Aug 2006, Christopher Barker apparently wrote:=20
> no, but the built-in pow() should -- does it?=20

The "try it and see" approach says that it does.

Cheers,
Alan Isaac

[Numpy-discussion] site.cfg problems

[Stephen W. <drs...@gm...>]

Does site.cfg actually work?  I ask because I want to test numpy (and soon
scipy) against ATLAS 3.7.13.  For simplicity I used the "make install" with
that distribution, which puts the files in /usr/local/atlas/lib,
/usr/local/atlas/include, and so on.  No problem, so I created a site.cfg in
the numpy root directory with

[atlas]
library_dirs = /usr/local/atlas/lib
atlas_libs = lapack, blas, cblas, atlas
include_dirs = /usr/local/atlas/include/

The numpy build did not find atlas; the output of "python setup.py build"
shows no sign of even having checked the listed directory above for the
libraries.  Did I do something wrong?  Should site.cfg be in
numpy/numpy/distutils instead?

[Numpy-discussion] Numpy 1.0b2 crash

[Pauli V. <pau...@ik...>]

Hi all,

The following code causes a segmentation fault in Numpy 1.0b2 and 1.0b1.

import numpy as N
v = N.array([1,2,3,4,5,6,7,8,9,10])
N.lexsort(v)


Stack trace
===========

$ gdb --args python crash.py
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db 
library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/python crash.py
[Thread debugging using libthread_db enabled]
[New Thread -1209857824 (LWP 22827)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209857824 (LWP 22827)]
0xb7d48f8d in PyArray_LexSort (sort_keys=0x81ed7e0, axis=<value optimized 
out>)
    at arrayobject.c:8483
8483    arrayobject.c: No such file or directory.
        in arrayobject.c
(gdb) bt
#0  0xb7d48f8d in PyArray_LexSort (sort_keys=0x81ed7e0,
    axis=<value optimized out>) at arrayobject.c:8483
#1  0xb7d49da5 in array_lexsort (ignored=0x0, args=0x822cb18, kwds=0x822cb18)
    at numpy/core/src/multiarraymodule.c:6271
#2  0x080b62c7 in PyEval_EvalFrame (f=0x8185c24) at ../Python/ceval.c:3563
#3  0x080b771f in PyEval_EvalCodeEx (co=0xb7e27ce0, globals=0xb7e08824,
    locals=0xb7e08824, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at ../Python/ceval.c:2736
#4  0x080b7965 in PyEval_EvalCode (co=0x822cb18, globals=0x822cb18,
    locals=0x822cb18) at ../Python/ceval.c:484
#5  0x080d94cc in PyRun_FileExFlags (fp=0x813e008,
    filename=0xbfcc98f3 "crash.py", start=136497944, globals=0x822cb18,
    locals=0x822cb18, closeit=1, flags=0xbfcc91d4)
    at ../Python/pythonrun.c:1265
#6  0x080d976c in PyRun_SimpleFileExFlags (fp=<value optimized out>,
    filename=0xbfcc98f3 "crash.py", closeit=1, flags=0xbfcc91d4)
    at ../Python/pythonrun.c:860
#7  0x08055b33 in Py_Main (argc=1, argv=0xbfcc9274) at ../Modules/main.c:493

#8  0xb7e45ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08054fa1 in _start () at ../sysdeps/i386/elf/start.S:119
(gdb)
#0  0xb7d48f8d in PyArray_LexSort (sort_keys=0x81ed7e0,
    axis=<value optimized out>) at arrayobject.c:8483
#1  0xb7d49da5 in array_lexsort (ignored=0x0, args=0x822cb18, kwds=0x822cb18)
    at numpy/core/src/multiarraymodule.c:6271
#2  0x080b62c7 in PyEval_EvalFrame (f=0x8185c24) at ../Python/ceval.c:3563
#3  0x080b771f in PyEval_EvalCodeEx (co=0xb7e27ce0, globals=0xb7e08824,
    locals=0xb7e08824, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at ../Python/ceval.c:2736
#4  0x080b7965 in PyEval_EvalCode (co=0x822cb18, globals=0x822cb18,
    locals=0x822cb18) at ../Python/ceval.c:484
#5  0x080d94cc in PyRun_FileExFlags (fp=0x813e008,
    filename=0xbfcc98f3 "crash.py", start=136497944, globals=0x822cb18,
    locals=0x822cb18, closeit=1, flags=0xbfcc91d4)
    at ../Python/pythonrun.c:1265
#6  0x080d976c in PyRun_SimpleFileExFlags (fp=<value optimized out>,
    filename=0xbfcc98f3 "crash.py", closeit=1, flags=0xbfcc91d4)
    at ../Python/pythonrun.c:860
#7  0x08055b33 in Py_Main (argc=1, argv=0xbfcc9274) at ../Modules/main.c:493
#8  0xb7e45ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#9  0x08054fa1 in _start () at ../sysdeps/i386/elf/start.S:119

Re: [Numpy-discussion] Creating and reshaping fortran order arrays

[Travis O. <oli...@ie...>]

Fernando Perez wrote:
> Sweet! We now finally have mutable strings for Python:
>
> In [2]: astr = '\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'
>
> In [4]: a = N.ndarray(shape=(2,2), dtype=N.int32, buffer=astr, order='F')
>
> In [5]: astr
> Out[5]: '\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'
>
> In [6]: a.flags.writeable = True
>
> In [7]: a
> Out[7]:
> array([[0, 2],
>        [1, 3]])
>
> In [8]: a[0] = 1
>
> In [9]: astr
> Out[9]: '\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x03\x00\x00\x00'
>
>
> Guido's going to kill you on Thursday, you know ;)
>   
Don't tell him ;-)

But, if he had provided a suitable bytes type already (that was 
pickleable) we wouldn't need to do this :-)  Notice it's not writeable 
by default, so at least you have to "know what you are doing" to shoot 
yourself in the foot.

-Travis

Re: [Numpy-discussion] Regarding Matrices

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

Sven Schreiber wrote:
> Hi,
>
> Satya Upadhya schrieb:
>
>   
>>>>> from Numeric import *
>>>>>           
>
> Well this list is about the numpy package, but anyway...
>   
This list is for numpy, numarray, and Numeric. There's just a lot more
numpy talk going on these days, but "numpy-discussion" comes from the
bad old days where no one realized that allowing your software package
to be called multiple things (Numeric, Numeric Python, numpy) might
result in confusion years later.

Cheers!
Andrew

Re: [Numpy-discussion] Creating and reshaping fortran order arrays

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

On 8/14/06, Travis Oliphant <oli...@ie...> wrote:
> Travis Oliphant wrote:
> > However, you can use the ndarray creation function itself to do what you
> > want:
> >
> > a = ndarray(shape=(2,2), dtype=int32, buffer=str, order='F')
> >
> > This will use the memory of the string as the new array memory.
> >
> Incidentally, the new array will be read-only.  But, you can fix this in
> two ways:
>
> 1) a.flags.writeable = True

Sweet! We now finally have mutable strings for Python:

In [2]: astr = '\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'

In [4]: a = N.ndarray(shape=(2,2), dtype=N.int32, buffer=astr, order='F')

In [5]: astr
Out[5]: '\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x03\x00\x00\x00'

In [6]: a.flags.writeable = True

In [7]: a
Out[7]:
array([[0, 2],
       [1, 3]])

In [8]: a[0] = 1

In [9]: astr
Out[9]: '\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x03\x00\x00\x00'


Guido's going to kill you on Thursday, you know ;)

f

Re: [Numpy-discussion] please comment on scalar types

[Travis O. <oli...@ee...>]

Sebastian Haase wrote:

>Travis Oliphant wrote:
>  
>
>And that automatically implies that there a  32bit-int cannot be used in 
>place of a "normal python integer" !?
>I could see wanting to use int16 or event uint8 as a tuple index.
>Logically a small type would be save to use in place of a bigger one ...
>  
>

That is the purpose behind the __index__ attribute I added to Python 2.5 
(see PEP 357).  This allows all the scalar integers to be used in place 
of integers inside of Python.

-Travis

Re: [Numpy-discussion] please comment on scalar types

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

Travis Oliphant wrote:
> Sebastian Haase wrote:
>> Hi!
>> I have a record array with a field 'mode'
>> Mode is a small integer that I use to choose a "PixelType"
>> So I did:
>>   
>>>>> print PixelTypes[ mode ]
>>>>>         
>> TypeError: tuple indices must be integers
>>   
>>>>> pdb.pm()
>>>>>         
>>> /home/haase/PrLinN64/Priithon/Mrc.py(813)MrcMode2numType()
>>>     
>> -> return PixelTypes[ mode ]
>> (Pdb) p mode
>> 1
>> (Pdb) p type(mode)
>> <type 'int32scalar'>
>> (Pdb) p isinstance(mode, int)
>> False
>>
>> Since numpy introduced special scalar types a simple statement like this 
>> doesn't work anymore !  Would it work if int32scalar was derived from int ? I 
>> actually thought it was ...
>>   
> It does sub-class from int unless you are on a system where a c-long is 
> 64-bit then int64scalar inherits from int.
> 
> On my 32-bit system:
> 
> isinstance(array([1,2,3])[0],int)  is true.
> 
> 
> 
> -Travis
I see -
yes I forgot - that test was indeed run on 64bit Linux.

And that automatically implies that there a  32bit-int cannot be used in 
place of a "normal python integer" !?
I could see wanting to use int16 or event uint8 as a tuple index.
Logically a small type would be save to use in place of a bigger one ...


- Sebastian

Re: [Numpy-discussion] please comment on scalar types

[Travis O. <oli...@ie...>]

Sebastian Haase wrote:
> Hi!
> I have a record array with a field 'mode'
> Mode is a small integer that I use to choose a "PixelType"
> So I did:
>   
>>>> print PixelTypes[ mode ]
>>>>         
> TypeError: tuple indices must be integers
>   
>>>> pdb.pm()
>>>>         
>> /home/haase/PrLinN64/Priithon/Mrc.py(813)MrcMode2numType()
>>     
> -> return PixelTypes[ mode ]
> (Pdb) p mode
> 1
> (Pdb) p type(mode)
> <type 'int32scalar'>
> (Pdb) p isinstance(mode, int)
> False
>
> Since numpy introduced special scalar types a simple statement like this 
> doesn't work anymore !  Would it work if int32scalar was derived from int ? I 
> actually thought it was ...
>   
It does sub-class from int unless you are on a system where a c-long is 
64-bit then int64scalar inherits from int.

On my 32-bit system:

isinstance(array([1,2,3])[0],int)  is true.



-Travis

[Numpy-discussion] please comment on scalar types

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

Hi!
I have a record array with a field 'mode'
Mode is a small integer that I use to choose a "PixelType"
So I did:
>>> print PixelTypes[ mode ]
TypeError: tuple indices must be integers
>>> pdb.pm()
> /home/haase/PrLinN64/Priithon/Mrc.py(813)MrcMode2numType()
-> return PixelTypes[ mode ]
(Pdb) p mode
1
(Pdb) p type(mode)
<type 'int32scalar'>
(Pdb) p isinstance(mode, int)
False

Since numpy introduced special scalar types a simple statement like this 
doesn't work anymore !  Would it work if int32scalar was derived from int ? I 
actually thought it was ...

Comments ?

- Sebastian Haase

Re: [Numpy-discussion] How to share memory when bArr is smaller-sized than aArr

[Travis O. <oli...@ie...>]

Sebastian Haase wrote:
> Hi,
> in numarray I could do this
>   
>>>> import numarray as na
>>>> a = na.arange(10)
>>>> b = na.array(a._data, type=na.int32, shape=8)
>>>>         
>
> b would use the beginning part of a.
>
> This is actually important for inplace FFT (where in real-to-complex-fft the 
> input has 2 "columns" more memory than the output)
>
> I found that in numpy there is no shape argument in array() at all anymore !
>
>   
No, there is no shape argument anymore.  But, the ndarray() constructor 
does have the shape argument and can be used in this way.

so

import numpy as na
b = na.ndarray(buffer=a, dtype=na.int32, shape=9)

should work.

-Travis

[Numpy-discussion] How to share memory when bArr is smaller-sized than aArr

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

Hi,
in numarray I could do this
>>> import numarray as na
>>> a = na.arange(10)
>>> b = na.array(a._data, type=na.int32, shape=8)

b would use the beginning part of a.

This is actually important for inplace FFT (where in real-to-complex-fft the 
input has 2 "columns" more memory than the output)

I found that in numpy there is no shape argument in array() at all anymore !

How can this be done with numpy ?

Thanks,
Sebastian Haase

Re: [Numpy-discussion] Segmentation Fault with Numeric 24.2 on Mac OS X 10.4 Tiger (8.7.0)

[Daran R. <dr...@uc...>]

Hi Chris,

> Darn. My few simple tests all work. If you can figure out which 
> functions are failing, and make a small sample that fails, post it here 
> and to the python-mac list. There are some smart folks there that might 
> be able to help.

I will try to do so, but like you, I think my time is better
spent transitioning to Numpy.

Incidentally, I am now using the MacPython distro--thanks for
pointing me toward that. I also got Numeric 23.8 to work well
with MacPython, including the optimized vecLib framework. I
got the harebrained idea to try compiling and installing
Numeric 23.8 using the setup.py and customize.py files from
Numeric 24.x, since they seem to get the Apple veclib stuff
compiled in properly, especially the optimized matrix math
libs. The one tweak I had to make was in setup.py, where I
pointed it to the new vecLib in:

      /System/Library/Frameworks/Accelerate.framework

> However, it might be easier to port to numpy that do all that. And 
> you'll definitely get more help solving any problems you have with numpy.

Agreed. I am looking forward to the first official release of
numpy. In the meantime, I will experiment with the Beta version.


Thanks again,



Daran

Re: [Numpy-discussion] Segmentation Fault with Numeric 24.2 on Mac OS X 10.4 Tiger (8.7.0)

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

Daran L. Rife wrote:
> I tried your suggestion of installing and running the pre-built
> packages at <http://www.pythonmac.org/packages/py24-fat/>. I am
> sorry to report that the pre-built MacPython and Numeric 24.2
> package did not work. I get the same "Segmentation Fault" that
> I got when I built Python 2.4.3 and Numeric 24.2 from source.

Darn. My few simple tests all work. If you can figure out which 
functions are failing, and make a small sample that fails, post it here 
and to the python-mac list. There are some smart folks there that might 
be able to help.

> As a last resort, I may build ATLAS and LAPACK from source,
> then build Numeric 23.8 against these, and try installing
> this into MacPython. I hate having to try this, but I cannot
> do any development without a functioning Python and Numeric.

However, it might be easier to port to numpy that do all that. And 
you'll definitely get more help solving any problems you have with numpy.

good luck.

-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] Regarding Matrices

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

Torgil Svensson wrote:

> Shouldn't power() and the ** operator return the same result for matrixes?

no, but the built-in pow() should -- does it?

-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] ctypes and ndpointer

[Travis O. <oli...@ie...>]

Albert Strasheim wrote:
> P.S. Sidebar: do we want these ctypes functions in the top-level namespace?
> Maybe not. Also, I'm starting to wonder whether ctypes_load_library deserves
> to exist or whether we should hear from the ctypes guys if there is a better
> way to accomplish what it does (which is to make it easy to load a shared
> library/DLL/dylib relative to some file in your module on any platform). 
>   
I'm happy to move them from the top-level name-space to something else 
prior to 1.0 final.  It's probably a good idea.

-Travis

[Numpy-discussion] ctypes and ndpointer

[Albert S. <fu...@gm...>]

Hello all

Just a quick note on the ndpointer function that Travis recently added to
NumPy (thanks Travis!).

When wrapping functions with ctypes, one can specify the argument types of
the function. ctypes then checks that the parameters are valid before
invoking the C function.

This is described here in detail:

http://docs.python.org/dev/lib/ctypes-specifying-required-argument-types.htm
l

The argtypes list is optional, and I think previously Travis suggested not
specifying the argtypes because it would require one to write something like
this:

bar.argtypes = [POINTER(c_double)]
x = N.array([...])
bar(x.data_as(POINTER(c_double))

instead of simply:

bar(x)

What ndpointer allows one to do is to build classes with a from_param method
that knows about the details of ndarrays and how to convert them to
something that ctypes can send to a C function. For example, suppose you
have the following function:

void bar(int* data, double x);

You know that bar expects a 20x30 array of big-endian integers in Fortran
order. You can make sure it gets only this kind of array by doing:

_foolib = N.ctypes_load_library('foolib_', '.')
bar = _foolib.bar
bar.restype = None
p = N.ndpointer(dtype='>i4', ndim=2, shape=(20,30), flags='FORTRAN')
bar.argtypes = [p, ctypes.c_double]

x = N.zeros((20,30),dtype='>i4',order='F')
bar(x, 123.0)

If you want your function to accept any kind of ndarray, you can do:

bar.argtypes = [N.ndpointer(),...]

In this case it will probably still make sense to wrap the C function in a
Python function that also passes the .ctypes.strides and .ctypes.shape of
the array.

Cheers,

Albert

P.S. Sidebar: do we want these ctypes functions in the top-level namespace?
Maybe not. Also, I'm starting to wonder whether ctypes_load_library deserves
to exist or whether we should hear from the ctypes guys if there is a better
way to accomplish what it does (which is to make it easy to load a shared
library/DLL/dylib relative to some file in your module on any platform). 

Re: [Numpy-discussion] Regarding Matrices

[Travis O. <oli...@ie...>]

Torgil Svensson wrote:
>>>> import numpy
>>>> numpy.__version__
>>>>         
> '1.0b1'
>   
>>>> from numpy import *
>>>> A = [1,2,3,4,5,6,7,8,9]
>>>> B = asmatrix(reshape(A,(3,3)))
>>>> B
>>>>         
> matrix([[1, 2, 3],
>         [4, 5, 6],
>         [7, 8, 9]])
>   
>>>> B**0
>>>>         
> matrix([[ 1.,  0.,  0.],
>         [ 0.,  1.,  0.],
>         [ 0.,  0.,  1.]])
>   
>>>> power(B,0)
>>>>         
> matrix([[1, 1, 1],
>         [1, 1, 1],
>         [1, 1, 1]])
>
> Shouldn't power() and the ** operator return the same result for matrixes?
>   
No.  power is always the ufunc which does element-by-element raising to 
a power.  This is actually a feature in that you can use the function 
call to do raising to a power without caring what kind of array subclass 
is used.

In the same manner, multiply is *always* the ufunc.


-Travis

Re: [Numpy-discussion] Regarding Matrices

[Torgil S. <tor...@gm...>]

>>> import numpy
>>> numpy.__version__
'1.0b1'
>>> from numpy import *
>>> A = [1,2,3,4,5,6,7,8,9]
>>> B = asmatrix(reshape(A,(3,3)))
>>> B
matrix([[1, 2, 3],
        [4, 5, 6],
        [7, 8, 9]])
>>> B**0
matrix([[ 1.,  0.,  0.],
        [ 0.,  1.,  0.],
        [ 0.,  0.,  1.]])
>>> power(B,0)
matrix([[1, 1, 1],
        [1, 1, 1],
        [1, 1, 1]])

Shouldn't power() and the ** operator return the same result for matrixes?

//Torgil

Re: [Numpy-discussion] Regarding Matrices

[Nils W. <nw...@ia...>]

On Mon, 14 Aug 2006 21:58:50 +0200
  Sven Schreiber <sve...@gm...> wrote:
> Hi,
>=20
> Satya Upadhya schrieb:
>=20
>>>>> from Numeric import *
>=20
> Well this list is about the numpy package, but anyway...
>=20
>> the power function is giving a resultant matrix in which=20
>>each element of
>> matrix B is raised to the power of 0 so as to make it 1.=20
>>But, taken as a
>> whole i.e. matrix B to the power of 0 should have given=20
>>the identity
>> matrix.
>=20
> afaik, in numpy terms if you are dealing with a numpy=20
>array, such
> functions are elementwise by design.
> In contrast, if you have a numpy matrix (a special=20
>subclass of the array
> class) --constructed e.g. as mat(eye(3))-- then power is=20
>redefined to be
> the matrix power; at least that's the rule for the **=20
>operator, not 100%
> sure if for the explicit power() function as well, but I=20
>suppose so.
>=20
>> =20
>> Also, what is the procedure for taking the log of an=20
>>entire matrix
>> (log(A) where A is a matrix takes the log of every=20
>>individual element in
>> A, but thats not the same as taking the log of the=20
>>entire matrix)
>=20
> I don't understand what you want, how do you take the=20
>log of a matrix
> mathematically?
>=20
> -Sven
>=20
> -----------------------------------------------------------------------=
--
> Using Tomcat but need to do more? Need to support web=20
>services, security?
> Get stuff done quickly with pre-integrated technology to=20
>make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based=20
>on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion


Help on function logm in module scipy.linalg.matfuncs:

logm(A, disp=3D1)
     Matrix logarithm, inverse of expm.

Nils