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

Re: [Numpy-discussion] Pow() with negative exponent

[Ivan V. i B. <iv...@ca...>]

En/na Pujo Aji ha escrit::

> Numpy optimize the python process by explicitly define the element type=

> of array.
> Just like C++.
>
> Python let you work with automatic converting... but it slows down the
> process.
> Like having extra code to check the type of your element array.
>
> I suggest you check the numpy reference instead of python reference the=
n
> using numpy.

OK, I see that predictability of the type of the output result matters.
;)  Besides that, I've been told that, according to the manual, power()
(as every other ufunc) uses its ``types`` member to find out the type of
the result depending only on the types of its arguments.  It makes sense
to avoid checking for particular values with possibly large arrays for
efficiency, as you point out.

I expected Python-like behaviour, but I understand this is not the most
appropriate thing to do for a high-performace package (but then, I was
not able to find out using the public docs).

Thanks for your help,

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""

Re[2]: [Numpy-discussion] Pow() with negative exponent

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

On Tue, 23 May 2006, Pujo Aji apparently wrote: 
> I suggest you check the numpy reference instead of python 
> reference when using numpy. 

http://www.scipy.org/Documentation

fyi,
Alan Isaac

Re: [Numpy-discussion] Pow() with negative exponent

[Pujo A. <aj...@gm...>]

Numpy optimize the python process by explicitly define the element type of
array.
Just like C++.

Python let you work with automatic converting... but it slows down the
process.
Like having extra code to check the type of your element array.

I suggest you check the numpy reference instead of python reference when
using numpy.

Sincerely Yours,
pujo


