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

Re: [Numpy-discussion] Defining custom types

[Jonathan W. <jon...@gm...>]

On 10/27/06, Travis Oliphant <oli...@ie...> wrote:
>
> Jonathan Wang wrote:
> > On 10/27/06, *Travis Oliphant* <oli...@ie...
> > <mailto:oli...@ie...>> wrote:
> >
> >     > If I redefine the string function, I encounter another, perhaps
> more
> >     > serious problem leading to a segfault. I've defined my string
> >     function
> >     > to be extremely simple:
> >     > >>> def printer(arr):
> >     > ...   return str(arr[0])
> >     >
> >     > Now, if I try to print an element of the array:
> >     > >>> mxArr[0]
> >     >
> >     > I get to this stack trace:
> >     > #0  scalar_value (scalar=0x814be10, descr=0x5079e0) at
> >     > scalartypes.inc.src:68
> >     > #1  0x0079936a in PyArray_Scalar (data=0x814cf98, descr=0x5079e0,
> >     > base=0x814e7a8) at arrayobject.c:1419
> >     > #2  0x007d259f in array_subscript_nice (self=0x814e7a8,
> >     op=0x804eb8c)
> >     > at arrayobject.c:1985
> >     > #3  0x00d17dde in PyObject_GetItem (o=0x814e7a8, key=0x804eb8c) at
> >     > Objects/abstract.c:94
> >     >
> >     > (Note: for some reason gdb claims that arrayobject.c:1985 is
> >     > array_subscript_nice, but looking at my source this line is
> >     actually
> >     > in array_item_nice. *boggle*)
> >     >
> >     > But scalar_value returns NULL for all non-native types. So,
> >     destptr in
> >     > PyArray_Scalar is set to NULL, and the call the copyswap
> segfaults.
> >     >
> >     > Perhaps scalar_value should be checking the scalarkind field of
> >     > PyArray_Descr, or using the elsize and alignment fields to
> >     figure out
> >     > the pointer to return if scalarkind isn't set?
> >
> >     Hmmm... It looks like the modifications to scalar_value did not take
> >     into account user-defined types.  I've added a correction so that
> >     user-defined types will use setitem to set the scalar value into the
> >     array.  Presumably your setitem function can handle setting the
> array
> >     with scalars of your new type?
> >
> >     I've checked the changes into SVN.
> >
> >
> > Do there also need to be changes in scalartypes.inc.src to use getitem
> > if a user-defined type does not inherit from a Numpy scalar?
> This needs to be clarified.  I don't think it's possible to do it
> without inheriting from a numpy scalar at this point (the void numpy
> scalar can be inherited from and is pretty generic).  I know I was not
> considering that case when I wrote the code.
> > i.e. at scalartypes.inc.src:114 we should return some pointer
> > calculated from the PyArray_Descr's elsize and alignment field to get
> > the destination for the "custom scalar" type to be copied.
> I think this is a good idea.  I doubt it's enough to fix all places that
> don't inherit from numpy scalars, but it's a start.
>
> It seems like we need to figure out where the beginning of the data is
> for the type which is assumed to be defined on alignment boundaries
> after a PyObject_HEAD  (right)?  This could actually be used for
> everything and all the switch and if statements eliminated.
>
> I think the alignment field is the only thing needed, though.  I don't
> see how I would use the elsize field?


Hmm, yeah, I guess alignment would be sufficient. Worst case, you could
delegate to setitem, right?

It would be useful to support arbitrary types. Suppose, for example, that I
wanted to make an array of structs. In keeping with the date/time example, I
might want to store a long and a double, the long for days in the Gregorian
calendar and the double for seconds from midnight on that day.

> Furthermore it seems like the scalar conversions prefer the builtin
> > types, but it seems to me that the user-defined type should be
> preferred.
> I'm not sure what this means.
> >
> >
> > i.e. if I try to get an element from my mxDateTime array, I get a
> > float back:
> > >>> mxArr[0] = DateTime.now()
> > >>> mxArr[0][0]
> > 732610.60691268521
> Why can you index mxArr[0]?  What is mxArr[0]?  If it's a scalar, then
> why can you index it?  What is type(mxArr[0])?


