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

[Numpy-discussion] installation under other than .../site-packages

[Jose B. <bor...@gm...>]

My system administrator has told me numpy has to be installed under /local =
,
instead of under /usr/lib/pythonx.x/site-packages. Can anybody point to me
what modifications do I have to make for this. ? Also, will other libraries
that call numpy work after I install ?
jose

[Numpy-discussion] Creating multirow numpy rec.arrays

[Francesc A. <fa...@ca...>]

Hi,

This exposes a weird behaviour when building heterogeneous arrays in
numpy:

In [85]: xcol =3D numpy.ones((3,2), 'int32')

In [86]: numpy.array([(xcol[0],)], dtype=3D[('x','i4', (2,))])
Out[86]: array([(array([1, 1]),)], dtype=3D(void,8))

So far so good. Now:

In [89]: numpy.array([xcol], dtype=3D[('x','i4', (2,))])
<ERROR: expected a readable buffer object>
array([[[(array([-1208633192, -1208633192]),), (array([15, 15]),)],
        [(array([  0, 185]),), (array([         18, -1208633016]),)],
        [(array([480,  21]),), (array([21, 21]),)]]], dtype=3D(void,8))

While I'd expect:

In [89]: numpy.array([xcol], dtype=3D[('x','i4', (2,))])
Out[89]: array([(array([1, 1]),
                (array([1, 1]),
		(array([1, 1]))], dtype=3D(void,8))

Also, for the whishlist: It would be nice if one can specify the shape
of the array to be built in the factory itself. I mean, allowing
something like:

In [90]: numpy.array([xcol], dtype=3D[('x','i4', (2,))], shape=3D2)
Out[90]: array([(array([1, 1]),
		(array([1, 1]))], dtype=3D(void,8))

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

[Numpy-discussion] Re: Weird (wrong?) real fft 2d behavior

[Andrew J. <a.h...@gm...>]

Andrew Jaffe wrote:
> If I start with what I thought was an appropriate (n, n/2+1) complex 
> matrix which should have a real inverse fft, and then take its real fft, 
> I don't get back the original matrix.
> 
> Note the presence of very small but nonzero reals in the final matrix, 
> and the fact that the 2d and 4th rows are duplicates. This seems to be a 
>  mistake somewhere.
> 
> Or am I just misunderstanding/misremembering something about 2d real ffts?

and I should point out that
	delta_rp = N.dft.real_fft2d(delta_kp)
is 'allclose' to the original delta_r (which leads me to believe that I 
may indeed be misunderstanding something).

Andrew


> 
> Andrew
> 
> 
> In [41]: dims=(4,4)
> 
> In [42]: delta_k = aniso.dft_realizn(dims, P)
>          #### this just makes an appropriate matrix
> 
> In [43]: delta_k
> Out[43]:
> array([[-0.    +0.j    ,  0.5904+0.0429j,  0.9063+0.j    ],
>        [-0.221 +0.j    ,  0.4169+0.4602j, -0.6909+0.j    ],
>        [ 0.9059+0.j    , -0.8037+0.2604j,  1.835 +0.j    ],
>        [ 1.7436+0.j    , -0.2382+0.221j , -0.0607+0.j    ]])
>        #### 16 real numbers
> 
> In [44]: delta_r = N.dft.inverse_real_fft2d(delta_k)
> 
> In [45]: delta_r
> Out[45]:
> array([[ 0.2718, -0.0956,  0.2805,  0.1505],
>        [ 0.0297, -0.0533, -0.259 ,  0.0561],
>        [ 0.1308, -0.2096,  0.2288, -0.3041],
>        [ 0.0895,  0.1105, -0.3188, -0.1076]])
> 
> In [46]: delta_kp = N.dft.real_fft2d(delta_r)
> 
> In [47]: delta_kp
> Out[47]:
> array([[ 0.     +0.00e+00j,  0.5904 +4.2938e-02j,  0.9063 +0.0000e+00j],
>        [ 0.7613 +5.5511e-17j,0.4169 +4.6020e-01j, -0.3758 +5.5511e-17j],
>        [ 0.9059 +0.0000e+00j,-0.8037+2.6038e-01j, 1.835  +0.0000e+00j],
>        [ 0.7613 -5.5511e-17j,-0.2382+2.2099e-01j,-0.3758-5.5511e-17j]])
> 
> In [48]: N.__version__
> Out[48]: '0.9.5.1982'
> ------------------------

[Numpy-discussion] Weird (wrong?) real fft 2d behavior

[Andrew J. <a.h...@gm...>]

If I start with what I thought was an appropriate (n, n/2+1) complex 
matrix which should have a real inverse fft, and then take its real fft, 
I don't get back the original matrix.

Note the presence of very small but nonzero reals in the final matrix, 
and the fact that the 2d and 4th rows are duplicates. This seems to be a 
  mistake somewhere.

Or am I just misunderstanding/misremembering something about 2d real ffts?

Andrew


In [41]: dims=(4,4)

In [42]: delta_k = aniso.dft_realizn(dims, P)
          #### this just makes an appropriate matrix

In [43]: delta_k
Out[43]:
array([[-0.    +0.j    ,  0.5904+0.0429j,  0.9063+0.j    ],
        [-0.221 +0.j    ,  0.4169+0.4602j, -0.6909+0.j    ],
        [ 0.9059+0.j    , -0.8037+0.2604j,  1.835 +0.j    ],
        [ 1.7436+0.j    , -0.2382+0.221j , -0.0607+0.j    ]])
        #### 16 real numbers

In [44]: delta_r = N.dft.inverse_real_fft2d(delta_k)

In [45]: delta_r
Out[45]:
array([[ 0.2718, -0.0956,  0.2805,  0.1505],
        [ 0.0297, -0.0533, -0.259 ,  0.0561],
        [ 0.1308, -0.2096,  0.2288, -0.3041],
        [ 0.0895,  0.1105, -0.3188, -0.1076]])

In [46]: delta_kp = N.dft.real_fft2d(delta_r)

In [47]: delta_kp
Out[47]:
array([[ 0.     +0.00e+00j,  0.5904 +4.2938e-02j,  0.9063 +0.0000e+00j],
        [ 0.7613 +5.5511e-17j,0.4169 +4.6020e-01j, -0.3758 +5.5511e-17j],
        [ 0.9059 +0.0000e+00j,-0.8037+2.6038e-01j, 1.835  +0.0000e+00j],
        [ 0.7613 -5.5511e-17j,-0.2382+2.2099e-01j,-0.3758-5.5511e-17j]])

In [48]: N.__version__
Out[48]: '0.9.5.1982'
------------------------

Re: [Numpy-discussion] some question on new dtype

[Francesc A. <fa...@ca...>]

A Dimecres 25 Gener 2006 08:33, Travis Oliphant va escriure:
> Something like this:
>
> descriptor =3D a.dtype.arrdescr   # this could probably be renamed to
>                                 # descr now that we're
>                                 # not using that word.

+1 for this

That way we should have (in case of a int32 type):

>>> dtype.num
11
>>> dtype.char
'f'
>>> dtype.str
'<f4'
>>> dtype.name
'float32'
>>> dtype.descr
[('', '<f4')]

which I find quite logic.

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] dtype=float32 not recognised.

[Francesc A. <fa...@ca...>]

A Dimecres 25 Gener 2006 01:56, Sasha va escriure:
> You did not import float32.
>
> Your options:
> >>> from numpy import *
> >>> zeros(5, dtype=3Dfloat32)
>
> array([ 0.,  0.,  0.,  0.,  0.], dtype=3Dfloat32)
>
> or
>
> >>> import numpy
> >>> numpy.zeros(5, dtype=3Dnumpy.float32)
>
> array([ 0.,  0.,  0.,  0.,  0.], dtype=3Dfloat32)
>
> or
>
> >>> import numpy
> >>> numpy.zeros(5, dtype=3Dfloat)
>
> array([ 0.,  0.,  0.,  0.,  0.])

Another one:

>>> import numpy
>>> numpy.zeros(5, dtype=3D"float32")
array([ 0.,  0.,  0.,  0.,  0.], dtype=3Dfloat32)

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] some question on new dtype

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

N. Volbers wrote:

> 4) In the example above, printing any of the strings via 'print' will 
> yield the characters and then the characters up to the string size 
> filled up with \x00, e.g.
>
>  u'Bill\x00\x00\x00\x00\x00\x00\x00.... (30 characters total)'
>
> Why doesn't 'prin't terminate the output when the first \x00 is reached ?