On 5/23/06, Ivan Vilata i Balaguer <iv...@ca...> wrote:
>
> En/na Pujo Aji ha escrit::
>
> > use 'f' to tell numpy that its array element is a float type:
> > b =3D numpy.array([1,2,3,4],'f')
> >
> > an alternative is to put dot after the number:
> > b =3D numpy.array([1. ,2. ,3. ,4.])
> >
> > This hopefully solve your problem.
>
> You're right, but according to Python reference docs, having an integer
> base and a negative integer exponent should still return a floating
> point result, without the need of converting the base to floating point
> beforehand.
>
> I wonder if the numpy/numarray behavior is based on some implicit policy
> which states that operating integers with integers should always return
> integers, for return type predictability, or something like that.  Could
> someone please shed some light on this?  Thanks!
>
> En/na Pujo Aji ha escrit::
>
> > On 5/23/06, *Ivan Vilata i Balaguer* <iv...@ca...
> > <mailto:iv...@ca...>> wrote:
> > [...]
> >     According to http://docs.python.org/ref/power.html:
> >
> >       For int and long int operands, the result has the same type as th=
e
> >       operands (after coercion) unless the second argument is negative;
> in
> >       that case, all arguments are converted to float and a float resul=
t
> is
> >       delivered.
> >
> >     Then, shouldn't be ``b ** -1 =3D=3D array([1.0, 0.5, 0.33333333, 0.=
25
> ])``
> >     (i.e. a floating point result)? Is this behaviour intentional?  (I
> >     googled for previous messages on the topic but I didn't find any.)
>
> ::
>
>         Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
>                C=E1rabos Coop. V.  V  V   Enjoy Data
>                                   ""
>
>
>
>

Re: [Numpy-discussion] Pow() with negative exponent

[Ivan V. i B. <iv...@ca...>]

En/na Pujo Aji ha escrit::

> use 'f' to tell numpy that its array element is a float type:
> b =3D numpy.array([1,2,3,4],'f')
>=20
> an alternative is to put dot after the number:
> b =3D numpy.array([1. ,2. ,3. ,4.])
>=20
> This hopefully solve your problem.

You're right, but according to Python reference docs, having an integer
base and a negative integer exponent should still return a floating
point result, without the need of converting the base to floating point
beforehand.

I wonder if the numpy/numarray behavior is based on some implicit policy
which states that operating integers with integers should always return
integers, for return type predictability, or something like that.  Could
someone please shed some light on this?  Thanks!

En/na Pujo Aji ha escrit::

> On 5/23/06, *Ivan Vilata i Balaguer* <iv...@ca...
> <mailto:iv...@ca...>> wrote:
> [...]
>     According to http://docs.python.org/ref/power.html:
>=20
>       For int and long int operands, the result has the same type as th=
e
>       operands (after coercion) unless the second argument is negative;=
 in
>       that case, all arguments are converted to float and a float resul=
t is
>       delivered.
>=20
>     Then, shouldn't be ``b ** -1 =3D=3D array([1.0, 0.5, 0.33333333, 0.=
25])``
>     (i.e. a floating point result)? Is this behaviour intentional?  (I
>     googled for previous messages on the topic but I didn't find any.)

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""

Re: [Numpy-discussion] Pow() with negative exponent

[Pujo A. <aj...@gm...>]

use 'f' to tell numpy that its array element is a float type:
b =3D numpy.array([1,2,3,4],'f')

an alternative is to put dot after the number:
b =3D numpy.array([1. ,2. ,3. ,4.])

This hopefully solve your problem.

Cheers,
pujo

On 5/23/06, Ivan Vilata i Balaguer <iv...@ca...> wrote:
>
> (I'm sending this again because I'm afraid the previous post may have
> qualified as spam because of it subject.  Sorry for the inconvenience.)
>
> Hi all, when working with numexpr, I have come across a curiosity in
> both numarray and numpy::
>
>   In [30]:b =3D numpy.array([1,2,3,4])
>   In [31]:b ** -1
>   Out[31]:array([1, 0, 0, 0])
>   In [32]:4 ** -1
>   Out[32]:0.25
>   In [33]:
>
> According to http://docs.python.org/ref/power.html:
>
>   For int and long int operands, the result has the same type as the
>   operands (after coercion) unless the second argument is negative; in
>   that case, all arguments are converted to float and a float result is
>   delivered.
>
> Then, shouldn't be ``b ** -1 =3D=3D array([1.0, 0.5, 0.33333333, 0.25])``
> (i.e. a floating point result)? Is this behaviour intentional?  (I
> googled for previous messages on the topic but I didn't find any.)
>
> Thanks,
>
> ::
>
>         Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
>                C=E1rabos Coop. V.  V  V   Enjoy Data
>                                   ""
>
>
>
>

[Numpy-discussion] Pow() with negative exponent

[Ivan V. i B. <iv...@ca...>]

(I'm sending this again because I'm afraid the previous post may have
qualified as spam because of it subject.  Sorry for the inconvenience.)

Hi all, when working with numexpr, I have come across a curiosity in
both numarray and numpy::

  In [30]:b =3D numpy.array([1,2,3,4])
  In [31]:b ** -1
  Out[31]:array([1, 0, 0, 0])
  In [32]:4 ** -1
  Out[32]:0.25
  In [33]:

According to http://docs.python.org/ref/power.html:

  For int and long int operands, the result has the same type as the
  operands (after coercion) unless the second argument is negative; in
  that case, all arguments are converted to float and a float result is
  delivered.

Then, shouldn=E2=80=99t be ``b ** -1 =3D=3D array([1.0, 0.5, 0.33333333, =
0.25])``
(i.e. a floating point result)? Is this behaviour intentional?  (I
googled for previous messages on the topic but I didn=E2=80=99t find any.=
)

Thanks,

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""

Re: [Numpy-discussion] Re: numpy (?) bug.

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

Martin Takeo Wiechert wrote:
> Robert,
>
> I nailed it down. Look at the short interactive session below. numpy version 
> is 0.9.8.
>
> Regards, Martin.
>
> P.S.: Simon, thanks for your hint. 0.9.8 is only a few days old. When did you 
> do your svn update?
>
>
> Python 2.4.3 (#1, May 12 2006, 05:35:54)
> [GCC 4.1.0 (SUSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>   
>>>> from numpy import *
>>>> multiply.reduceat ((15,15,15,15), (0,2))
>>>>         
> array([225, 225])
>   
>>>> multiply.reduceat ((15,15,15,15), (0,2))
>>>>         

Thanks for tracking this down.   It was a reference-count bug on the 
data-type object.   The builtin data-types should never be freed, but an 
attempt was made due to the bug. 

This should be fixed in SVN now.

-Travis



> *** glibc detected *** python: free(): invalid pointer: 0xb7a2eac0 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0xb7c1a911]
> /lib/libc.so.6(__libc_free+0x84)[0xb7c1bf84]
> /usr/local/lib/libpython2.4.so.1.0(PyObject_Free+0x51)[0xb7e56f31]
> /usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so[0xb79e0d97]
> /usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so[0xb79f9dca]
> /usr/local/lib/python2.4/site-packages/numpy/core/umath.so[0xb7983d9f]
> /usr/local/lib/libpython2.4.so.1.0(PyCFunction_Call+0x11d)[0xb7e5364d]
> /usr/local/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4e8e)[0xb7e8f42e]
> /usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x869)[0xb7e905c9]
> /usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCode+0x63)[0xb7e90643]
> /usr/local/lib/libpython2.4.so.1.0(PyRun_InteractiveOneFlags+0x1fd)
> [0xb7eb512d]
> /usr/local/lib/libpython2.4.so.1.0(PyRun_InteractiveLoopFlags+0x5b)
> [0xb7eb526b]
> /usr/local/lib/libpython2.4.so.1.0(PyRun_AnyFileExFlags+0x47)[0xb7eb5a87]
> /usr/local/lib/libpython2.4.so.1.0(Py_Main+0xbad)[0xb7ebbf3d]
> python(main+0x32)[0x80485e2]
> /lib/libc.so.6(__libc_start_main+0xdc)[0xb7bcc87c]
> python[0x8048521]
> ======= Memory map: ========
> 08048000-08049000 r-xp 00000000 03:05 205745     /usr/local/bin/python
> 08049000-0804a000 rw-p 00000000 03:05 205745     /usr/local/bin/python
> 0804a000-081ad000 rw-p 0804a000 00:00 0          [heap]
> b7000000-b7021000 rw-p b7000000 00:00 0
> b7021000-b7100000 ---p b7021000 00:00 0
> b71b4000-b7297000 rw-p b71b4000 00:00 0
> b7297000-b72b2000 r-xp 00000000 03:05 
> 212490     /usr/local/lib/python2.4/site-packages/numpy/random/mtrand.so
> b72b2000-b72b6000 rw-p 0001a000 03:05 
> 212490     /usr/local/lib/python2.4/site-packages/numpy/random/mtrand.so
> b72b6000-b72d0000 r-xp 00000000 03:05 201845     /usr/lib/libg2c.so.0.0.0
> b72d0000-b72d1000 rw-p 00019000 03:05 201845     /usr/lib/libg2c.so.0.0.0
> b72d1000-b72d4000 rw-p b72d1000 00:00 0
> b72e2000-b72eb000 r-xp 00000000 03:05 
> 212480     /usr/local/lib/python2.4/site-packages/numpy/dft/fftpack_lite.so
> b72eb000-b72ec000 rw-p 00008000 03:05 
> 212480     /usr/local/lib/python2.4/site-packages/numpy/dft/fftpack_lite.so
> b72ec000-b758c000 r-xp 00000000 03:05 
> 212489     /usr/local/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so
> b758c000-b758e000 rw-p 0029f000 03:05 
> 212489     /usr/local/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so
> b758e000-b75ef000 rw-p b758e000 00:00 0
> b75ef000-b75f2000 r-xp 00000000 03:05 
> 208618     /usr/local/lib/python2.4/lib-dynload/math.so
> b75f2000-b75f3000 rw-p 00002000 03:05 
> 208618     /usr/local/lib/python2.4/lib-dynload/math.so
> b75f3000-b75f5000 r-xp 00000000 03:05 
> 212481     /usr/local/lib/python2.4/site-packages/numpy/lib/_compiled_base.so
> b75f5000-b75f6000 rw-p 00002000 03:05 
> 212481     /usr/local/lib/python2.4/site-packages/numpy/lib/_compiled_base.so
> b75f6000-b7610000 r-xp 00000000 03:05 
> 212486     /usr/local/lib/python2.4/site-packages/numpy/core/scalarmath.so
> b7610000-b7611000 rw-p 00019000 03:05 
> 212486     /usr/local/lib/python2.4/site-packages/numpy/core/scalarmath.so
> b7611000-b7614000 r-xp 00000000 03:05 
> 208625     /usr/local/lib/python2.4/lib-dynload/mmap.so
> b7614000-b7615000 rw-p 00003000 03:05 
> 208625     /usr/local/lib/python2.4/lib-dynload/mmap.so
> b7615000-b7656000 rw-p b7615000 00:00 0
> b7656000-b765a000 r-xp 00000000 03:05 
> 208644     /usr/local/lib/python2.4/lib-dynload/strop.so
> b765a000-b765c000 rw-p 00003000 03:05 
> 208644     /usr/local/lib/python2.4/lib-dynload/strop.so
> b765c000-b765f000 r-xp 00000000 03:05 
> 208595     /usr/local/lib/python2.4/lib-dynload/cStringIO.so
> b765f000-b7660000 rw-p 00003000 03:05 
> 208595     /usr/local/lib/python2.4/lib-dynload/cStringIO.so
> b7660000-b7671000 r-xp 00000000 03:05 
> 208619     /usr/local/lib/python2.4/lib-dynload/cPickle.so
> b7671000-b7672000 rw-p 00010000 03:05 
> 208619     /usr/local/lib/python2.4/lib-dynload/cPickle.so
> b7672000-b7964000 r-xp 00000000 03:05 
> 212484     /usr/local/lib/python2.4/site-packages/numpy/core/_dotblas.so
> b7964000-b7966000 rw-p 002f1000 03:05 
> 212484     /usr/local/lib/python2.4/site-packages/numpy/core/_dotblas.so
> b7966000-b798e000 r-xp 00000000 03:05 
> 212487     /usr/local/lib/python2.4/site-packages/numpy/core/umath.so
> b798e000-b7991000 rw-p 00027000 03:05 
> 212487     /usr/local/lib/python2.4/site-packages/numpy/core/umath.so
> b7991000-b79d3000 rw-p b7991000 00:00 0
> b79d3000-b7a28000 r-xp 00000000 03:05 
> 212482     /usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so
> b7a28000-b7a32000 rw-p 00054000 03:05 
> 212482     /usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so
> b7a32000-b7a6d000 r-xp 00000000 03:05 17777      /lib/libncurses.so.5.5
> b7a6d000-b7a78000 rw-p 0003a000 03:05 17777      /lib/libncurses.so.5.5
> b7a78000-b7a79000 rw-p b7a78000 00:00 0
> b7a79000-b7aba000 r-xp 00000000 03:05 17792      /usr/lib/libncursesw.so.5.5
> b7aba000-b7ac6000 rw-p 00040000 03:05 17792      /usr/lib/libncursesw.so.5.5
> b7ac6000-b7af0000 r-xp 00000000 03:05 18393      /lib/libreadline.so.5.1
> b7af0000-b7af4000 rw-p 0002a000 03:05 18393      /lib/libreadline.so.5.1
> b7af4000-b7af5000 rw-p b7af4000 00:00 0
> b7af5000-b7af8000 r-xp 00000000 03:05 
> 208646     /usr/local/lib/python2.4/lib-dynload/readline.so
> b7af8000-b7af9000 rw-p 000030Aborted
>
>
> -------------------------------------------------------
> 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] saving data: which format is recommended?

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