Ah, I am mistaken here - I am correctly getting my mxNumpyDateTime type
back:

mxArr is a 1x1 matrix:

>>> mxArr = numpy.empty((1,1), dtype = libMxNumpy.type)
>>> mxArr[0] = DateTime.now()
>>> type(mxArr)
<type 'numpy.ndarray'>
>>> type(mxArr[0])
<type 'numpy.ndarray'>
>>> type(mxArr[0][0])
<type 'mxNumpyDateTime'>
>>> mxArr.shape
(1, 1)


> But what I really want is the mxDateTime, which, oddly enough, is what
> > happens if I use tolist():
> > >>> mxArr.tolist()[0]
> > [<DateTime object for '2006-10-27 14:33:57.25' at a73c60>]
>
> That's not surprising because tolist just calls getitem on each element
> in the array to construct the list.


I guess this is a degenerate case, since I have getitem returning a
mxDateTime while the actual type of the elements in the array is
mxNumpyDateTime (i.e. mxNumpyType). Would the correct behavior, then, be for
getitem to return a mxNumpyDateTime and register the object cast function to
return a mxDateTime?

If I try to do math on the array, it seems like the operation is performed
via object pointers (mxDateTime - mxDateTime returns a DateTimeDelta object,
and mxNumpyDateTime is a float):
>>> mxArr = numpy.empty((1,1), dtype = libMxNumpy.type)
>>> mxArr[0][0] = DateTime.now()
>>> mxArr2 = numpy.empty((1,1), dtype = libMxNumpy.type)
>>> mxArr2[0][0] = DateTime.DateTimeFrom('2006-01-01')
>>> type(mxArr[0][0])
<type 'mxNumpyDateTime'>
>>> type(mxArr2[0][0])
<type 'mxNumpyDateTime'>
>>> sub = mxArr - mxArr2
>>> type(sub[0][0])
<type 'DateTimeDelta'>

I'm guessing I need to register ufunc loops for all the basic math on my
types?

Re: [Numpy-discussion] Sorting eigenvalues and vectors together

[Sven S. <sve...@gm...>]

jeremito schrieb:
> argsort() will do the trick.  Thanks once again.  
> Jeremy
> 

I was a bit confused by your question, maybe you can clarify what you
did in the end.

IIRC, if the eigenvalues returned by numpy are real numbers (due to the
type of the underlying matrix and algorithm), then they are
automatically returned  ascending (again, IIRC). That would mean you
don't have to do anything. But if they're complex, it's not obvious how
to sort them. Probably by modulus. So what exactly was your problem?

ciao,
Sven

Re: [Numpy-discussion] Sorting eigenvalues and vectors together

[jeremito <jer...@gm...>]

argsort() will do the trick.  Thanks once again.  
Jeremy

Re: [Numpy-discussion] Defining custom types

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