O.K.  I finally broke down and fixed this in the SVN version.    Perhaps 
people can try it out for bugs.


-Travis

Re: [Numpy-discussion] some question on new dtype

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

N. Volbers wrote:

> Hello everyone on the list!
>
> I have been playing around with the latest and greatest numpy 0.94 and 
> its dtype mechanism. I am especially interested in using the 
> record-array-like facilities, e.g. the following which is based on an 
> example from a mail of Travis to this list:
>
> <--
> # define array with three "columns".
> dtype = numpy.dtype( {'names': ['name', 'age', 'weight'],
>  'formats': ['U30', 'i2', numpy.float32]} )
> a = numpy.array( [(u'Bill', 31, 260), (u'Fred', 15, 135)], dtype=dtype )
>
> # specify column by key
> print a ['name']
> print a['age']
> print a['weight']
> #print a['object']
>
> # specify row by number
> print a[0]
> print a[1]
>
> # first item of row 1 (Fred's age)
> print a[1]['age']
>
> # first item of name column (name 'Bill')
> print a['name'][0]
> -->
>
> I now have a few questions, maybe someone can help me with them:
>
> 1) When reading the sample chapter from Travis' documentation, I 
> noticed that there is also a type 'object' with the character 'O'. So 
> I kind of hoped that it would be possible to have arbitrary python 
> objects in an array. However, when I add a fourth "column" of type 
> 'O', then numpy will mem-fault. Is this not allowed or is this some 
> implementation bug?