Brian Blais wrote:
> Hello,
>
> I am trying to save numpy arrays (actually a list of them) for later 
> use, and
> distribution to others.  Up until yesterday, I've been using the 
> zpickle module from
> the Cookbook, which is just pickle binary format with gzip 
> compression.  Yesterday, I
> upgraded my operating system, and now I can't read those files.  I am 
> using numpy
> 0.9.9.2536, and unfortunately I can't recall the version that I was 
> using, but it was
> pretty relatively recent.  I also upgraded from Python 2.3 to 2.4.  
> Trying to load
> the "old" files, I get:
>
> AttributeError: 'module' object has no attribute 'dtypedescr'

The name "dtypedescr" was changed to "dtype" back in early February.  
The problem with pickle is that it is quite sensitive to these kind of 
changes.   These kind of changes are actually rare, but in the early 
stages of NumPy, more common.  This should be more stable now.  I don't 
expect changes that will cause pickled NumPy arrays to fail in the future.

If you needed to read the data on these files, it is likely possible 
with a little tweaking.

While pickle is convenient and the actual data is guaranteed to be 
readable, reconstructing the data requires that certain names won't 
change.   Many people use other methods for persistence because of this.


-Travis

Re: [Numpy-discussion] saving data: which format is recommended?

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

El dl 22 de 05 del 2006 a les 12:49 -0400, en/na Brian Blais va
escriure:
> I am trying to save numpy arrays (actually a list of them) for later use,=
 and
> distribution to others.  Up until yesterday, I've been using the zpickle =
module from
> the Cookbook, which is just pickle binary format with gzip compression.  =
Yesterday, I
> upgraded my operating system, and now I can't read those files.  I am usi=
ng numpy
> 0.9.9.2536, and unfortunately I can't recall the version that I was using=
, but it was
> pretty relatively recent.  I also upgraded from Python 2.3 to 2.4.  Tryin=
g to load
> the "old" files, I get:
>=20
> AttributeError: 'module' object has no attribute 'dtypedescr'
>=20
>=20
> the file consists of a single dictionary, with two elements, like:
>=20
> var=3D{'im': numpy.zeros((5,5)),'im_scale_shift':[0.0,1.0]}

This could be because NumPy objects has suffered some changes in their
structure in the last months. After 1.0 version there will (hopefully)
be no more changes in the structure, so your pickles will be more stable
(but again, you might have problems in the long run, i.e. when NumPy 2.0
will appear).

>=20
> My question isn't how can I load these "old" files, because I can regener=
ate them.  I
> would like to know what file format I should be using so that I don't hav=
e to worry
> about upgrades/version differences when I want to load them.  Is there a =
preferred
> way to do this?  I thought pickle was that way, but perhaps I don't under=
stand how
> pickle works.

If you need full comaptibility, a better approach than pickle-based
solutions are the .tofile() .fromfile() methods, but you need to save
the metadata for your objects (type, shape, etc.) separately.

If you need full support for saving data & metadata for your NumPy
objects in a transparent way that is independent of pickle you may want
to have a look at PyTables [1] or NetCDF4 [2]. Both packages should be
able to save NumPy datasets without a need to worry for future changes
in NumPy data structures. These both packages are ultimately based on
the HDF5 format[3], which has a pretty strong commitement with
backward/forward format compatibility along its versions.

[1]http://www.pytables.org
[2]http://www.cdc.noaa.gov/people/jeffrey.s.whitaker/python/netCDF4.html=20
[3]http://hdf.ncsa.uiuc.edu/HDF5

Cheers,

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

[Numpy-discussion] saving data: which format is recommended?

[Brian B. <bb...@br...>]

Hello,

I am trying to save numpy arrays (actually a list of them) for later use, and
distribution to others.  Up until yesterday, I've been using the zpickle module from
the Cookbook, which is just pickle binary format with gzip compression.  Yesterday, I
upgraded my operating system, and now I can't read those files.  I am using numpy
0.9.9.2536, and unfortunately I can't recall the version that I was using, but it was
pretty relatively recent.  I also upgraded from Python 2.3 to 2.4.  Trying to load
the "old" files, I get:

AttributeError: 'module' object has no attribute 'dtypedescr'


the file consists of a single dictionary, with two elements, like:

var={'im': numpy.zeros((5,5)),'im_scale_shift':[0.0,1.0]}

My question isn't how can I load these "old" files, because I can regenerate them.  I
would like to know what file format I should be using so that I don't have to worry
about upgrades/version differences when I want to load them.  Is there a preferred
way to do this?  I thought pickle was that way, but perhaps I don't understand how
pickle works.

thanks,

		Brian Blais

Re: [Numpy-discussion] Re: numpy (?) bug.

[Martin W. <mar...@gm...>]

I've created ticket #128

Regards, Martin


On Monday 22 May 2006 16:33, Albert Strasheim wrote:
> Hello all
>
> This bug seems to be present in 0.9.9.2536. Martin, it would be great if
> you could create a ticket in Trac.
>
> http://projects.scipy.org/scipy/numpy/newticket
>
> Regards,
>
> Albert
>
> > -----Original Message-----
> > From: num...@li... [mailto:numpy-
> > dis...@li...] On Behalf Of Martin Takeo
> > Wiechert Sent: 22 May 2006 16:24
> > To: num...@li...
> > Subject: Re: [Numpy-discussion] Re: numpy (?) bug.
> >
> > Robert,
> >
> > I nailed it down. Look at the short interactive session below. numpy
> > version
> > is 0.9.8.
> >
> > Regards, Martin.
> >
> > P.S.: Simon, thanks for your hint. 0.9.8 is only a few days old. When did
> > you
> > do your svn update?
>
> -------------------------------------------------------
> 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

[Numpy-discussion] Re: numpy (?) bug.

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