Jonathan Wang wrote:
> On 10/27/06, *Travis Oliphant* <oli...@ie... 
> <mailto:oli...@ie...>> wrote:
>
>     > If I redefine the string function, I encounter another, perhaps more
>     > serious problem leading to a segfault. I've defined my string
>     function
>     > to be extremely simple:
>     > >>> def printer(arr):
>     > ...   return str(arr[0])
>     >
>     > Now, if I try to print an element of the array:
>     > >>> mxArr[0]
>     >
>     > I get to this stack trace:
>     > #0  scalar_value (scalar=0x814be10, descr=0x5079e0) at
>     > scalartypes.inc.src:68
>     > #1  0x0079936a in PyArray_Scalar (data=0x814cf98, descr=0x5079e0,
>     > base=0x814e7a8) at arrayobject.c:1419
>     > #2  0x007d259f in array_subscript_nice (self=0x814e7a8,
>     op=0x804eb8c)
>     > at arrayobject.c:1985
>     > #3  0x00d17dde in PyObject_GetItem (o=0x814e7a8, key=0x804eb8c) at
>     > Objects/abstract.c:94
>     >
>     > (Note: for some reason gdb claims that arrayobject.c:1985 is
>     > array_subscript_nice, but looking at my source this line is
>     actually
>     > in array_item_nice. *boggle*)
>     >
>     > But scalar_value returns NULL for all non-native types. So,
>     destptr in
>     > PyArray_Scalar is set to NULL, and the call the copyswap segfaults.
>     >
>     > Perhaps scalar_value should be checking the scalarkind field of
>     > PyArray_Descr, or using the elsize and alignment fields to
>     figure out
>     > the pointer to return if scalarkind isn't set?
>
>     Hmmm... It looks like the modifications to scalar_value did not take
>     into account user-defined types.  I've added a correction so that
>     user-defined types will use setitem to set the scalar value into the
>     array.  Presumably your setitem function can handle setting the array
>     with scalars of your new type?
>
>     I've checked the changes into SVN. 
>
>
> Do there also need to be changes in scalartypes.inc.src to use getitem 
> if a user-defined type does not inherit from a Numpy scalar?
This needs to be clarified.  I don't think it's possible to do it 
without inheriting from a numpy scalar at this point (the void numpy 
scalar can be inherited from and is pretty generic).  I know I was not 
considering that case when I wrote the code.
> i.e. at scalartypes.inc.src:114 we should return some pointer 
> calculated from the PyArray_Descr's elsize and alignment field to get 
> the destination for the "custom scalar" type to be copied.
I think this is a good idea.  I doubt it's enough to fix all places that 
don't inherit from numpy scalars, but it's a start.

It seems like we need to figure out where the beginning of the data is 
for the type which is assumed to be defined on alignment boundaries 
after a PyObject_HEAD  (right)?  This could actually be used for 
everything and all the switch and if statements eliminated.

I think the alignment field is the only thing needed, though.  I don't 
see how I would use the elsize field?
>
> As it stands, if the user-defined type does not inherit from a Numpy 
> scalar, lots of things continue to break.
Not surprising, I did not make sure and support this.

> Furthermore it seems like the scalar conversions prefer the builtin 
> types, but it seems to me that the user-defined type should be preferred.
I'm not sure what this means. 
>
>
> i.e. if I try to get an element from my mxDateTime array, I get a 
> float back:
> >>> mxArr[0] = DateTime.now()
> >>> mxArr[0][0]
> 732610.60691268521
Why can you index mxArr[0]?  What is mxArr[0]?  If it's a scalar, then 
why can you index it?  What is type(mxArr[0])?

>
> But what I really want is the mxDateTime, which, oddly enough, is what 
> happens if I use tolist():
> >>> mxArr.tolist()[0]
> [<DateTime object for '2006-10-27 14:33:57.25' at a73c60>]

That's not surprising because tolist just calls getitem on each element 
in the array to construct the list.

-Travis

Re: [Numpy-discussion] Defining custom types

[Jonathan W. <jon...@gm...>]

On 10/27/06, Travis Oliphant <oli...@ie...> wrote:
>
> > If I redefine the string function, I encounter another, perhaps more
> > serious problem leading to a segfault. I've defined my string function
> > to be extremely simple:
> > >>> def printer(arr):
> > ...   return str(arr[0])
> >
> > Now, if I try to print an element of the array:
> > >>> mxArr[0]
> >
> > I get to this stack trace:
> > #0  scalar_value (scalar=0x814be10, descr=0x5079e0) at
> > scalartypes.inc.src:68
> > #1  0x0079936a in PyArray_Scalar (data=0x814cf98, descr=0x5079e0,
> > base=0x814e7a8) at arrayobject.c:1419
> > #2  0x007d259f in array_subscript_nice (self=0x814e7a8, op=0x804eb8c)
> > at arrayobject.c:1985
> > #3  0x00d17dde in PyObject_GetItem (o=0x814e7a8, key=0x804eb8c) at
> > Objects/abstract.c:94
> >
> > (Note: for some reason gdb claims that arrayobject.c:1985 is
> > array_subscript_nice, but looking at my source this line is actually
> > in array_item_nice. *boggle*)
> >
> > But scalar_value returns NULL for all non-native types. So, destptr in
> > PyArray_Scalar is set to NULL, and the call the copyswap segfaults.
> >
> > Perhaps scalar_value should be checking the scalarkind field of
> > PyArray_Descr, or using the elsize and alignment fields to figure out
> > the pointer to return if scalarkind isn't set?
>
> Hmmm... It looks like the modifications to scalar_value did not take
> into account user-defined types.  I've added a correction so that
> user-defined types will use setitem to set the scalar value into the
> array.  Presumably your setitem function can handle setting the array
> with scalars of your new type?
>
> I've checked the changes into SVN.


