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

Re: [Numpy-discussion] Interesting memory leak

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

> This leak is caused by add_docstring, but it's supposed to leak. I wonder if
> there's a way to register some kind of on-exit handler in Python so that
> this can also be cleaned up?

import atexit
atexit.register(your_cleanup_function)

whose api is no args on input:

def your_cleanup_function():
  do_whatever...


You could use here a little extension function which goes in and does
the necessary free() calls on a pre-stored list of allocated pointers,
if there's more than one (I don't really know what's going on here).

Cheers,

f

Re: [Numpy-discussion] attributes of scalar types - e.g. numpy.int32.itemsize

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

Sebastian Haase wrote:
> On Friday 18 August 2006 15:25, Travis Oliphant wrote:
>   
>> Sebastian Haase wrote:
>>     
>>> On Friday 18 August 2006 11:38, Travis Oliphant wrote:
>>>       
>>>> Sebastian Haase wrote:
>>>>         
>>>>> Hi,
>>>>> array dtype descriptors have an attribute itemsize  that gives the
>>>>> total number of bytes required for an item of that dtype.
>>>>>
>>>>> Scalar types, like  numy.int32, also have that attribute,
>>>>> but it returns "something else" - don't know what:
>>>>>
>>>>>
>>>>> Furthermore there are *lot's*  of more attributes to a scalar dtype,
>>>>> e.g.
>>>>>           
>>>> The scalar types are actual Python types (classes) whereas the dtype
>>>> objects are instances.
>>>>
>>>> The attributes you are seeing of the typeobject are very useful when you
>>>> have an instance of that type.
>>>>
>>>> With numpy.int32.itemsize you are doing the equivalent of
>>>> numpy.dtype.itemsize
>>>>         
>>> but why then do I not get the result 4 ?
>>>       
>> Because it's not a "class" attribute, it's an instance attribute.
>>
>> What does numpy.dtype.itemsize give you?
>>
>>     
> I'm really sorry for being so dumb - but HOW can I get then the number of 
> bytes needed by a given scalar type ?
>
>   
Ah, the real question.  Sorry for not catching it earlier.  I've been in 
"make sure this isn't a bug mode" for a long time.

If you have a scalar type you could create one and then check the itemsize:

int32(0).itemsize

Or you could look at the name and parse out how big it is.

There is also a stored dictionary-like object that returns the number of 
bytes for any data-type recognized:

numpy.nbytes[int32]


-Travis

Re: [Numpy-discussion] numpy installation

[Piotr L. <lus...@cs...>]

s_wsfe is not LAPACK's routine it's a routine from the g2c library.
You have to link it in in addition to lapack_lite.

Piotr

On Friday 18 August 2006 18:07, jo...@st... wrote:
> Hi,
>
> I am correctly assuming that numpy needs the full lapack
> distribution, and not just the few lapack routines given by atlas?
> After installing numpy I still get the warning
>
> ImportError:
> /software/python-2.4.1/lib/python2.4/site-packages/numpy/linalg/lapac
>k_lite.so: undefined symbol: s_wsfe
>
> which seems to indicate that numpy is trying to use its lapack_lite
> version instead of the full lapack distribution. Defining
>
> [lapack]
> library_dirs = /software/lapack3.0/
> lapack_libs = combinedlapack
>
> in my site.cfg does not help. It also always gives a warning that my
> lapack lib in my atlas directory is incomplete despite the fact that
> I specified the full lapack library. The complaint of incompleteness
> disappears when I overwrite the liblapack.a of atlas with the one of
> the full lapack distribution, but then I still have the ImportError
> when I try to import numpy in my python shell.
>
> Any pointers?
>
> Cheers,
> Joris
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
> ---------------------------------------------------------------------
>---- 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=121
>642 _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] numpy installation

[<jo...@st...>]

Hi,

I am correctly assuming that numpy needs the full lapack distribution, 
and not just the few lapack routines given by atlas? After installing 
numpy I still get the warning

ImportError:
/software/python-2.4.1/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so:
undefined symbol: s_wsfe

which seems to indicate that numpy is trying to use its lapack_lite version
instead of the full lapack distribution. Defining

[lapack]
library_dirs = /software/lapack3.0/
lapack_libs = combinedlapack