Albert Strasheim wrote:
> Hello all
> 
> This bug seems to be present in 0.9.9.2536.

In order to bracket the bug, I will add that I do not see it in 0.9.7.2477 .

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

[Fwd: Re: [Numpy-discussion] Re: numpy (?) bug.]

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

RE: [Numpy-discussion] Re: numpy (?) bug.

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

Hello all

This bug seems to be present in 0.9.9.2536. Martin, it would be great if you
could create a ticket in Trac.

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

Regards,

Albert

> -----Original Message-----
> From: num...@li... [mailto:numpy-
> dis...@li...] On Behalf Of Martin Takeo Wiechert
> Sent: 22 May 2006 16:24
> To: num...@li...
> Subject: Re: [Numpy-discussion] Re: numpy (?) bug.
> 
> Robert,
> 
> I nailed it down. Look at the short interactive session below. numpy
> version
> is 0.9.8.
> 
> Regards, Martin.
> 
> P.S.: Simon, thanks for your hint. 0.9.8 is only a few days old. When did
> you
> do your svn update?

Re: [Numpy-discussion] Re: numpy (?) bug.

[Martin T. W. <Mar...@mp...>]

Robert,

I nailed it down. Look at the short interactive session below. numpy version 
is 0.9.8.

Regards, Martin.

P.S.: Simon, thanks for your hint. 0.9.8 is only a few days old. When did you 
do your svn update?


Python 2.4.3 (#1, May 12 2006, 05:35:54)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from numpy import *
>>> multiply.reduceat ((15,15,15,15), (0,2))
array([225, 225])
>>> multiply.reduceat ((15,15,15,15), (0,2))
*** glibc detected *** python: free(): invalid pointer: 0xb7a2eac0 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7c1a911]
/lib/libc.so.6(__libc_free+0x84)[0xb7c1bf84]
/usr/local/lib/libpython2.4.so.1.0(PyObject_Free+0x51)[0xb7e56f31]
/usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so[0xb79e0d97]
/usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so[0xb79f9dca]
/usr/local/lib/python2.4/site-packages/numpy/core/umath.so[0xb7983d9f]
/usr/local/lib/libpython2.4.so.1.0(PyCFunction_Call+0x11d)[0xb7e5364d]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4e8e)[0xb7e8f42e]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x869)[0xb7e905c9]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCode+0x63)[0xb7e90643]
/usr/local/lib/libpython2.4.so.1.0(PyRun_InteractiveOneFlags+0x1fd)
[0xb7eb512d]
/usr/local/lib/libpython2.4.so.1.0(PyRun_InteractiveLoopFlags+0x5b)
[0xb7eb526b]
/usr/local/lib/libpython2.4.so.1.0(PyRun_AnyFileExFlags+0x47)[0xb7eb5a87]
/usr/local/lib/libpython2.4.so.1.0(Py_Main+0xbad)[0xb7ebbf3d]
python(main+0x32)[0x80485e2]
/lib/libc.so.6(__libc_start_main+0xdc)[0xb7bcc87c]
python[0x8048521]
======= Memory map: ========
08048000-08049000 r-xp 00000000 03:05 205745     /usr/local/bin/python
08049000-0804a000 rw-p 00000000 03:05 205745     /usr/local/bin/python
0804a000-081ad000 rw-p 0804a000 00:00 0          [heap]
b7000000-b7021000 rw-p b7000000 00:00 0
b7021000-b7100000 ---p b7021000 00:00 0
b71b4000-b7297000 rw-p b71b4000 00:00 0
b7297000-b72b2000 r-xp 00000000 03:05 
212490     /usr/local/lib/python2.4/site-packages/numpy/random/mtrand.so
b72b2000-b72b6000 rw-p 0001a000 03:05 
212490     /usr/local/lib/python2.4/site-packages/numpy/random/mtrand.so
b72b6000-b72d0000 r-xp 00000000 03:05 201845     /usr/lib/libg2c.so.0.0.0
b72d0000-b72d1000 rw-p 00019000 03:05 201845     /usr/lib/libg2c.so.0.0.0
b72d1000-b72d4000 rw-p b72d1000 00:00 0
b72e2000-b72eb000 r-xp 00000000 03:05 
212480     /usr/local/lib/python2.4/site-packages/numpy/dft/fftpack_lite.so
b72eb000-b72ec000 rw-p 00008000 03:05 
212480     /usr/local/lib/python2.4/site-packages/numpy/dft/fftpack_lite.so
b72ec000-b758c000 r-xp 00000000 03:05 
212489     /usr/local/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so
b758c000-b758e000 rw-p 0029f000 03:05 
212489     /usr/local/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so
b758e000-b75ef000 rw-p b758e000 00:00 0
b75ef000-b75f2000 r-xp 00000000 03:05 
208618     /usr/local/lib/python2.4/lib-dynload/math.so
b75f2000-b75f3000 rw-p 00002000 03:05 
208618     /usr/local/lib/python2.4/lib-dynload/math.so
b75f3000-b75f5000 r-xp 00000000 03:05 
212481     /usr/local/lib/python2.4/site-packages/numpy/lib/_compiled_base.so
b75f5000-b75f6000 rw-p 00002000 03:05 
212481     /usr/local/lib/python2.4/site-packages/numpy/lib/_compiled_base.so
b75f6000-b7610000 r-xp 00000000 03:05 
212486     /usr/local/lib/python2.4/site-packages/numpy/core/scalarmath.so
b7610000-b7611000 rw-p 00019000 03:05 
212486     /usr/local/lib/python2.4/site-packages/numpy/core/scalarmath.so
b7611000-b7614000 r-xp 00000000 03:05 
208625     /usr/local/lib/python2.4/lib-dynload/mmap.so
b7614000-b7615000 rw-p 00003000 03:05 
208625     /usr/local/lib/python2.4/lib-dynload/mmap.so
b7615000-b7656000 rw-p b7615000 00:00 0
b7656000-b765a000 r-xp 00000000 03:05 
208644     /usr/local/lib/python2.4/lib-dynload/strop.so
b765a000-b765c000 rw-p 00003000 03:05 
208644     /usr/local/lib/python2.4/lib-dynload/strop.so
b765c000-b765f000 r-xp 00000000 03:05 
208595     /usr/local/lib/python2.4/lib-dynload/cStringIO.so
b765f000-b7660000 rw-p 00003000 03:05 
208595     /usr/local/lib/python2.4/lib-dynload/cStringIO.so
b7660000-b7671000 r-xp 00000000 03:05 
208619     /usr/local/lib/python2.4/lib-dynload/cPickle.so
b7671000-b7672000 rw-p 00010000 03:05 
208619     /usr/local/lib/python2.4/lib-dynload/cPickle.so
b7672000-b7964000 r-xp 00000000 03:05 
212484     /usr/local/lib/python2.4/site-packages/numpy/core/_dotblas.so
b7964000-b7966000 rw-p 002f1000 03:05 
212484     /usr/local/lib/python2.4/site-packages/numpy/core/_dotblas.so
b7966000-b798e000 r-xp 00000000 03:05 
212487     /usr/local/lib/python2.4/site-packages/numpy/core/umath.so
b798e000-b7991000 rw-p 00027000 03:05 
212487     /usr/local/lib/python2.4/site-packages/numpy/core/umath.so
b7991000-b79d3000 rw-p b7991000 00:00 0
b79d3000-b7a28000 r-xp 00000000 03:05 
212482     /usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so
b7a28000-b7a32000 rw-p 00054000 03:05 
212482     /usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so
b7a32000-b7a6d000 r-xp 00000000 03:05 17777      /lib/libncurses.so.5.5
b7a6d000-b7a78000 rw-p 0003a000 03:05 17777      /lib/libncurses.so.5.5
b7a78000-b7a79000 rw-p b7a78000 00:00 0
b7a79000-b7aba000 r-xp 00000000 03:05 17792      /usr/lib/libncursesw.so.5.5
b7aba000-b7ac6000 rw-p 00040000 03:05 17792      /usr/lib/libncursesw.so.5.5
b7ac6000-b7af0000 r-xp 00000000 03:05 18393      /lib/libreadline.so.5.1
b7af0000-b7af4000 rw-p 0002a000 03:05 18393      /lib/libreadline.so.5.1
b7af4000-b7af5000 rw-p b7af4000 00:00 0
b7af5000-b7af8000 r-xp 00000000 03:05 
208646     /usr/local/lib/python2.4/lib-dynload/readline.so
b7af8000-b7af9000 rw-p 000030Aborted