Do there also need to be changes in scalartypes.inc.src to use getitem if a
user-defined type does not inherit from a Numpy scalar? i.e. at
scalartypes.inc.src:114 we should return some pointer calculated from the
PyArray_Descr's elsize and alignment field to get the destination for the
"custom scalar" type to be copied.

As it stands, if the user-defined type does not inherit from a Numpy scalar,
lots of things continue to break. Furthermore it seems like the scalar
conversions prefer the builtin types, but it seems to me that the
user-defined type should be preferred.

i.e. if I try to get an element from my mxDateTime array, I get a float
back:
>>> mxArr[0] = DateTime.now()
>>> mxArr[0][0]
732610.60691268521

But what I really want is the mxDateTime, which, oddly enough, is what
happens if I use tolist():
>>> mxArr.tolist()[0]
[<DateTime object for '2006-10-27 14:33:57.25' at a73c60>]

Re: [Numpy-discussion] pyaudio, a module to make noise from numpy arrays

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

> David Cournapeau wrote:
>> Hi,
>>    I announce the first release of pyaudio, a module to make noise from 
>> numpy arrays (read, write and play audio files with numpy arrays).

Does this have anything to do with this pyaudio?

http://people.csail.mit.edu/hubert/pyaudio/

-Chris



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

Chr...@no...

Re: [Numpy-discussion] pyaudio, a module to make noise from numpy arrays

[<pe...@ce...>]

On Fri, 27 Oct 2006, Travis Oliphant wrote:

> David Cournapeau wrote:
> > Hi,
> >    I announce the first release of pyaudio, a module to make noise from 
> > numpy arrays (read, write and play audio files with numpy arrays).
> >   
> 
> Very nice.   Thank you.  I'd like to see exactly this kind of thing for 
> video files too.  We can get a lot of mileage out of ctypes. 
> 
> By the way.  I noticed your setup.py file is missing a .todict()  to 
> convert the configuration object into a dictionary that setup(** ) can 
> handle.
> 
> if __name__ == "__main__":
>     from numpy.distutils.core import setup
>     setup(**configuration(top_path='').todict())

Actually, one should use here

  setup(configuration=configuration)

Pearu

Re: [Numpy-discussion] pyaudio, a module to make noise from numpy arrays

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

David Cournapeau wrote:
> Hi,
>    I announce the first release of pyaudio, a module to make noise from 
> numpy arrays (read, write and play audio files with numpy arrays).
>   

Very nice.   Thank you.  I'd like to see exactly this kind of thing for 
video files too.  We can get a lot of mileage out of ctypes. 

By the way.  I noticed your setup.py file is missing a .todict()  to 
convert the configuration object into a dictionary that setup(** ) can 
handle.

if __name__ == "__main__":
    from numpy.distutils.core import setup
    setup(**configuration(top_path='').todict())


You might also check to see if libsndfile can be imported during the 
setup phase and then warn the user before installing that they need it.

Re: [Numpy-discussion] pyaudio, a module to make noise from numpy arrays

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

On 10/27/06, David L. Goldsmith <Dav...@no...> wrote:
> I'm sure some others _might_ regard this as frivolous, so let me just
> say: "Way Cool"!  Thanks!

+1, and not frivolous at all.  It's /really/ neat to be able to pull
in data from standard image formats (say jpeg) into arrays to quickly
do numerics on images.  Adding similar capabilities to audio signals
is, IMHO, a great contribution.  So I heartily join the
congratulation.

Cheers,

f

Re: [Numpy-discussion] Sorting eigenvalues and vectors together

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