in my site.cfg does not help. It also always gives a warning that my lapack
lib in my atlas directory is incomplete despite the fact that I specified 
the full lapack library. The complaint of incompleteness disappears when I
overwrite the liblapack.a of atlas with the one of the full lapack
distribution, but then I still have the ImportError when I try to import 
numpy in my python shell.

Any pointers?

Cheers,
Joris


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

Re: [Numpy-discussion] attributes of scalar types - e.g. numpy.int32.itemsize

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

On Friday 18 August 2006 15:25, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > On Friday 18 August 2006 11:38, Travis Oliphant wrote:
> >> Sebastian Haase wrote:
> >>> Hi,
> >>> array dtype descriptors have an attribute itemsize  that gives the
> >>> total number of bytes required for an item of that dtype.
> >>>
> >>> Scalar types, like  numy.int32, also have that attribute,
> >>> but it returns "something else" - don't know what:
> >>>
> >>>
> >>> Furthermore there are *lot's*  of more attributes to a scalar dtype,
> >>> e.g.
> >>
> >> The scalar types are actual Python types (classes) whereas the dtype
> >> objects are instances.
> >>
> >> The attributes you are seeing of the typeobject are very useful when you
> >> have an instance of that type.
> >>
> >> With numpy.int32.itemsize you are doing the equivalent of
> >> numpy.dtype.itemsize
> >
> > but why then do I not get the result 4 ?
>
> Because it's not a "class" attribute, it's an instance attribute.
>
> What does numpy.dtype.itemsize give you?
>
I'm really sorry for being so dumb - but HOW can I get then the number of 
bytes needed by a given scalar type ?

-S.

Re: [Numpy-discussion] attributes of scalar types - e.g. numpy.int32.itemsize

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

Sebastian Haase wrote:
> On Friday 18 August 2006 11:38, Travis Oliphant wrote:
>   
>> Sebastian Haase wrote:
>>     
>>> Hi,
>>> array dtype descriptors have an attribute itemsize  that gives the total
>>> number of bytes required for an item of that dtype.
>>>
>>> Scalar types, like  numy.int32, also have that attribute,
>>> but it returns "something else" - don't know what:
>>>
>>>
>>> Furthermore there are *lot's*  of more attributes to a scalar dtype, e.g.
>>>       
>> The scalar types are actual Python types (classes) whereas the dtype
>> objects are instances.
>>
>> The attributes you are seeing of the typeobject are very useful when you
>> have an instance of that type.
>>
>> With numpy.int32.itemsize you are doing the equivalent of
>> numpy.dtype.itemsize
>>     
>
> but why then do I not get the result 4 ?
>   
Because it's not a "class" attribute, it's an instance attribute.

What does numpy.dtype.itemsize give you?

-Travis

Re: [Numpy-discussion] [Fwd: Re: Signal handling]

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

On 8/18/06, Fernando Perez <Fer...@co...> wrote:
> here is the SAGE signal handling code, graciously donated by William Stein.

Hit send too soon... I forgot to thank William for this code :)
hopefully one of many things we'll be sharing between numpy/scipy and
SAGE.

Cheers,

f

[Numpy-discussion] [Fwd: Re: Signal handling]

[Fernando P. <Fer...@co...>]

Hi all,

here is the SAGE signal handling code, graciously donated by William Stein. 
I'd suggest putting (with any modifications to adapt it to numpy conventions) 
this into the actual numpy headers, so that not only all of our 
auto-generation tools (f2py, weave) can use it, but so that it also becomes 
trivial for end-users to user the same macros in their own code without doing 
anything additional.

Regards,

f

-------- Original Message --------
Subject: Re: Signal handling
Date: Fri, 18 Aug 2006 21:15:38 +0000
From: William Stein <ws...@gm...>
To: Fernando Perez <Fer...@co...>
References: <44E...@co...>

Here you are (see attached).   Let me know if you have any trouble
with gmail mangling
the attachment.

On 8/18/06, Fernando Perez <Fer...@co...> wrote:
> Hi William,
>
> could you please send me 'officially' an email with the interrupt.{c,h} files
> and a notice of them being BSD licensed ?  With that, I can then forward them
> to the numpy list and work on their inclusion tomorrow.


-- 
William Stein
Associate Professor of Mathematics
University of Washington

Re: [Numpy-discussion] numpy 0.9.8->1.0b2

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