[Numpy-discussion] Re: test AMBeBtEN

[Susannah S. <se...@ps...>]

Hi,
=20
S O M ^
A M B / E N
P R O Z ^ C
L E V / T R A
X ^ N A X
M E R / D / A
V A L / U M
V / A G R A
C / A L / S
=20
http://www.teminolvi.com
=20
=20
=20
=20
=20
And so Bilbo was swung down from the wall, and departed with nothing=20
for all his trouble, except the armour which Thorin had given him=20
already. More than one of the dwarves =18in their hearts felt shame and=20
pity at his going. Farewell! he cried to them. We may meet again as=20
friends. Be off! called Thorin. You have mail upon you, which was=20
made by my folk, and is too good for you. It cannot be pierced.by=20

Re: [Numpy-discussion] Re: numpy (?) bug.

[Simon B. <si...@ar...>]

On Mon, 22 May 2006 14:15:11 +0200
Martin Wiechert <mar...@gm...> wrote:

> #9  0xb7addd9f in PyUFunc_GenericReduction (self=0x80a49a0, args=0xb299152c, 
> kwds=<value optimized out>, operation=2)
>     at numpy/core/src/ufuncobject.c:2521

I was getting segfaults with version 0.9.7.2523:

#0  0xb7c5d612 in PyUFunc_GenericFunction (self=0x81b6d08, args=0x76484a40, mps=0xbfffad10) at ufuncobject.c:1484

An svn update fixed it.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

[Numpy-discussion] Power with negative exponent

[Ivan V. i B. <iv...@ca...>]

Hi all, when working with numexpr, I have come across a curiosity in
both numarray and numpy::

  In [30]:b =3D numpy.array([1,2,3,4])
  In [31]:b ** -1
  Out[31]:array([1, 0, 0, 0])
  In [32]:4 ** -1
  Out[32]:0.25
  In [33]:

According to http://docs.python.org/ref/power.html:

  For int and long int operands, the result has the same type as the
  operands (after coercion) unless the second argument is negative; in
  that case, all arguments are converted to float and a float result is
  delivered.

Then, shouldn=E2=80=99t be ``b ** -1 =3D=3D array([1.0, 0.5, 0.33333333, =
0.25])``?
Is this behaviour intentional?  (I googled for previous messages on the
topic but I didn=E2=80=99t find any.)

Thanks,

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       C=C3=A1rabos Coop. V.  V  V   Enjoy Data
	                          ""

Re: [Numpy-discussion] Re: numpy (?) bug.

[Martin W. <mar...@gm...>]

Robert,

Thanks for your reply. I have managed to get a gdb backtrace, see below. Does 
this help? Can I extract more useful information from gdb (never used it 
before)?

Btw. I have no problem showing my code (besides embarrassment), but I'm pretty 
certain you don't want to read it ;-) I'll try to narrow it down, but it's 
difficult, e.g. it doesn't seem to happen the first time the guilty code is 
executed but rather when it is called the third or fourth time or even later.

Thanks,
Martin.


On Monday 22 May 2006 13:21, Robert Kern wrote:
> Martin Wiechert wrote:
> > Hi list,
> >
> > I've a rather huge and involved application which now that I've updateded
> > a couple of its dependencies (numpy/PyQwt/ScientificPython ...) keeps
> > crashing on me after "certain patterns of interaction". I've pasted a
> > typical backtrace below, the top part looks always very similar, in
> > particular multiarray.so is always there. Also it's always an illegal
> > call to free ().
> >
> > So you gurus out there, does this mean that numpy is the culprit?
>
> Possibly. Without access to your code, it's impossible for us to tell and
> even more impossible for us to fix it. If you can narrow it down to the
> function in numpy.core.multiarray that's being called and the arguments you
> are passing to it, we might be able to do something.


(gdb) backtrace
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7c6b7d0 in raise () from /lib/libc.so.6
#2  0xb7c6cea3 in abort () from /lib/libc.so.6
#3  0xb7ca0f8b in __libc_message () from /lib/libc.so.6
#4  0xb7ca6911 in malloc_printerr () from /lib/libc.so.6
#5  0xb7ca7f84 in free () from /lib/libc.so.6
#6  0xb7ee2f31 in PyObject_Free (p=0x2) at Objects/obmalloc.c:798
#7  0xb7af9d97 in arraydescr_dealloc (self=0xb7b47ac0) at 
numpy/core/src/arrayobject.c:8956
#8  0xb7b12dca in array_dealloc (self=0x8714a18) at 
numpy/core/src/arrayobject.c:1477
#9  0xb7addd9f in PyUFunc_GenericReduction (self=0x80a49a0, args=0xb299152c, 
kwds=<value optimized out>, operation=2)
    at numpy/core/src/ufuncobject.c:2521
#10 0xb7edf64d in PyCFunction_Call (func=0xb2d2c82c, arg=0xb299152c, kw=0x6) 
at Objects/methodobject.c:77
#11 0xb7f1b42e in PyEval_EvalFrame (f=0x8299d24) at Python/ceval.c:3563
#12 0xb7f1c5c9 in PyEval_EvalCodeEx (co=0xb2f623a0, globals=0xb41e59bc, 
locals=0x0, args=0x812dd1c, argcount=1, kws=0x812dd20,
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736
#13 0xb7f1a62b in PyEval_EvalFrame (f=0x812db8c) at Python/ceval.c:3656
#14 0xb7f1c5c9 in PyEval_EvalCodeEx (co=0xb2f414a0, globals=0xb2f3a0b4, 
locals=0x0, args=0xb2d45c78, argcount=1, kws=0x869bdf8,
    kwcount=2, defs=0xb2d148f8, defcount=8, closure=0x0) at 