jeremito wrote:
> I am using a = numpy.linalg.eig(A) to get the eigenvalues and
> eigenvectors.  I am interested only in the largest eigenvalue so I
> would like to sort the first element of a.  But if I do that, I won't
> know what is the associated eigenvector.  Is there a function that will
> sort the values and vectors together or do I need to write it myself.

Use argsort() on the eigenvalues and fancy indexing on the eigenvectors.

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

Re: [Numpy-discussion] dtype() examples that used to work

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

Joris De Ridder wrote:
> Hi,
>
> The following did once work in NumPy:
>
>   
>>>> dtype([int16])
>>>> dtype([[int16]])
>>>> dtype([uint,int32])
>>>> dtype(['f8','S10'])
>>>>         
>
> but now they all generate a "TypeError: data type not understood". Why?
> I could not find the answer in help(dtype), the RecordArrays tutorial on 
> scipy.org, the NumPy release notes, nor in the NumPy book.
>   

It's in the release notes.   Look in the section from 1.0b2 to 1.0b3.  
It's highlighted with a Note:

*NOTE: * When creating data-type objects from lists, the list must be in 
array descriptor format. The "list of data-type objects" approach is no 
longer supported due to its ambiguity with the very common array 
descriptor approach. You can still get this behavior using a 
comma-separated string or changing your list to an array_descriptor: 
[('', x) for x in oldlist]


-Travis

Re: [Numpy-discussion] numpy-1.0 regress failure on OpenBSD

[Damien M. <dj...@mi...>]

On Thu, 26 Oct 2006, Travis Oliphant wrote:

> Unless you want to help with tracking how long double is interpreted on 
> several platforms, then just ignore the test.  (It actually wasn't being 
> run in 1.0b1).

I'm happy to help - do you have a testcase that I can run on the various
platforms that OpenBSD supports?

-d

Re: [Numpy-discussion] pyaudio, a module to make noise from numpy arrays

[David L. G. <Dav...@no...>]

I'm sure some others _might_ regard this as frivolous, so let me just 
say: "Way Cool"!  Thanks!

DG

David Cournapeau wrote:
> Hi,
>    I announce the first release of pyaudio, a module to make noise from 
> numpy arrays (read, write and play audio files with numpy arrays).
>
> * WHAT FOR ?:
>
>    The Goal is to give to a numpy/scipy environmenet some basic audio IO 
> facilities (ala sound, wavread, wavwrite of matlab).
>
>    With pyaudio, you should be able to read and write most common audio 
> files from and to numpy arrays. The underlying IO operations are done 
> using libsndfile from Erik Castro Lopo 
> (http://www.mega-nerd.com/libsndfile/), so he is the one who did the 
> hard work. As libsndfile has support for a vast number of audio files 
> (including wav, aiff, but also htk, ircam, and flac, an open source 
> lossless codec), pyaudio enables the import from and export to a fairly 
> large number of file formats.
>    There is also a really crude player, which uses tempfile to play 
> audio, and which only works for linux-alsa anyway. I intend to add 
> better support at least for linux, and for other platforms if this does 
> not involve too much hassle.
>
>    So basically, if you are lucky enough to use a recent linux system, 
> pyaudio already gives you the equivalent of wavread, wavwrite and sound.
>
> * DOWNLOAD:
>
>    http://www.ar.media.kyoto-u.ac.jp/members/david/pyaudio.tar.gz
>
> * INSTALLATION INSTRUCTIONS:
>
>    Just untar the package and drop it into scipy/Lib/sandbox, and add 
> the two following lines to scipy/Lib/sandbox/setup.py:
>      
>    # Package to make some noise using numpy
>    config.add_subpackage('pyaudio')
>
>    (if libsndfile.so is not in /usr/lib, a fortiori if you are a windows 
> user, you should also change set the right location for libsndfile in 
> pyaudio/pysndfile.py, at the line 
> _snd.cdll.LoadLibrary('/usr/lib/libsndfile.so') )
>
> * EXAMPLE USAGE
>
>    == Reading example ==
>
>    # Reading from '/home/david/blop.flac'
>    from scipy.sandbox.pyaudio import sndfile
>
>    a = sndfile('/home/david/blop.flac')
>    print a
>
>    tmp = a.read_frames_float(1024)
>
>    --> Prints:
>
>    File        : /home/david/blop.flac
>    Sample rate : 44100
>    Channels    : 2
>    Frames      : 9979776
>    Format      : 0x00170002
>    Sections    : 1
>    Seekable    : True
>    Duration    : 00:03:46.298
>
>    And put into tmp the 1024 first frames (a frame is the equivalent of 
> a sample, but taking into account the number of channels: so 1024 frames 
> gives you 2048 samples here).
>
>    == Writing example ==
>    # Writing to a wavfile:
>    from scipy.sandbox.pyaudio import sndfile
>    import numpy as N
>
>    noise     = N.random.randn((44100))
>    a         = sndfile('/home/david/blop.flac', sfm['SFM_WRITE'], 
> sf_format['SF_FORMAT_WAV'] | sf_format['SF_FORMAT_PCM16'],
>        1, 44100)
>
>    a.write_frames(noise, 44100)
>    a.close()
>
>    -> should gives you a lossless compressed white noise !
>
>    This is really a first release, not really tested, not much 
> documentation, I can just say it works for me. I haven't found a good 
> way to emulate enumerations, which libsndfile uses a lot, so I am using 
> dictionaries generated from the library C header to get a relation enum 
> label <=> value. If someone has a better idea, I am open to suggestions !
>
>    Cheers,
>
>    David
>
> -------------------------------------------------------------------------
> 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] Sorting eigenvalues and vectors together

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