It's a bug if it seg-faults, that should be allowed.  Please post your 
code so we can track it down.

>
> 2) Is it possible to rename the type descriptors? For my application, 
> I need to treat these names as keys of dataset columns, so it should 
> be possible to rename these.  More generally speaking: Is it possible 
> to alter parts of the dtype after instantiation? Of course it should 
> be possible to copy the dtype, modify it accordingly and create a new 
> array. However, maybe there is a suggested way to doing this?

Right now, you would have to construct a new data-type with the new 
field names,  There may be some ways we could make this easier, though.  
The big thing is that you can't change data-types in-place because they 
are used by other array objects.   

Perhaps the easiest way to do this is by getting the arrdescr attribute 
of the dtype (it's a list of tuples) and then constructing a new list of 
tuples using it (replaceing the tuples you want to rename) and then 
using that in the dtype constructor:

Something like this:

descriptor = a.dtype.arrdescr   # this could probably be renamed to 
descr now that we're     
                                                    #  not using that word.
                  # or a.__array_descr__  retrieves the same thing.

field = descriptor[field_num]
descriptor[field_num] = (newname,)+field[1:]
newdtype = numpy.dtype(descriptor)

Then you can do:

a.dtype = newdtype

and have a new field name.  


Actually, it would probably be faster to do:

new = dict(a.dtype.fields) # get a writeable dictionary.
new['<newname>'] = new['<oldname>']
del new['<oldname>']
del new[-1]  # get rid of the special ordering entry
a.dtype = dtype(new)

>
> 3) When I use two identical entries in the names part of the dtype, I 
> get the message 'TypeError: expected a readable buffer object'. It 
> makes sense that it is not allowed to have two identical names, but I 
> think the error message should be worded more descriptive.

Yeah, we ought to check for this.  Could you post your code that raises 
this error.

>
> 4) In the example above, printing any of the strings via 'print' will 
> yield the characters and then the characters up to the string size 
> filled up with \x00, e.g.
>
>  u'Bill\x00\x00\x00\x00\x00\x00\x00.... (30 characters total)'
>
> Why doesn't 'prin't terminate the output when the first \x00 is reached ?