Python/ceval.c:2736
#15 0xb7ecbfce in function_call (func=0xb2d148b4, arg=0xb2d45c6c, 
kw=0xb28052d4) at Objects/funcobject.c:548
#16 0xb7eb0217 in PyObject_Call (func=0x5e02, arg=0xb2d45c6c, kw=0xb28052d4) 
at Objects/abstract.c:1795
#17 0xb7eb7b05 in instancemethod_call (func=0xb427e324, arg=0xb2d45c6c, 
kw=0xb28052d4) at Objects/classobject.c:2447
#18 0xb7eb0217 in PyObject_Call (func=0x5e02, arg=0xb7c0102c, kw=0xb28052d4) 
at Objects/abstract.c:1795
#19 0xb7ef792e in slot_tp_init (self=0xb27fdbac, args=0xb7c0102c, 
kwds=0xb28052d4) at Objects/typeobject.c:4759
#20 0xb7ef0ea5 in type_call (type=<value optimized out>, args=0xb7c0102c, 
kwds=0xb28052d4) at Objects/typeobject.c:435
#21 0xb7eb0217 in PyObject_Call (func=0x5e02, arg=0xb7c0102c, kw=0xb28052d4) 
at Objects/abstract.c:1795
#22 0xb7f18b9d in PyEval_EvalFrame (f=0x849ef24) at Python/ceval.c:3771
#23 0xb7f1c5c9 in PyEval_EvalCodeEx (co=0xb2d1b0a0, globals=0xb2d12f0c, 
locals=0x0, args=0x80ab9ec, argcount=2, kws=0x80ab9f4,
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736
#24 0xb7f1a62b in PyEval_EvalFrame (f=0x80ab88c) at Python/ceval.c:3656
#25 0xb7f1c5c9 in PyEval_EvalCodeEx (co=0xb7bd63e0, globals=0xb7bcd24c, 
locals=0x0, args=0xb297eee8, argcount=4, kws=0x0,
    kwcount=0, defs=0xb2d27d18, defcount=2, closure=0x0) at 
Python/ceval.c:2736
#26 0xb7ecbefa in function_call (func=0xb2d31b8c, arg=0xb297eedc, kw=0x0) at 
Objects/funcobject.c:548
#27 0xb7eb0217 in PyObject_Call (func=0x5e02, arg=0xb297eedc, kw=0x0) at 
Objects/abstract.c:1795
#28 0xb7eb7b05 in instancemethod_call (func=0xb427e2fc, arg=0xb297eedc, 
kw=0x0) at Objects/classobject.c:2447
#29 0xb7eb0217 in PyObject_Call (func=0x5e02, arg=0xb29a8d9c, kw=0x0) at 
Objects/abstract.c:1795
#30 0xb7f1591c in PyEval_CallObjectWithKeywords (func=0xb427e2fc, 
arg=0xb29a8d9c, kw=0x0) at Python/ceval.c:3430
#31 0xb3b48817 in initsip () 
from /usr/local/lib/python2.4/site-packages/sip.so
#32 0xb3c21b80 in initqt () from /usr/local/lib/python2.4/site-packages/qt.so
#33 0xb36beb5d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#34 0xb3a0a686 in QListView::doubleClicked () from /usr/lib/libqt-mt.so.3
#35 0xb37a2908 in QListView::contentsMouseDoubleClickEvent () 
from /usr/lib/libqt-mt.so.3
#36 0xb3e10e7c in initqt () from /usr/local/lib/python2.4/site-packages/qt.so
#37 0xb37d4345 in QScrollView::viewportMouseDoubleClickEvent () 
from /usr/lib/libqt-mt.so.3
#38 0xb3e107bc in initqt () from /usr/local/lib/python2.4/site-packages/qt.so
#39 0xb37d1821 in QScrollView::eventFilter () from /usr/lib/libqt-mt.so.3
#40 0xb379fc96 in QListView::eventFilter () from /usr/lib/libqt-mt.so.3
#41 0xb3e0caab in initqt () from /usr/local/lib/python2.4/site-packages/qt.so
#42 0xb36be45c in QObject::activate_filters () from /usr/lib/libqt-mt.so.3
#43 0xb36be4cb in QObject::event () from /usr/lib/libqt-mt.so.3
#44 0xb36f74fc in QWidget::event () from /usr/lib/libqt-mt.so.3
#45 0xb365fc47 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#46 0xb3660b6b in QApplication::notify () from /usr/lib/libqt-mt.so.3
#47 0xb3fe1f05 in initqt () from /usr/local/lib/python2.4/site-packages/qt.so
#48 0xb35ffc42 in QETWidget::translateMouseEvent () 
from /usr/lib/libqt-mt.so.3
#49 0xb35fee16 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3
#50 0xb360f45a in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#51 0xb3676a78 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#52 0xb367690e in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#53 0xb365f7ff in QApplication::exec () from /usr/lib/libqt-mt.so.3
#54 0xb3fdfd6e in initqt () from /usr/local/lib/python2.4/site-packages/qt.so
#55 0xb7edf67d in PyCFunction_Call (func=0xb2f42c8c, arg=0xb7c0102c, kw=0x0) 
at Objects/methodobject.c:108
#56 0xb7f1b42e in PyEval_EvalFrame (f=0x80577d4) at Python/ceval.c:3563
#57 0xb7f1c5c9 in PyEval_EvalCodeEx (co=0xb7be1360, globals=0xb7c19824, 
locals=0xb7c19824, args=0x0, argcount=0, kws=0x0,
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736
#58 0xb7f1c643 in PyEval_EvalCode (co=0xb7be1360, globals=0xb7c19824, 
locals=0xb7c19824) at Python/ceval.c:484
#59 0xb7f415c7 in PyRun_FileExFlags (fp=0x804a008, filename=0xbfb61faf 
"onset_view.py", start=257, globals=0xb7c19824,
    locals=0xb7c19824, closeit=1, flags=0xbfb60814) at Python/pythonrun.c:1265
#60 0xb7f417c8 in PyRun_SimpleFileExFlags (fp=0x804a008, filename=0xbfb61faf 
"onset_view.py", closeit=1, flags=0xbfb60814)
    at Python/pythonrun.c:860
#61 0xb7f41aba in PyRun_AnyFileExFlags (fp=0x804a008, filename=0xbfb61faf 
"onset_view.py", closeit=1, flags=0xbfb60814)
    at Python/pythonrun.c:664
#62 0xb7f47f3d in Py_Main (argc=1, argv=0xbfb608e4) at Modules/main.c:493
#63 0x080485e2 in main (argc=Cannot access memory at address 0x5e02
) at Modules/python.c:23

[Numpy-discussion] Re: numpy (?) bug.

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

Martin Wiechert wrote:
> Hi list,
> 
> I've a rather huge and involved application which now that I've updateded a 
> couple of its dependencies (numpy/PyQwt/ScientificPython ...) keeps crashing 
> on me after "certain patterns of interaction". I've pasted a typical 
> backtrace below, the top part looks always very similar, in particular 
> multiarray.so is always there. Also it's always an illegal call to free ().
> 
> So you gurus out there, does this mean that numpy is the culprit?