On 10/27/06, jeremito <jer...@gm...> wrote:
> I am using a = numpy.linalg.eig(A) to get the eigenvalues and
> eigenvectors.  I am interested only in the largest eigenvalue so I
> would like to sort the first element of a.  But if I do that, I won't
> know what is the associated eigenvector.  Is there a function that will
> sort the values and vectors together or do I need to write it myself.

You can get the ranking of the eigenvalues with idx =
a[0].argsort().argsort() or idx = (-a[0]).argsort().argsort(). And
then use that to sort both the eigenvalues and eigenvectors.

Re: [Numpy-discussion] Sorting eigenvalues and vectors together

[A. M. A. <per...@gm...>]

On 27/10/06, jeremito <jer...@gm...> wrote:
> I am using a = numpy.linalg.eig(A) to get the eigenvalues and
> eigenvectors.  I am interested only in the largest eigenvalue so I
> would like to sort the first element of a.  But if I do that, I won't
> know what is the associated eigenvector.  Is there a function that will
> sort the values and vectors together or do I need to write it myself.

I think that they are sorted, but argsort() will do what you want (or
argmax(), even).

A. M. Archibald

[Numpy-discussion] Sorting eigenvalues and vectors together

[jeremito <jer...@gm...>]

I am using a = numpy.linalg.eig(A) to get the eigenvalues and
eigenvectors.  I am interested only in the largest eigenvalue so I
would like to sort the first element of a.  But if I do that, I won't
know what is the associated eigenvector.  Is there a function that will
sort the values and vectors together or do I need to write it myself.
Thanks,
Jeremy

Re: [Numpy-discussion] dtype() examples that used to work

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

A Divendres 27 Octubre 2006 18:13, Joris De Ridder va escriure:
> Hi,
>
> The following did once work in NumPy:
> >>> dtype([int16])
> >>> dtype([[int16]])
> >>> dtype([uint,int32])
> >>> dtype(['f8','S10'])
>
> but now they all generate a "TypeError: data type not understood". Why?

Should be intended as well. If you try to set a dtype from a list, it has t=
o=20
follow the format of a description as specified in:

http://numpy.scipy.org/array_interface.shtml

for example:

In [67]: dtype([('f1', int16)])
Out[67]: dtype([('f1', '<i2')])

In [68]: dtype([('f1', int16, (2,2))])
Out[68]: dtype([('f1', '<i2', (2, 2))])

In [69]: dtype([('f1', int16, (2,2)), ('f3', int32)])
Out[69]: dtype([('f1', '<i2', (2, 2)), ('f3', '<i4')])

Cheers,

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

Re: [Numpy-discussion] astype() behaviour

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