Because I don't know the Unicode equivalent to PyString_FromString 
(which is what I'm using
to automatically truncate the fixed-field string before printing it).  
UNICODE_getitem in arraytypes.inc.src is the relevant function.  See 
STRING_getitem for comparison.

I think it would be better to truncate it if anybody has a good 
suggestion...

-Travis

[Numpy-discussion] some question on new dtype

[N. V. <mit...@we...>]

Hello everyone on the list!

I have been playing around with the latest and greatest numpy 0.94 and 
its dtype mechanism. I am especially interested in using the 
record-array-like facilities, e.g. the following which is based on an 
example from a mail of Travis to this list:

<--
# define array with three "columns".
dtype = numpy.dtype( {'names': ['name', 'age', 'weight'],
  'formats': ['U30', 'i2', numpy.float32]} )
a = numpy.array( [(u'Bill', 31, 260), (u'Fred', 15, 135)], dtype=dtype )

# specify column by key
print a ['name']
print a['age']
print a['weight']
#print a['object']

# specify row by number
print a[0]
print a[1]

# first item of row 1 (Fred's age)
print a[1]['age']

# first item of name column (name 'Bill')
print a['name'][0]
-->

I now have a few questions, maybe someone can help me with them:

1) When reading the sample chapter from Travis' documentation, I noticed 
that there is also a type 'object' with the character 'O'. So I kind of 
hoped that it would be possible to have arbitrary python objects in an 
array. However, when I add a fourth "column" of type 'O', then numpy 
will mem-fault. Is this not allowed or is this some implementation bug?

2) Is it possible to rename the type descriptors? For my application, I 
need to treat these names as keys of dataset columns, so it should be 
possible to rename these.  More generally speaking: Is it possible to 
alter parts of the dtype after instantiation? Of course it should be 
possible to copy the dtype, modify it accordingly and create a new 
array. However, maybe there is a suggested way to doing this?

3) When I use two identical entries in the names part of the dtype, I 
get the message 'TypeError: expected a readable buffer object'. It makes 
sense that it is not allowed to have two identical names, but I think 
the error message should be worded more descriptive.

4) In the example above, printing any of the strings via 'print' will 
yield the characters and then the characters up to the string size 
filled up with \x00, e.g.

  u'Bill\x00\x00\x00\x00\x00\x00\x00.... (30 characters total)'

Why doesn't 'prin't terminate the output when the first \x00 is reached ?



Overall I am very much impressed by the new numpy and I thank everyone 
who contributes to this!

Niklas Volbers.

Re: [Numpy-discussion] dtype=float32 not recognised.

[Sasha <nd...@ma...>]

You did not import float32.

Your options:

>>> from numpy import *
>>> zeros(5, dtype=3Dfloat32)
array([ 0.,  0.,  0.,  0.,  0.], dtype=3Dfloat32)

or

>>> import numpy
>>> numpy.zeros(5, dtype=3Dnumpy.float32)
array([ 0.,  0.,  0.,  0.,  0.], dtype=3Dfloat32)

or

>>> import numpy
>>> numpy.zeros(5, dtype=3Dfloat)
array([ 0.,  0.,  0.,  0.,  0.])

-- sasha

On 1/24/06, ag...@no... <ag...@no...> wrote:
> A curious problem (0.9.5.1993):
>
> n [12]: theta3 =3Dnumpy.zeros(66,dtype=3Dfloat32)
> -------------------------------------------------------------------------=
--
> exceptions.NameError                                 Traceback (most rece=
nt call
> last)
>
> /working/jrd/mod2/agn/OCCAM/AGN_GLOBAL/<ipython console>
>
> NameError: name 'float32' is not defined
>
> But
> n [14]: theta3 =3Dnumpy.zeros(66,dtype=3D'f')
>
> In [15]: theta3
> Out[15]:
> array([ 0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,
>         0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,
>         0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,
>         0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,
>         0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  =
0.],
> dtype=3Dfloat32)
>
> George Nuresr
>
>
> -----------------------------------------------------------------------
> National Oceanography Centre, Southampton :: http://www.noc.soton.ac.uk
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