Possibly. Without access to your code, it's impossible for us to tell and even
more impossible for us to fix it. If you can narrow it down to the function in
numpy.core.multiarray that's being called and the arguments you are passing to
it, we might be able to do something.

-- 
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] numpy (?) bug.

[Martin W. <mar...@gm...>]

Hi list,

I've a rather huge and involved application which now that I've updateded a 
couple of its dependencies (numpy/PyQwt/ScientificPython ...) keeps crashing 
on me after "certain patterns of interaction". I've pasted a typical 
backtrace below, the top part looks always very similar, in particular 
multiarray.so is always there. Also it's always an illegal call to free ().

So you gurus out there, does this mean that numpy is the culprit?

Any help would be appreciated.

Thanks,
Martin



*** glibc detected *** python: free(): invalid pointer: 0xb7a95ac0 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7c00911]
/lib/libc.so.6(__libc_free+0x84)[0xb7c01f84]
/usr/local/lib/libpython2.4.so.1.0(PyObject_Free+0x51)[0xb7e3cf31]
/usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so[0xb7a47d97]
/usr/local/lib/python2.4/site-packages/numpy/core/multiarray.so[0xb7a60dca]
/usr/local/lib/python2.4/site-packages/numpy/core/umath.so[0xb7a2bd9f]
/usr/local/lib/libpython2.4.so.1.0(PyCFunction_Call+0x11d)[0xb7e3964d]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4e8e)[0xb7e7542e]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x869)[0xb7e765c9]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x408b)[0xb7e7462b]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x869)[0xb7e765c9]
/usr/local/lib/libpython2.4.so.1.0[0xb7e25fce]
/usr/local/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0xb7e0a217]
/usr/local/lib/libpython2.4.so.1.0[0xb7e11b05]
/usr/local/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0xb7e0a217]
/usr/local/lib/libpython2.4.so.1.0[0xb7e5192e]
/usr/local/lib/libpython2.4.so.1.0[0xb7e4aea5]
/usr/local/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0xb7e0a217]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x25fd)[0xb7e72b9d]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x869)[0xb7e765c9]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x408b)[0xb7e7462b]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x869)[0xb7e765c9]
/usr/local/lib/libpython2.4.so.1.0[0xb7e25efa]
/usr/local/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0xb7e0a217]
/usr/local/lib/libpython2.4.so.1.0[0xb7e11b05]
/usr/local/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0xb7e0a217]
/usr/local/lib/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x7c)
[0xb7e6f91c]
/usr/local/lib/python2.4/site-packages/sip.so[0xb3aa2817]
/usr/local/lib/python2.4/site-packages/qt.so[0xb3b7bb80]
/usr/lib/libqt-mt.so.3
(_ZN7QObject15activate_signalEP15QConnectionListP8QUObject+0x16d)[0xb3618b5d]
/usr/lib/libqt-mt.so.3
(_ZN9QListView13doubleClickedEP13QListViewItemRK6QPointi+0xe6)[0xb3964686]
/usr/lib/libqt-mt.so.3
(_ZN9QListView29contentsMouseDoubleClickEventEP11QMouseEvent+0x168)
[0xb36fc908]
/usr/local/lib/python2.4/site-packages/qt.so[0xb3d6ae7c]
/usr/lib/libqt-mt.so.3
(_ZN11QScrollView29viewportMouseDoubleClickEventEP11QMouseEvent+0xa5)
[0xb372e345]
/usr/local/lib/python2.4/site-packages/qt.so[0xb3d6a7bc]
/usr/lib/libqt-mt.so.3(_ZN11QScrollView11eventFilterEP7QObjectP6QEvent+0x1e1)
[0xb372b821]
/usr/lib/libqt-mt.so.3(_ZN9QListView11eventFilterEP7QObjectP6QEvent+0xa6)
[0xb36f9c96]
/usr/local/lib/python2.4/site-packages/qt.so[0xb3d66aab]
/usr/lib/libqt-mt.so.3(_ZN7QObject16activate_filtersEP6QEvent+0x5c)
[0xb361845c]
/usr/lib/libqt-mt.so.3(_ZN7QObject5eventEP6QEvent+0x3b)[0xb36184cb]
/usr/lib/libqt-mt.so.3(_ZN7QWidget5eventEP6QEvent+0x2c)[0xb36514fc]
/usr/lib/libqt-mt.so.3
(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0x97)[0xb35b9c47]
/usr/lib/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x1cb)
[0xb35bab6b]
/usr/local/lib/python2.4/site-packages/qt.so[0xb3f3bf05]
/usr/lib/libqt-mt.so.3(_ZN9QETWidget19translateMouseEventEPK7_XEvent+0x4c2)
[0xb3559c42]
/usr/lib/libqt-mt.so.3(_ZN12QApplication15x11ProcessEventEP7_XEvent+0x916)
[0xb3558e16]
/usr/lib/libqt-mt.so.3(_ZN10QEventLoop13processEventsEj+0x4aa)[0xb356945a]
/usr/lib/libqt-mt.so.3(_ZN10QEventLoop9enterLoopEv+0x48)[0xb35d0a78]
/usr/lib/libqt-mt.so.3(_ZN10QEventLoop4execEv+0x2e)[0xb35d090e]
/usr/lib/libqt-mt.so.3(_ZN12QApplication4execEv+0x1f)[0xb35b97ff]
/usr/local/lib/python2.4/site-packages/qt.so[0xb3f39d6e]
/usr/local/lib/libpython2.4.so.1.0(PyCFunction_Call+0x14d)[0xb7e3967d]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4e8e)[0xb7e7542e]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x869)[0xb7e765c9]
/usr/local/lib/libpython2.4.so.1.0(PyEval_EvalCode+0x63)[0xb7e76643]
/usr/local/lib/libpython2.4.so.1.0(PyRun_FileExFlags+0xb7)[0xb7e9b5c7]
/usr/local/lib/libpython2.4.so.1.0(PyRun_SimpleFileExFlags+0x198)[0xb7e9b7c8]
/usr/local/lib/libpython2.4.so.1.0(PyRun_AnyFileExFlags+0x7a)[0xb7e9baba]
/usr/local/lib/libpython2.4.so.1.0(Py_Main+0xbad)[0xb7ea1f3d]
python(main+0x32)[0x80485e2]
/lib/libc.so.6(__libc_start_main+0xdc)[0xb7bb287c]
python[0x8048521]
======= Memory map: ========
08048000-08049000 r-xp 00000000 03:05 205745     /usr/local/bin/python
08049000-0804a000 rw-p 00000000 03:05 205745     /usr/local/bin/python
0804a000-087cc000 rw-p 0804a000 00:00 0          [heap]
b1f00000-b1f21000 rw-p b1f00000 00:00 0
b1f21000-b2000000 ---p b1f21000 00:00 0
b204b000-b21d7000 rw-p b204b000 00:00 0
b229d000-b24ef000 rw-p b229d000 00:00 0
b2551000-b2583000 rw-p b2551000 00:00 0
b25b5000-b25e7000 rw-p b25b5000 00:00 0
b2619000-b2713000 rw-p b2619000 00:00 0
b2745000-b2786000 rw-p b2745000 00:00 0
b2786000-b278f000 r-xp 00000000 03:05 
42242      /usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2
b278f000-b2790000 rw-p 00008000 03:05 
42242      /usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2
b2790000-b27d6000 r--p 00000000 03:05 
47073      /var/X11R6/compose-cache/l2_024_35fe9fba
b27d6000-b27f1000 r-xp 00000000 03:05 
42237      /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
b27f1000-b27f3000 rw-p 0001b000 03:05 
42237      /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
b27f3000-b2816000 r-xp 00000000 03:05 
43814      /usr/lib/qt3/plugins/inputmethods/libqsimple.so
b2816000-b2817000 rw-p 00022000 03:05 
43814      /usr/lib/qt3/plugins/inputmethods/libqsimple.so
b2817000-b281f000 r-xp 00000000 03:05 13957      /lib/libnss_files-2.4.so
b281f000-b2821000 rw-p 00007000 03:05 13957      /lib/libnss_files-2.4.so
b2821000-b2832000 r-xp 00000000 03:05 13951      /lib/libnsl-2.4.so
b2832000-b2834000 rw-p 00010000 03:05 13951      /lib/libnsl-2.4.so
b2834000-b2836000 rw-p b2834000 00:00 0
b2836000-b2860000 r-xp 00000000 03:05 
61788      /opt/kde3/lib/libkdefx.so.4.2.0
b2860000-b2862000 rw-p 00029000 03:05 
61788      /opt/kde3/lib/libkdefx.so.4.2.0
b2862000-b2878000 r-xp 00000000 03:05 
61766      /opt/kde3/lib/kde3/plugins/styles/light.so
b2878000-b2879000 rw-p 00015000 03:05 
61766      /opt/kde3/lib/kde3/plugins/styles/light.so
b2879000-b289a000 r--p 00000000 03:05 
36221      /usr/X11R6/lib/X11/fonts/truetype/DejaVuSerif.ttf
b28a8000-b28c8000 r--p 00000000 03:05 
36218      /usr/X11R6/lib/X11/fonts/truetype/DejaVuSerif-Bold.ttf
b28c8000-b2909000 rw-p b28c8000 00:00 0
b2909000-b2934000 r-xp 00000000 03:05 19354      /usr/lib/liblcms.so.1.0.15
b2934000-b2936000 rw-p 0002a000 03:05 19354      /usr/lib/liblcms.so.1.0.15
b2936000-b2938000 rw-p b2936000 00:00 0
b2938000-b29a5000 r-xp 00000000 03:05 21150      /usr/lib/libmng.so.1.1.0.9
b29a5000-b29a8000 rw-p 0006c000 03:05 21150      /usr/lib/libmng.so.1.1.0.9
b29ab000-b29b3000 r-xp 00000000 03:05 
43815      /usr/lib/qt3/plugins/inputmethods/libqxim.so
b29b3000-b29b4000 rw-p 00008000 03:05 
43815      /usr/lib/qt3/plugins/inputmethods/libqxim.so
b29b4000-b29b7000 r-xp 00000000 03:05 
43813      /usr/lib/qt3/plugins/inputmethods/libqimsw-none.so
b29b7000-b29b8000 rw-p 00003000 03:05 
43813      /usr/lib/qt3/plugins/inputmethods/libqimsw-none.so
b29b8000-b29bf000 r-xp 00000000 03:05 
43812      /usr/lib/qt3/plugins/inputmethods/libqimsw-multi.so
b29bf000-b29c0000 rw-p 00007000 03:05 
43812      /usr/lib/qt3/plugins/inputmethods/libqimsw-multi.so
b29c0000-b29de000 r-xp 00000000 03:05 17664      /usr/lib/libjpeg.so.62.0.0
b29de000-b29df000 rw-p 0001d000 03:05 17664      /usr/lib/libjpeg.so.62.0.0
b29e0000-b29e8000 r-xp 00000000 03:05 13961      /lib/libnss_nis-2.4.so
b29e8000-b29ea000 rw-p 00007000 03:05 13961      /lib/libnss_nis-2.4.so
b29ea000-b29f0000 r-xp 00000000 03:05 13953      /lib/libnss_compat-2.4.so
b29f0000-b29f2000 rw-p 00005000 03:05 13953      /lib/libnss_compat-2.4.so
b29f2000-b29f6000 r-xp 00000000 03:05 
43810      /usr/lib/qt3/plugins/imageformats/libqmng.so
b29f6000-b29f7000 rw-p 00003000 03:05 
43810      /usr/lib/qt3/plugins/imageformats/libqmng.so
b29f7000-b29f8000 r-xp 00000000 03:05 
42239      /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
b29f8000-b29f9000 rw-p 00000000 03:05 
42239      /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
b29f9000-b29ff000 r--s 00001000 03:05 
68835      /var/cache/fontconfig/d0814903482a18ed8717ceb08fcf4410.cache-2
b29ff000-b2a04000 r--s 00001000 0Aborted