On 8/18/06, Travis Oliphant <oli...@ie...> wrote:
> David Grant wrote:
> > I'm contemplating upgrading to 1.0b2. The main reason is that I am
> > experiencing a major memory leak and before I report a bug I think the
> > developers would appeciate if I was using the most recent version. Am
> > I correct in that the only major change that might actually break my
> > code is that the following functions:
> >
> > take, repeat, sum, product, sometrue, cumsum, cumproduct, ptp, amax,
> > amin, prod, cumprod, mean, std, var
> >
> > now have axis=None as argument?
> Also the default return type is "float" instead of "int".  I've
> highlighted the changes I think might break 0.9.8 code with the NOTE
> annotation on the page of release notes.
> >
> > BTW, how come alter_code2.py (
> > http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/oldnumeric/alter_code2.py?rev=HEAD)
> > says in the docstring that it "converts functions that don't give
> > axis= keyword that have changed" but I don't see it actually doing
> > that anywhere in the code?
> Because it isn't done.  The comments are a "this is what it should do".
> If you notice there is a warning on import (probably should be an error).

Oh ok, so maybe a FIXME then... oh well, it's all a question of
personal style, as long as you know what they mean. :-) I see the
warning now...good idea.

I see the "Important changes are denoted with a NOTE:" now in the
release notes now. Finally realizing that I had a scipy wiki account,
I added some more emphasis here for others.

Thanks,
David


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

Re: [Numpy-discussion] 1.02b

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

kor...@id... wrote:
> I realize it was just released, but is there going to be a windows release
> for 1.02b?
>
>   
There will be either be one of 1.0b3 or one of 1.0b2 released for 
windows by Monday.

-Travis

Re: [Numpy-discussion] convertcode.py

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

Hi Travis,



> The description of what these codes do is in the latest version of the
> second chapter of my book (which is part of the preview chapters that
> are available on the web).


Speaking of which, is it possible for us early buyers to get updated copies?

Chuck

Re: [Numpy-discussion] =?iso-8859-1?q?attributes_of_scalar_types_-_e?= =?iso-8859-1?q?=2Eg=2E=09numpy=2Eint32=2Eitemsize?=

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

On Friday 18 August 2006 11:38, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Hi,
> > array dtype descriptors have an attribute itemsize  that gives the total
> > number of bytes required for an item of that dtype.
> >
> > Scalar types, like  numy.int32, also have that attribute,
> > but it returns "something else" - don't know what:
> >
> >
> > Furthermore there are *lot's*  of more attributes to a scalar dtype, e.g.
>
> The scalar types are actual Python types (classes) whereas the dtype
> objects are instances.
>
> The attributes you are seeing of the typeobject are very useful when you
> have an instance of that type.
>
> With numpy.int32.itemsize you are doing the equivalent of
> numpy.dtype.itemsize

but why then do I not get the result 4 ?

-Sebastian

[Numpy-discussion] 1.02b

[<kor...@id...>]

I realize it was just released, but is there going to be a windows release
for 1.02b?

Re: [Numpy-discussion] attributes of scalar types - e.g. numpy.int32.itemsize

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

Sebastian Haase wrote:
> Hi,
> array dtype descriptors have an attribute itemsize  that gives the total 
> number of bytes required for an item of that dtype.
>
> Scalar types, like  numy.int32, also have that attribute,
> but it returns "something else" - don't know what:
>   
>
> Furthermore there are *lot's*  of more attributes to a scalar dtype, e.g.
>   

The scalar types are actual Python types (classes) whereas the dtype 
objects are instances.

The attributes you are seeing of the typeobject are very useful when you 
have an instance of that type.

With numpy.int32.itemsize you are doing the equivalent of

numpy.dtype.itemsize


-Travis

Re: [Numpy-discussion] bugfix-patch for numpy-1.0b2 setup

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

Norbert Nemec wrote:
> Hi there,
>
> in numpy-1.0b2 the logic in setup.py is slightly off. The attached patch
> fixes the issue.
>
> Greetings,
> Norbert
>
> PS: I would have preferred to submit this patch via the sourceforge
> bug-tracker, but that seems rather confusing: there are tabs "Numarray
> Patches" and "Numarray Bugs" but no "NumPy bugs" and the tab "Patches"
> seems to be used for Numeric. Why isn't NumPy handled via the
> Sourceforge page?
>   
NumPy development happens on the SVN servers at scipy.org and 
bug-tracking is handled through the Trac system at

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