A Divendres 27 Octubre 2006 17:58, Joris De Ridder va escriure:
> Hi,
>
> Is the following behaviour of astype() intentional in NumPy 1.0?
>
> >>> x =3D array([1,2,3])
> >>> x.astype(None)
>
> array([ 1.,  2.,  3.])
>
> That is, the int32 is converted to float64.

Yes, I think the behaviour is intended. This is because 'float64' is the=20
default type in NumPy from some months ago (before the default was 'int_')

HTH,

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

Re: [Numpy-discussion] Python Enhancement Proposal (PEP) - Current status?

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

Christopher Barker wrote:
> Travis Oliphant wrote:
>   
>> I'm working on two PEP's after discussing this with Guido at SciPy 2006. 
>>
>> 1) A data-type object PEP
>> 2) An extension of the buffer protocol to include the array interface.
>>
>> These are being done instead of the basearray PEP for now. 
>>     
>
> Those are a great starts, and I think it is a good idea to break these 
> out. Thanks for working on this.
>
> However, I still think it is a VERY good idea to have an n-d array in 
> the standard lib -- I hope that idea won't get forgotten.
>   

I think any nd-array in the standard library will just be an "Object" 
nd-array, though.

-Travis

Re: [Numpy-discussion] Python Enhancement Proposal (PEP) - Current status?

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

Travis Oliphant wrote:
> I'm working on two PEP's after discussing this with Guido at SciPy 2006. 
> 
> 1) A data-type object PEP
> 2) An extension of the buffer protocol to include the array interface.
> 
> These are being done instead of the basearray PEP for now. 

Those are a great starts, and I think it is a good idea to break these 
out. Thanks for working on this.

However, I still think it is a VERY good idea to have an n-d array in 
the standard lib -- I hope that idea won't get forgotten.

-Chris


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

Chr...@no...

[Numpy-discussion] dtype() examples that used to work

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

Hi,

The following did once work in NumPy:

>>> dtype([int16])
>>> dtype([[int16]])
>>> dtype([uint,int32])
>>> dtype(['f8','S10'])

but now they all generate a "TypeError: data type not understood". Why?
I could not find the answer in help(dtype), the RecordArrays tutorial on 
scipy.org, the NumPy release notes, nor in the NumPy book.

J.


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

[Numpy-discussion] astype() behaviour

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

Hi,

Is the following behaviour of astype() intentional in NumPy 1.0?

>>> x = array([1,2,3])
>>> x.astype(None)
array([ 1.,  2.,  3.])

That is, the int32 is converted to float64.

J.


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

Re: [Numpy-discussion] Python Enhancement Proposal (PEP) - Current status?

[Colin J. W. <cj...@sy...>]

Travis Oliphant wrote:
> Colin J. Williams wrote:
>   
>> A July posting sets out the intent:
>> http://scipy.org/BaseArray
>> Version 3 of the draft:
>> http://numpy.scipy.org/array_interface.shtml
>> There is a description, from a C Structure perspective:
>> http://svn.scipy.org/svn/PEP/PEP_basearray.txt
>>
>> What is the current status of the plan to develop a PEP?
>>
>> Is there a more recent version of the PEP, from a Python user's perspective?
>>
>>   
>>     
> I'm working on two PEP's after discussing this with Guido at SciPy 2006. 
>
> 1) A data-type object PEP
> 2) An extension of the buffer protocol to include the array interface.
>
> These are being done instead of the basearray PEP for now.  I'm hoping 
> to have a draft of these ready for discussion in a few weeks.
>
>
> -Travis
>
>   
Travis,

Many thanks, I'll watch out.

In an earlier draft, I believe it was proposed that the type specifier 
be a single character.

I hope that thought will be given to the use of something similar to 
dtype as the mnemonic codes are much more user-friendly than the letter 
codes.

Thanks also for all the slogging you have done over the last many months.

Colin W.

Re: [Numpy-discussion] Defining custom types

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