[Numpy-discussion] dtype=float32 not recognised.

[<ag...@no...>]

A curious problem (0.9.5.1993):

n [12]: theta3 =numpy.zeros(66,dtype=float32)
---------------------------------------------------------------------------
exceptions.NameError                                 Traceback (most recent call 
last)

/working/jrd/mod2/agn/OCCAM/AGN_GLOBAL/<ipython console> 

NameError: name 'float32' is not defined

But
n [14]: theta3 =numpy.zeros(66,dtype='f')

In [15]: theta3
Out[15]: 
array([ 0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,
        0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,
        0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,
        0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,
        0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.,  0.], 
dtype=float32)

George Nuresr


-----------------------------------------------------------------------
National Oceanography Centre, Southampton :: http://www.noc.soton.ac.uk

[Numpy-discussion] Re: Efficient way to handle None->nan?

[Russell E. O. <ro...@ce...>]

In article <43D...@ee...>,
 Travis Oliphant <oli...@ee...> wrote:

> Russell E. Owen wrote:
> 
> >We're getting numeric data from a (MySQL) database. We'd like to use 
> >numarray or NumPy on the resulting data, but some values may be None. Is 
> >there a fast, efficient way to replace None with NaN? I'd hate to use a 
> >list comprehension on each data tuple before turning it into an array, 
> >but I haven't thought of anything else.
> >  
> >
> 
> Current numpy SVN allows
> 
> array([1.0,None,2.0],dtype=float)
> array([ 1.        ,         nan,  2.        ])

That's great! Thanks!!

-- Russell

Re: [Numpy-discussion] Matrix/Vector norm?

[Norbert N. <Nor...@gm...>]

Travis Oliphant wrote:

> Norbert Nemec wrote:
>
>> Hi there,
>>
>> im missing a norm function in NumPy. Writing one by hand is simple, but
>> doing so both general and efficient is a lot more tricky.
>>
>> Ideas?
>>  
>>
> There's one in scipy (i'm not sure if it's the best of breed, but it's
> a starting point).
>
> Look in scipy.linalg.norm

Is there a reason not to have it in numpy.linalg? That would be the most
logical place for it, I would guess.

Re: [Numpy-discussion] bdist_egg trips up over non-extension extensions

[Pearu P. <pe...@sc...>]

On Tue, 24 Jan 2006, Robert Kern wrote:

> Pearu Peterson wrote:
>> Could you try recent version of numpy from SVN? __config__.py is now
>> generated via py_modules list.
>
> It doesn't build an egg, yet, because setuptools expects Distribution.py_modules
> to contain only strings, not tuples. Modifying setuptools to handle tuples in
> Distribution.py_modules seems to work. Is there any way you can do it without
> tuples?

Source generators in numpy.distutils are extensions to distutils and if 
setuptools assumes std distutils then source generators will remain a 
problem for setuptools. However, if you call build_src then all source 
generators will be resolved (including 3-tuples in py_modules list) and 
the file lists in distribution instance should not cause any problems for 
setuptools.

So, would calling `setup.py build_src bdist_egg` be an acceptable 
solution?

__config__.py files could also be handled as data files but that would 
require hooks in numpy.core.setup function and we want to get rid of 
numpy.core.setup in future.

Pearu

Re: [Numpy-discussion] bdist_egg trips up over non-extension extensions

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

Pearu Peterson wrote:
> Could you try recent version of numpy from SVN? __config__.py is now
> generated via py_modules list.

It doesn't build an egg, yet, because setuptools expects Distribution.py_modules
to contain only strings, not tuples. Modifying setuptools to handle tuples in
Distribution.py_modules seems to work. Is there any way you can do it without
tuples?

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

Re: [Numpy-discussion] Speed performance on array constant set

[Todd M. <jm...@st...>]

Mark Heslep wrote:

