Re: [Numpy-discussion] first impressions with numpy
![](https://secure.gravatar.com/avatar/55f7acf47233a7a98f5eb9dfd0b2d763.jpg?s=120&d=mm&r=g)
Sebastian Haase wrote:
No. Just clumsy fingers. Probably the same reason the functions got all garbled!
Well, I think it's probably a good idea and it sounds like Travis like the idea " for some of the builtin types". I suspect that's code for "not types for which it doesn't make sense, like recarrays".
I agree that str should display something nicer. Repr should probably stay the same though.
Thanks for your great work ..
Oh, I'm not doing much in the way of great work. I'm mostly just causing Travis headaches. -tim
![](https://secure.gravatar.com/avatar/55f7acf47233a7a98f5eb9dfd0b2d763.jpg?s=120&d=mm&r=g)
Colin J. Williams wrote:
This isn't really about parameter lists and docstrings, it's about __str__ and possibly __repr__. The basic issue is that the way dtypes are displayed is powerful, but unfriendly. If I create an array of integers: >>> a = arange(4) >>> print repr(a.dtype), str(a.dtype) dtype('<i4') '<i4' This result is sort of cryptic. It would probably be reasonable to have this print dtype(int32), int32 instead. This is much less cryptic and dtype(int32) works fine, so it's an acceptable substitute for repr. On the other hand, some things don't map neatly onto the builtin types. Data that's not in the native byte order would be one case. For example, dtype('>i4') is not the same as dtype(int32) on my machine and should probably not be displayed using int32[1]. These cases should be rare in practice and it seems fine to fall back to the less friendly but more flexible notation. Recarrays were probably not such a good example. Here is an example from a recarray: dtype([('x', '<f8'), ('z', '<c16')]) This would work fine if repr were instead: dtype([('x', float64), ('z', complex128)]) Anyway, this all seems reasonable to me at first glance. That said, I don't plan to work on this, I've got other fish to fry at the moment. Regards, -tim [1] There does seem to be something squirley going on here though: dtype('>i4').name is 'int32' which seems wrong.
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Tim Hochberg wrote: <snip>
A new point: Please remind me (and probably others): when did it get decided to introduce 'complex128' to mean numarray's complex64 and the 'complex64' to mean numarray's complex32 ? I do understand the logic that 128 is really the bit-size of one (complex) element - but I also liked the old way, because: 1. e.g. in fft transforms, float32 would "go with" complex32 and float64 with complex64 2. complex128 is one character extra (longer) and also (alphabetically) now sorts before(!) complex64 These might just be my personal (idiotic ;-) comments - but I would appreciate some feedback/comments. Also: Is it now to late to (re-)start a discussion on this !? Thanks - Sebastian Haase
![](https://secure.gravatar.com/avatar/4d021a1d1319f36ad861ebef0eb5ba44.jpg?s=120&d=mm&r=g)
Sebastian Haase wrote:
It was last February (i.e. 2005) when I first started posting regarding the new NumPy. I claimed it was more consistent to use actual bit-widths. A few people, including Perry, indicated they weren't opposed to the change and so I went ahead with it. You can read relevant posts by searching on numpy-discussion@lists.sourceforge.net Discussions are always welcome. I suppose it's not too late to change something like this --- but it's getting there... -Travis
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Hi, Could we start another poll on this !? I think I would vote +1 for complex32 & complex64 mostly just because of "that's what I'm used to" But I'm curious to hear what others "know to be in use" - e.g. Matlab or IDL ! - Thanks Sebastian Haase Travis Oliphant wrote:
![](https://secure.gravatar.com/avatar/764323a14e554c97ab74177e0bce51d4.jpg?s=120&d=mm&r=g)
Sebastian Haase wrote:
Hi, Could we start another poll on this !?
Please, let's leave voting as a method of last resort.
On the merits of the issue, I like the new scheme better. For whatever reason, I tend to remember it when coding. With Numeric, I would frequently second-guess myself and go to the prompt and tab-complete to look at all of the options and reason out the one I wanted. -- Robert Kern robert.kern@gmail.com "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
![](https://secure.gravatar.com/avatar/55f7acf47233a7a98f5eb9dfd0b2d763.jpg?s=120&d=mm&r=g)
Robert Kern wrote:
I can't bring myself to care. I almost always use dtype=complex and on the rare times I don't I can never remember what the scheme is regardless of which scheme it is / was / will be. On the other hand, if the scheme was Complex32x2 and Complex64x2, I could probably decipher what that was without looking it up. It is is a little ugly and weird I admit, but that probably wouldn't bother me. Regards, -tim
![](https://secure.gravatar.com/avatar/beebe07772844149dcd47e23e5276e72.jpg?s=120&d=mm&r=g)
On Tue, 4 Apr 2006, Robert Kern wrote:
In order to get an opionion on the subject: How would one presently find out about the meaning of complex64 and complex128? The following attempt does not help: In [1]:import numpy In [2]:numpy.complex64? Type: type Base Class: <type 'type'> String Form: <type 'complex64scalar'> Namespace: Interactive Docstring: <no docstring> In [3]:numpy.complex128? Type: type Base Class: <type 'type'> String Form: <type 'complex128scalar'> Namespace: Interactive Docstring: <no docstring> I also looked in Travis' "Guide to NumPy", where the different types are discussed on page 18 (referring to the sample chapters at http://www.tramy.us/guidetoscipy.html) Maybe chapter 12 contains more info on this ((our library was still not able to buy the 20 copies since this request was approved a month ago ...)) Best, Arnd
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
A Dimarts 04 Abril 2006 07:40, Robert Kern va escriure:
I agree with Robert. From the very beginning NumPy design has been very consequent with typeEXTENT_IN_BITS mapping (even for unicode), and if we go back to numarray (complex32/complex64) convention, this would be the only exception to this rule. Perhaps I'm a bit biased by being a developer more interested in type 'sizes' that in 'precision' issues, but I'd definitely prefer a completely consistent approach for this matter. So +1 for complex64 & complex128 Cheers, --
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
I can't get worked up over this one way or the other: complex128 make sense if I count bits, complex64 makes sense if I note precision; I just have to remember the numpy convention. One could argue that complex64 is the more conventional choice and so has the virtue of least surprise, but I don't think it is terribly difficult to become accustomed to using complex128 in its place. I suppose this is one of those programmer's vs user's point of view thingees. For the guy writing general low level numpy code what matters is the length of the type, how many bytes have to be moved and so on, and from the other point of view what counts is the precision of the arithmetic. Chuck On 4/4/06, Colin J. Williams <cjw@sympatico.ca> wrote:
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
On Tuesday 04 April 2006 08:09, Charles R Harris wrote:
I kind of like your comparison of programmer vs user ;-) And so I was "hoping" that numpy (and scipy !!) is intended for the users - like supposedly IDL and Matlab are... No one likes my "backwards compatibility" argument !? Thanks - Sebastian Haase PS: I understand that voting is only for a last resort - some people, always use na.Complex and na.Float and don't care - BUT I use single precision all the time because my image data is already getting to large. So I have to look at this every day, and as Travis pointed out, now is about the last chance to possibly change complex128 to complex64 ...
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Tim Hochberg wrote: <snip>
A new point: Please remind me (and probably others): when did it get decided to introduce 'complex128' to mean numarray's complex64 and the 'complex64' to mean numarray's complex32 ? I do understand the logic that 128 is really the bit-size of one (complex) element - but I also liked the old way, because: 1. e.g. in fft transforms, float32 would "go with" complex32 and float64 with complex64 2. complex128 is one character extra (longer) and also (alphabetically) now sorts before(!) complex64 3 Mostly of course: this new naming will confuse all my code and introduce hard to find bugs - when I see complex64 I will "think" the old way for quite some time ... These might just be my personal (idiotic ;-) comments - but I would appreciate some feedback/comments. Also: Is it now to late to (re-)start a discussion on this !? Thanks - Sebastian Haase
![](https://secure.gravatar.com/avatar/55f7acf47233a7a98f5eb9dfd0b2d763.jpg?s=120&d=mm&r=g)
Colin J. Williams wrote:
This isn't really about parameter lists and docstrings, it's about __str__ and possibly __repr__. The basic issue is that the way dtypes are displayed is powerful, but unfriendly. If I create an array of integers: >>> a = arange(4) >>> print repr(a.dtype), str(a.dtype) dtype('<i4') '<i4' This result is sort of cryptic. It would probably be reasonable to have this print dtype(int32), int32 instead. This is much less cryptic and dtype(int32) works fine, so it's an acceptable substitute for repr. On the other hand, some things don't map neatly onto the builtin types. Data that's not in the native byte order would be one case. For example, dtype('>i4') is not the same as dtype(int32) on my machine and should probably not be displayed using int32[1]. These cases should be rare in practice and it seems fine to fall back to the less friendly but more flexible notation. Recarrays were probably not such a good example. Here is an example from a recarray: dtype([('x', '<f8'), ('z', '<c16')]) This would work fine if repr were instead: dtype([('x', float64), ('z', complex128)]) Anyway, this all seems reasonable to me at first glance. That said, I don't plan to work on this, I've got other fish to fry at the moment. Regards, -tim [1] There does seem to be something squirley going on here though: dtype('>i4').name is 'int32' which seems wrong.
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Tim Hochberg wrote: <snip>
A new point: Please remind me (and probably others): when did it get decided to introduce 'complex128' to mean numarray's complex64 and the 'complex64' to mean numarray's complex32 ? I do understand the logic that 128 is really the bit-size of one (complex) element - but I also liked the old way, because: 1. e.g. in fft transforms, float32 would "go with" complex32 and float64 with complex64 2. complex128 is one character extra (longer) and also (alphabetically) now sorts before(!) complex64 These might just be my personal (idiotic ;-) comments - but I would appreciate some feedback/comments. Also: Is it now to late to (re-)start a discussion on this !? Thanks - Sebastian Haase
![](https://secure.gravatar.com/avatar/4d021a1d1319f36ad861ebef0eb5ba44.jpg?s=120&d=mm&r=g)
Sebastian Haase wrote:
It was last February (i.e. 2005) when I first started posting regarding the new NumPy. I claimed it was more consistent to use actual bit-widths. A few people, including Perry, indicated they weren't opposed to the change and so I went ahead with it. You can read relevant posts by searching on numpy-discussion@lists.sourceforge.net Discussions are always welcome. I suppose it's not too late to change something like this --- but it's getting there... -Travis
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Hi, Could we start another poll on this !? I think I would vote +1 for complex32 & complex64 mostly just because of "that's what I'm used to" But I'm curious to hear what others "know to be in use" - e.g. Matlab or IDL ! - Thanks Sebastian Haase Travis Oliphant wrote:
![](https://secure.gravatar.com/avatar/764323a14e554c97ab74177e0bce51d4.jpg?s=120&d=mm&r=g)
Sebastian Haase wrote:
Hi, Could we start another poll on this !?
Please, let's leave voting as a method of last resort.
On the merits of the issue, I like the new scheme better. For whatever reason, I tend to remember it when coding. With Numeric, I would frequently second-guess myself and go to the prompt and tab-complete to look at all of the options and reason out the one I wanted. -- Robert Kern robert.kern@gmail.com "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
![](https://secure.gravatar.com/avatar/55f7acf47233a7a98f5eb9dfd0b2d763.jpg?s=120&d=mm&r=g)
Robert Kern wrote:
I can't bring myself to care. I almost always use dtype=complex and on the rare times I don't I can never remember what the scheme is regardless of which scheme it is / was / will be. On the other hand, if the scheme was Complex32x2 and Complex64x2, I could probably decipher what that was without looking it up. It is is a little ugly and weird I admit, but that probably wouldn't bother me. Regards, -tim
![](https://secure.gravatar.com/avatar/beebe07772844149dcd47e23e5276e72.jpg?s=120&d=mm&r=g)
On Tue, 4 Apr 2006, Robert Kern wrote:
In order to get an opionion on the subject: How would one presently find out about the meaning of complex64 and complex128? The following attempt does not help: In [1]:import numpy In [2]:numpy.complex64? Type: type Base Class: <type 'type'> String Form: <type 'complex64scalar'> Namespace: Interactive Docstring: <no docstring> In [3]:numpy.complex128? Type: type Base Class: <type 'type'> String Form: <type 'complex128scalar'> Namespace: Interactive Docstring: <no docstring> I also looked in Travis' "Guide to NumPy", where the different types are discussed on page 18 (referring to the sample chapters at http://www.tramy.us/guidetoscipy.html) Maybe chapter 12 contains more info on this ((our library was still not able to buy the 20 copies since this request was approved a month ago ...)) Best, Arnd
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
A Dimarts 04 Abril 2006 07:40, Robert Kern va escriure:
I agree with Robert. From the very beginning NumPy design has been very consequent with typeEXTENT_IN_BITS mapping (even for unicode), and if we go back to numarray (complex32/complex64) convention, this would be the only exception to this rule. Perhaps I'm a bit biased by being a developer more interested in type 'sizes' that in 'precision' issues, but I'd definitely prefer a completely consistent approach for this matter. So +1 for complex64 & complex128 Cheers, --
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
I can't get worked up over this one way or the other: complex128 make sense if I count bits, complex64 makes sense if I note precision; I just have to remember the numpy convention. One could argue that complex64 is the more conventional choice and so has the virtue of least surprise, but I don't think it is terribly difficult to become accustomed to using complex128 in its place. I suppose this is one of those programmer's vs user's point of view thingees. For the guy writing general low level numpy code what matters is the length of the type, how many bytes have to be moved and so on, and from the other point of view what counts is the precision of the arithmetic. Chuck On 4/4/06, Colin J. Williams <cjw@sympatico.ca> wrote:
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
On Tuesday 04 April 2006 08:09, Charles R Harris wrote:
I kind of like your comparison of programmer vs user ;-) And so I was "hoping" that numpy (and scipy !!) is intended for the users - like supposedly IDL and Matlab are... No one likes my "backwards compatibility" argument !? Thanks - Sebastian Haase PS: I understand that voting is only for a last resort - some people, always use na.Complex and na.Float and don't care - BUT I use single precision all the time because my image data is already getting to large. So I have to look at this every day, and as Travis pointed out, now is about the last chance to possibly change complex128 to complex64 ...
![](https://secure.gravatar.com/avatar/6194b135cba546afa82516de1537de49.jpg?s=120&d=mm&r=g)
Tim Hochberg wrote: <snip>
A new point: Please remind me (and probably others): when did it get decided to introduce 'complex128' to mean numarray's complex64 and the 'complex64' to mean numarray's complex32 ? I do understand the logic that 128 is really the bit-size of one (complex) element - but I also liked the old way, because: 1. e.g. in fft transforms, float32 would "go with" complex32 and float64 with complex64 2. complex128 is one character extra (longer) and also (alphabetically) now sorts before(!) complex64 3 Mostly of course: this new naming will confuse all my code and introduce hard to find bugs - when I see complex64 I will "think" the old way for quite some time ... These might just be my personal (idiotic ;-) comments - but I would appreciate some feedback/comments. Also: Is it now to late to (re-)start a discussion on this !? Thanks - Sebastian Haase
participants (9)
-
Arnd Baecker
-
Charles R Harris
-
Colin J. Williams
-
Francesc Altet
-
Robert Kern
-
Sebastian Haase
-
Tim Hochberg
-
Travis Oliphant
-
Zachary Pincus