Jonathan Wang wrote:
> On 10/26/06, *Travis Oliphant* <oli...@ee... 
> <mailto:oli...@ee...>> wrote:
>
>     > Okay, is my understanding here correct? I am defining two type
>     > descriptors:
>     > PyArray_Descr mxNumpyType - describes the Numpy array type.
>     > PyTypeObject mxNumpyDataType - describes the data type of the
>     contents
>     > of the array (i.e. mxNumpyType->typeobj points to this),
>     inherits from
>     > PyDoubleArrType_Type and overrides some fields as mentioned above.
>     >
>     The nomenclature is that mxNumPyType is the data-type of the array and
>     your PyTypeObject is the "type" of the elements of the array.  
>     So, you
>     have the names a bit backward.
>
>     So, to correspond with the way I use the words "type" and
>     "data-type", I
>     would name them:
>
>     PyArray_Descr mxNumpyDataType
>     PyTypeObject mxNumpyType
>
>
> Okay, I will use this convention going forwards.
>
>     > And the getitem and setitem functions are designed to only
>     give/take
>     > PyObject* of type mxDateTime.
>     >
>     These are in the 'f' member of the PyArray_Descr structure, so
>     presumably you have also filled in your PyArray_Descr structure with
>     items from PyArray_DOUBLE?
>
>
> That's correct. I have all members of the 'f' member identical to that 
> from PyArray_DOUBLE, except:
>
>     mxNumpyType->f->dotfunc = NULL;
>     mxNumpyType->f->getitem = date_getitem;
>     mxNumpyType->f->setitem = date_setitem;
>     mxNumpyType->f->cast[PyArray_DOUBLE] = (PyArray_VectorUnaryFunc*) 
> dateToDouble;
>     mxNumpyType->f->cast[PyArray_OBJECT] = (PyArray_VectorUnaryFunc*) 
> dateToObject;
>
> All other cast functions are NULL.
>
> If I redefine the string function, I encounter another, perhaps more 
> serious problem leading to a segfault. I've defined my string function 
> to be extremely simple:
> >>> def printer(arr):
> ...   return str(arr[0])
>
> Now, if I try to print an element of the array:
> >>> mxArr[0]
>
> I get to this stack trace:
> #0  scalar_value (scalar=0x814be10, descr=0x5079e0) at 
> scalartypes.inc.src:68
> #1  0x0079936a in PyArray_Scalar (data=0x814cf98, descr=0x5079e0, 
> base=0x814e7a8) at arrayobject.c:1419
> #2  0x007d259f in array_subscript_nice (self=0x814e7a8, op=0x804eb8c) 
> at arrayobject.c:1985
> #3  0x00d17dde in PyObject_GetItem (o=0x814e7a8, key=0x804eb8c) at 
> Objects/abstract.c:94
>
> (Note: for some reason gdb claims that arrayobject.c:1985 is 
> array_subscript_nice, but looking at my source this line is actually 
> in array_item_nice. *boggle*)
>
> But scalar_value returns NULL for all non-native types. So, destptr in 
> PyArray_Scalar is set to NULL, and the call the copyswap segfaults.
>
> Perhaps scalar_value should be checking the scalarkind field of 
> PyArray_Descr, or using the elsize and alignment fields to figure out 
> the pointer to return if scalarkind isn't set?

Hmmm... It looks like the modifications to scalar_value did not take 
into account user-defined types.  I've added a correction so that 
user-defined types will use setitem to set the scalar value into the 
array.  Presumably your setitem function can handle setting the array 
with scalars of your new type?

I've checked the changes into SVN.


-Travis

Re: [Numpy-discussion] Python Enhancement Proposal (PEP) - Current status?

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

Colin J. Williams wrote:
> A July posting sets out the intent:
> http://scipy.org/BaseArray
> Version 3 of the draft:
> http://numpy.scipy.org/array_interface.shtml
> There is a description, from a C Structure perspective:
> http://svn.scipy.org/svn/PEP/PEP_basearray.txt
>
> What is the current status of the plan to develop a PEP?
>
> Is there a more recent version of the PEP, from a Python user's perspective?
>
>   
I'm working on two PEP's after discussing this with Guido at SciPy 2006. 

1) A data-type object PEP
2) An extension of the buffer protocol to include the array interface.

These are being done instead of the basearray PEP for now.  I'm hoping 
to have a draft of these ready for discussion in a few weeks.


-Travis