Re: [Numpy-discussion] casting homogeneous struct arrays

[Simon B. <si...@ar...>]

On Mon, 22 May 2006 01:47:38 -0600
Travis Oliphant <oli...@ie...> wrote:

> 
> Simon Burton wrote:
> > This is something I will need to be able do:
> >
> >   
> >>>> a=numpy.array( [(1,2,3)], list('lll') )
> >>>>         
> >>>> a.astype( 'l' )
> >>>>         
> 
> Currently record-arrays can't be cast like this to built-in types.   
> it's true the error message could be more informative.
> 
> What do you think should actually be done here anyway?  How do you want 
> to cast 3 long's to 1 long? 

with shape = (1,3).

I am visualizing the fields as columns, and when
the array is homogeneous it seems natural to be able to switch between the
two array types.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 

Re: [Numpy-discussion] casting homogeneous struct arrays

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

Simon Burton wrote:
> This is something I will need to be able do:
>
>   
>>>> a=numpy.array( [(1,2,3)], list('lll') )
>>>>         
>>>> a.astype( 'l' )
>>>>         

Currently record-arrays can't be cast like this to built-in types.   
it's true the error message could be more informative.

What do you think should actually be done here anyway?  How do you want 
to cast 3 long's to 1 long? 

You can use the .view method to view a record-array as a different 
data-type without going through a data-copy using tostring and fromstring.

-Travis

[Numpy-discussion] Wetsuit

[winnie <win...@ya...>]

Multi Neoprene Factory
Product name: Wetsuit (shorties --style no. S015) 
The materials : 2mm Neoprene
QTY:2,000PCS 
The price : USD8.00/pc
Delivery : FOB Shenzhen China
see the attached


http://home.netvigator.com/~sky888s/ 


Thanks, 

 
Winnie

[Numpy-discussion] casting homogeneous struct arrays

[Simon B. <si...@ar...>]

This is something I will need to be able do:

>>> a=numpy.array( [(1,2,3)], list('lll') )
>>> a.astype( 'l' )
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: an integer is required

(and what a strange error message).

Is there a workaround ?
.tostring/.fromstring incurs a memcopy copy, if i am not mistaken.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com