> Travis Oliphant wrote:
>
>>> 1. numdata.h  example that works well for simple Cv structures  
>>> containing uniform types:  CvPoint2D32F  => struct { float x, float 
>>> y }.  Can I use a record array here, or is there some Numpy overhead 
>>> interlaced with fields?
>>
>>
>>
>> You can use a record array, but for uniform types I don't know what 
>> the advantage is (except for perhaps named-field slicing---which may 
>> actually be faster I'm not sure) over a x2 float array.
>
>
> So that I can step through the array record by record and not field by 
> field.
>
>>> 2. numarray.h  Attempt to replace the main Cv Image structures 
>>> CvMat, IplImage.  Needs work. Some success but there's segfault or 
>>> two in there somewhere.
>>
>>
>> These can be ported fairly easily, I think (actually, the old Numeric 
>> typemaps would still work --- and work with Numarray), so the basic 
>> Numeric C-API still presents itself as the simplest way to support 
>> all the array packages.
>
>
> Well good to know.  Ive been proceeding directly from the NumArray 
> Users Manual 1.5 by Greenfield/Miller et al that describes the NA High 
> Level API as the fastest of the APIs available to NA.  

The Numeric compatibility layer in numarray is almost identical in 
performance with the High Level API.   I recommend using the Numeric 
compatibility layer because it makes it easier to port your application 
back to Numeric or forward to NumPy.

> I thought that NA also took steps to insure that unnecessary mem 
> copies were not made, unlike Numeric?

NA does provide flexibility and support for managing mis-behaved 
(byteswapped, mis-aligned, mis-typed) arrays,  but these extra 
properties weren't a concern for Numeric.  Both numarray's High Level 
API and numarray's Numeric compatibility layer generally make whole 
copies of arrays as required to present well behaved representations of 
data to C.


Regards,
Todd

Re: [Numpy-discussion] bdist_egg trips up over non-extension extensions

[Pearu P. <pe...@sc...>]

On Tue, 24 Jan 2006, Robert Kern wrote:

> In particular, numpy can't build into an egg currently because
> numpy/__config__.py is created using Configuration.add_extension() and a
> generator function. In order to make extension modules usable from zipped eggs,
> setuptools generates a pure Python stub loader that will extract the extension
> module to a .hidden directory and load it from there. In this case, since the
> Extension isn't actually an extension, the stub loader is broken, because it
> expects a numpy/__config__.so.

Could you try recent version of numpy from SVN? __config__.py is now
generated via py_modules list.

Pearu

[Numpy-discussion] Replace typechars considered harmful

[Sasha <nd...@ma...>]

After a day of debugging I found that convertcode replaced '1' with
'b' in the code which was selecting database columns with names ending
with '1'.  Since it is probably very difficult to automatically
differentiate between '1' used as a typecode and other possible uses,
I suggest to either make "replace typechars" optional, or make it
write verbose message with a few lines of context when it changes the
code.

-- sasha

Re: [Numpy-discussion] bdist_egg trips up over non-extension extensions

[Pearu P. <pe...@sc...>]

On Tue, 24 Jan 2006, Robert Kern wrote:

> In particular, numpy can't build into an egg currently because
> numpy/__config__.py is created using Configuration.add_extension() and a
> generator function. In order to make extension modules usable from zipped eggs,
> setuptools generates a pure Python stub loader that will extract the extension
> module to a .hidden directory and load it from there. In this case, since the
> Extension isn't actually an extension, the stub loader is broken, because it
> expects a numpy/__config__.so.
>
> Can we find another way to generate Python code instead of abusing Extension
> this way?

Yes, using py_modules instead of ext_modules would be the correct way to 
go. I'm looking into this issue right now...

Pearu

Re: [Numpy-discussion] bdist_egg trips up over non-extension extensions

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

Just to be clear, you're not having problems with numpy as a non-zipped
egg, just a zipped egg, right? I haven't had any problems, but I haven't
tried to make zip-safe eggs.

(For those who don't know, eggs can be installed either as a zip filed
with extension .egg, or as a directory with extension egg.)

Robert Kern wrote:

>In particular, numpy can't build into an egg currently because
>numpy/__config__.py is created using Configuration.add_extension() and a
>generator function. In order to make extension modules usable from zipped eggs,
>setuptools generates a pure Python stub loader that will extract the extension
>module to a .hidden directory and load it from there. In this case, since the
>Extension isn't actually an extension, the stub loader is broken, because it
>expects a numpy/__config__.so.
>
>Can we find another way to generate Python code instead of abusing Extension
>this way?
>
>  
>

Re: [Numpy-discussion] f2py problems

[Pearu P. <pe...@sc...>]

On Tue, 24 Jan 2006, George Nurser wrote:

> I'm not sure whether this is the right list for f2py questions, but anyway.
>
> Tried it (v 2_1967) out today. It worked beautifully for a simple function.
>
> But for a more complicated (f77) *.F file with preprocessor directives and a 
> lot of data statements I have been having problems.
>
> Firstly, it just seemed to ignore all of the lines with preprocessor 
> directives.

f2py does not do preprocessing.

> Secondly, after I used a preprocessor to create the .f file separately, and 
> then ran the .f file through f2py, I got the following error trace.
> Anybody have any ideas?

> line 2007, in analyzevars
>   for k in implicitrules[ln0].keys():
> KeyError: '('

Could you send me the file that caused this error? The error may be due to 
a f2py bug or a non-standard Fortran code.

Thanks,
Pearu

[Numpy-discussion] bdist_egg trips up over non-extension extensions

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

In particular, numpy can't build into an egg currently because
numpy/__config__.py is created using Configuration.add_extension() and a
generator function. In order to make extension modules usable from zipped eggs,
setuptools generates a pure Python stub loader that will extract the extension
module to a .hidden directory and load it from there. In this case, since the
Extension isn't actually an extension, the stub loader is broken, because it
expects a numpy/__config__.so.

Can we find another way to generate Python code instead of abusing Extension
this way?

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

[Numpy-discussion] f2py problems

[George N. <ag...@no...>]

I'm not sure whether this is the right list for f2py questions, but  
anyway.

Tried it (v 2_1967) out today. It worked beautifully for a simple  
function.

But for a more complicated (f77) *.F file with preprocessor  
directives and a lot of data statements I have been having problems.

Firstly, it just seemed to ignore all of the lines with preprocessor  
directives.



Secondly, after I used a preprocessor to create the .f file  
separately, and then ran the .f file through f2py, I got the  
following error trace.
Anybody have any ideas?

--George Nurser.

f2py -c --verbose -m state2sig state2sig.f
running build
running config_fc
running build_src
building extension "state2sig" sources
f2py options: []
f2py:> /tmp/tmppzKlnT/src/state2sigmodule.c
creating /tmp/tmppzKlnT
creating /tmp/tmppzKlnT/src
Reading fortran codes...
         Reading file 'state2sig.f' (format:fix,strict)
Post-processing...
         Block: state2sig
                         Block: state2sig
Traceback (most recent call last):
   File "/data/jrd/mod1/agn/ext/Linux/bin/f2py", line 6, in ?
     f2py.main()
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
f2py2e.py", line 546, in main
     run_compile()
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
f2py2e.py", line 533, in run_compile
     setup(ext_modules = [ext])
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/distutils/ 
core.py", line 93, in setup
     return old_setup(**new_attr)
   File "/usr/lib64/python2.3/distutils/core.py", line 149, in setup
     dist.run_commands()
   File "/usr/lib64/python2.3/distutils/dist.py", line 907, in  
run_commands
     self.run_command(cmd)
   File "/usr/lib64/python2.3/distutils/dist.py", line 927, in  
run_command
     cmd_obj.run()
   File "/usr/lib64/python2.3/distutils/command/build.py", line 107,  
in run
     self.run_command(cmd_name)
   File "/usr/lib64/python2.3/distutils/cmd.py", line 333, in  
run_command
     self.distribution.run_command(command)
   File "/usr/lib64/python2.3/distutils/dist.py", line 927, in  
run_command
     cmd_obj.run()
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/distutils/ 
command/build_src.py", line 86, in run
     self.build_sources()
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/distutils/ 
command/build_src.py", line 99, in build_sources
     self.build_extension_sources(ext)
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/distutils/ 
command/build_src.py", line 149, in build_extension_sources
     sources = self.f2py_sources(sources, ext)
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/distutils/ 
command/build_src.py", line 355, in f2py_sources
     f2py2e.run_main(f2py_options + ['--lower',
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
f2py2e.py", line 330, in run_main
     postlist=callcrackfortran(files,options)
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
f2py2e.py", line 269, in callcrackfortran
     postlist=crackfortran.crackfortran(files)
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
crackfortran.py", line 2574, in crackfortran
     postlist=postcrack(grouplist[0])
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
crackfortran.py", line 1488, in postcrack
     g=postcrack(g,tab=tab+'\t')
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
crackfortran.py", line 1506, in postcrack
     block['body']=analyzebody(block,args,tab=tab)
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
crackfortran.py", line 1648, in analyzebody
     b=postcrack(b,as,tab=tab+'\t')
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
crackfortran.py", line 1506, in postcrack
     block['body']=analyzebody(block,args,tab=tab)
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
crackfortran.py", line 1648, in analyzebody
     b=postcrack(b,as,tab=tab+'\t')
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
crackfortran.py", line 1502, in postcrack
     block['vars']=analyzevars(block)
   File "/data/jrd/mod1/agn/ext/Linux/lib64/python/numpy/f2py/ 
crackfortran.py", line 2007, in analyzevars
     for k in implicitrules[ln0].keys():
KeyError: '('

Re: [Numpy-discussion] Numeric/numpy difference

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

Jens Jorgen Mortensen wrote:

> I just discovered (the hard way) that:
>
> >>> import numpy
> >>> a = numpy.empty((2, 3))
> >>> a[:] = [1, 2]
> >>> a
> array([[1, 2, 1],
>        [2, 1, 2]])
>
> This is with revision 1984.  With Numeric I get "ValueError: matrices 
> are not aligned for copy", which I think is the correct answer.

Well, not necessarily.   This is consistent behavior with a[:] = 3 which 
fills the array with 3's.  What's happening is that the array is being 
filled with [1,2] repeatedly (in C-contiguous order).

-Travis

Re: [Numpy-discussion] 0-dimensional object arrays

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

Ed Schofield wrote:

>Hi all,
>
>I've been attempting to use an object array to group together a
>collection of different-length arrays or lists, and I'm getting
>unexpected results.  Here's an example:
>
>  
>
>>>>import numpy
>>>>a = numpy.array([[1,2],[1,2,3]],object)
>>>>        
>>>>
>
>I expected here that 'a' would be an array of dimension (2,), holding
>two Python lists of integers.  Was I wrong to expect this?  It seems
>instead that 'a' is a 0-dimensional array holding one object:
>
>  
>
Yes, you were wrong to expect this ;-)

The array constructor is not really useful for constructing arbitrary 
object arrays.  It is not designed to analyze what you've input and pick 
the "optimal" assignment.  It never has been.  So, it's not surprising 
that it doesn't do what you expect.

>
>[[1, 2], [1, 2, 3], [1, 2], [1, 2, 3]]
>
>although these last two commands return Python lists, without the 0-d
>array wrapper, which isn't consistent with other 0-d arrays.
>  
>

We just changed that remember.  When 0-d object arrays result from 
calculations, the actual objects are returned. 

>On the whole, 0-d object arrays seem quite strange beasts.  Could
>someone please enlighten me on why they deserve to exist? ;)  They seem
>inconsistent with the new simplified interface to object array
>elements.  Could we get rid of them entirely?!
>  
>
No, we can't get rid of them because 0-d arrays exist and OBJECT is a 
data-type an array can have. Somebody is going to be able to construct 
one.   My advise is to create empty object arrays and fill them 
appropriately unless something better is written for OBJECT array 
construction.

-Travis