We only use sourceforge for distribution.

I need more description on why the logic is not right.

-Travis

[Numpy-discussion] attributes of scalar types - e.g. numpy.int32.itemsize

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

Hi,
array dtype descriptors have an attribute itemsize  that gives the total 
number of bytes required for an item of that dtype.

Scalar types, like  numy.int32, also have that attribute,
but it returns "something else" - don't know what:
>>> a.dtype.itemsize
4
>>> a.dtype.name
'float32'
>>> N.int32.itemsize
<attribute 'itemsize' of 'genericscalar' objects>

Furthermore there are *lot's*  of more attributes to a scalar dtype, e.g.

>>> N.int32.data
<attribute 'data' of 'genericscalar' objects>
>>> N.int32.argmax()
Traceback (most recent call last):
  File "<input>", line 1, in ?
TypeError: descriptor 'argmax' of 'genericscalar' object needs an argument

Are those useful ? 

Thanks,
Sebastian Haase

Re: [Numpy-discussion] numpy 0.9.8->1.0b2

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

David Grant wrote:
> I'm contemplating upgrading to 1.0b2. The main reason is that I am 
> experiencing a major memory leak and before I report a bug I think the 
> developers would appeciate if I was using the most recent version. Am 
> I correct in that the only major change that might actually break my 
> code is that the following functions:
>
> take, repeat, sum, product, sometrue, cumsum, cumproduct, ptp, amax, 
> amin, prod, cumprod, mean, std, var
>
> now have axis=None as argument?
Also the default return type is "float" instead of "int".  I've 
highlighted the changes I think might break 0.9.8 code with the NOTE 
annotation on the page of release notes.
>
> BTW, how come alter_code2.py ( 
> http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/oldnumeric/alter_code2.py?rev=HEAD) 
> says in the docstring that it "converts functions that don't give 
> axis= keyword that have changed" but I don't see it actually doing 
> that anywhere in the code?
Because it isn't done.  The comments are a "this is what it should do".  
If you notice there is a warning on import (probably should be an error).


-Travis

Re: [Numpy-discussion] convertcode.py

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

Chris Kees wrote:
> Hi,
>
> I just  ran convertcode.py on my code  (from the latest svn source   
> of numpy) and it looks  like  it just changed the import  statements  to
>
> import numpy.oldnumeric as Numeric
>
> So  it doesn't  look  like it's really helping me move  over to the  
> new usage.  Is  there a script  that  will converts code  to use the  
> new numpy as  it's intended to be used?
>   
Not yet.   The transition approach is to use the compatibility layer 
first by running oldnumeric.alter_code1.py and then running 
alter_code2.py which will take you from the compatibility layer to NumPy 
(but alter_code2 is not completed yet).

The description of what these codes do is in the latest version of the 
second chapter of my book (which is part of the preview chapters that 
are available on the web).

-Travis

Re: [Numpy-discussion] numpy.bool8

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

Christopher Hanley wrote:
> What happened to numpy.bool8?  I realize that bool_ is just as good.  I 
> was just wondering what motivated the change?
>
>   
I think it was accidental...  The numpy scalar tp_names were recently 
changed to be more consistent with Python and the bool8 construct 
probably disappeared because it was automatically generated.

Thanks for the check. 


-Travis

Re: [Numpy-discussion] te test

[Jaka K. <mo...@de...>]

Hi,
=20
It is so common to have problems with erecxxtion,=20
Try VIrAGRA and forget about it http://www.vabaominheran.com

=20

=20

=20

which in turn . . .
Charges up your batteries. We know a thing or two as well, Hingst,
greeter of strangers to Paradise, and we are not your usual goaty

Re: [Numpy-discussion] First impressions on migrating to NumPy

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

A Divendres 18 Agost 2006 16:44, Chris Kees va escriure:
> Can you provide  some details about your approach to  migrating to
> NumPy? Are you following some  documentation on migration or do  you
> have your own  plan  of attack?

Well, to say the truth none of both ;-). The truth is that I was trying to=
=20
accelerate some parts of my software and realized that numarray was an=20
important bottleneck. NumPy was already in advanced beta stage and some sma=
ll=20
benchmarks conviced me that it would be the solution. So, I started porting=
=20
one single C extension (PyTables has several), the simplest one, and checke=
d=20
that the results were correct (and confirmed that the new code was much=20
faster!). After that, the second extension came converted and I'm in the=20
process of checking everything. Now, there remains 3 more extensions to=20
migrate, but the important ones for me are done.

So, no plans other than having a good motivation (and the need for speed wa=
s a=20
very good one). However, I think that having a complete test suite checking=
=20
every detail of your software was key. Also, having access to the excellent=
=20
book by Travis was extremely helpful. Finally, having IPython opened to che=
ck=20
everything, look at online docstrings and be able to do fast timings added=
=20
the "cerise sur le g=E2teau".

Luck!

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

Re: [Numpy-discussion] bugfix-patch for numpy-1.0b2 setup

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

Hi Norbert

On Fri, Aug 18, 2006 at 03:36:47PM +0200, Norbert Nemec wrote:
> in numpy-1.0b2 the logic in setup.py is slightly off. The attached patc=
h
> fixes the issue.

Please file a ticket so that we don't lose track of this.

St=E9fan

Re: [Numpy-discussion] First impressions on migrating to NumPy

[Chris K. <chr...@er...>]

Can you provide  some details about your approach to  migrating to =20
NumPy? Are you following some  documentation on migration or do  you =20
have your own  plan  of attack?

Chris
On Aug 18, 2006, at 6:59 AM, Francesc Altet wrote:

> Hi,
>
> I'm starting to (slowly) replace numarray by NumPy at the core of =20
> PyTables,
> specially at those places where the speed of NumPy is *much* =20
> better, that is,
> in the creation of arrays (there are places in PyTables where this is
> critical, most specially in indexation) and in copying arrays. In =20
> both cases,
> NumPy performs between 8x to 40x than numarray and this is, well...,
> excellent :-)
>
> Also, the big unification between numerical homogeneous  arrays, =20
> string
> homogeneous arrays (with unicode support added) and heterogeneous =20
> arrays
> (recarrays, with nested records support there also!) is simplyfying =20=

> very much
> the code in PyTables where there are many places where one have to
> distinguish between those different objects in numarray. =20
> Fortunately, this
> distinction is not necessary anymore in many of this places.
>
> Furthermore, I'm seeing that most of the corner cases where =20
> numarray do well
> (this was the main reason I was conservative about migrating =20
> anyway), are
> also very well resolved in NumPy (in some cases better, as for one, =20=

> NumPy has
> chosen NULL terminated strings for internal representation, instead =20=

> of space
> padding in numarray that gave me lots of headaches). Of course, =20
> there are
> some glitches that I'll report appropriately, but overall, NumPy is =20=

> behaving
> better than expected (and I already had *great* expectations).
>
> Well, I just wanted to report these experiences just in case other =20
> people is
> pondering about migrating as well to NumPy. But also wanted to =20
> thanks (once
> more), the excellent work of the NumPy crew, and specially Travis =20
> for their
> first-class work.
>
> Thanks!
>
> --=20
>> 0,0<   Francesc Altet     http://www.carabos.com/
> V   V   C=E1rabos Coop. V.   Enjoy Data
>  "-"
>
> ----------------------------------------------------------------------=20=

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] bugfix-patch for numpy-1.0b2 setup

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

A Divendres 18 Agost 2006 15:36, Norbert Nemec va escriure:
> PS: I would have preferred to submit this patch via the sourceforge
> bug-tracker, but that seems rather confusing: there are tabs "Numarray
> Patches" and "Numarray Bugs" but no "NumPy bugs" and the tab "Patches"
> seems to be used for Numeric. Why isn't NumPy handled via the
> Sourceforge page?

Because it has its own development site in:

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

Log your bug reports there. Sourceforge is mainly used to distribute tarbal=
ls=20
and binary packages of public releases, that's all.

Cheers,

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

[Numpy-discussion] bugfix-patch for numpy-1.0b2 setup

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

Hi there,

in numpy-1.0b2 the logic in setup.py is slightly off. The attached patch
fixes the issue.

Greetings,
Norbert

PS: I would have preferred to submit this patch via the sourceforge
bug-tracker, but that seems rather confusing: there are tabs "Numarray
Patches" and "Numarray Bugs" but no "NumPy bugs" and the tab "Patches"
seems to be used for Numeric. Why isn't NumPy handled via the
Sourceforge page?