Re: [Numpy-discussion] matlab vs. python question

Thank you so much! When I finally get a moment to take a break, I'll look in more detail into using your suggestion. --b On Apr 26, 2007, at 12:47 AM, Pauli Virtanen wrote: > belinda thom kirjoitti: >> On Apr 25, 2007, at 12:46 PM, Bill Baxter wrote: >> >> Agree w/most of what you've said, bu

Re: [Numpy-discussion] numpy endian question

> I really want to know if the array is in big-endian order (I don't care > whether it's native). This is for sending arrays to the ds9 image viewer > via xpa (and communicating with ds9 is not easy). To do this reliably I > need to indicate the byte order of the data. > Thanks for the clar

Re: [Numpy-discussion] numpy endian question

Russell, This should work as a consistent test for bigendian: -> isBigEndian = (obj.dtype.str[0] == '>') Also, I have ported numarray's numdisplay to numpy if you would like to directly display an array in DS9. We haven't done an official release yet (sometime soon) but I can forward you a co

Re: [Numpy-discussion] numpy endian question

In article <[EMAIL PROTECTED]>, Travis Oliphant <[EMAIL PROTECTED]> wrote: > Russell E. Owen asked how best to translate some numarray code that > determines if an array is in big-endian order... > > What are you trying to test for (where a data-type is big-endian or not?). I really want to kno

Re: [Numpy-discussion] sort bug

Just doing argsort() on the whole array is faster (up until about 1e6 elements) because it does everything in C whereas heapq will create a lot of Python objects because it is treating the array as a general Python container. That's a good point. I wasn't thinking about the efficiency issue. _

Re: [Numpy-discussion] sort bug

tan2 wrote: > > On 4/26/07, * Anton Sherwood* <[EMAIL PROTECTED] > > wrote: > > All I really need is the four highest eigenvalues and their > vectors. > I'll have a look in "Python Cookbook" to see if there's a more > efficient way

Re: [Numpy-discussion] numpy endian question

Russell E. Owen wrote: > In converting some code from numarray to numpy I had this: > isBigendian = (arr.isbyteswapped() != numarray.isBigEndian) > > The only numpy version I've come up with is: > isBigEndian = (arr.dtype.descr[0][1][0] == '>') > > which is short but very obscure. Has anyone got a

Re: [Numpy-discussion] sort bug

On 4/26/07, Anton Sherwood <[EMAIL PROTECTED]> wrote: > > > All I really need is the four highest eigenvalues and their vectors. > I'll have a look in "Python Cookbook" to see if there's a more > efficient way to do that partial sort. Maybe "heapq.nlargest()" is what you want? http://www.pyt

Re: [Numpy-discussion] sort bug

On 26/04/07, Anton Sherwood <[EMAIL PROTECTED]> wrote: > All I really need is the four highest eigenvalues and their vectors. It's not really very efficient, but sorting time is going to be tiny compared to however you get your eigenvalues, so you could argsort the eigenvalue array and use the re

Re: [Numpy-discussion] sort bug

On 4/26/07, Anton Sherwood <[EMAIL PROTECTED]> wrote: Travis Oliphant wrote: > cmp(x,y) must return -1, 0, or 1 which doesn't work on arrays with more > than 1 element because it is ambiguous. Thus you get this error. Ah. Since lists *can* be compared, I assumed arrays would inherit that prop

Re: [Numpy-discussion] Questions about converting to numpy

Russell E. Owen wrote: > But I still don't understand why one shouldn't just use dtype=float or > numpy.float. Does that result in an array with a different type of float > than numpy.float_ (float64)? Or does it just somehow speed up numpy > because it doesn't have to convert the python type i

Re: [Numpy-discussion] sort bug

Anton Sherwood wrote: > Travis Oliphant wrote: > >> cmp(x,y) must return -1, 0, or 1 which doesn't work on arrays with more >> than 1 element because it is ambiguous. Thus you get this error. >> > > Ah. Since lists *can* be compared, I assumed arrays would inherit > that property. > >

Re: [Numpy-discussion] numpy endian question

El dj 26 de 04 del 2007 a les 11:38 -0700, en/na Russell E. Owen va escriure: > In converting some code from numarray to numpy I had this: > isBigendian = (arr.isbyteswapped() != numarray.isBigEndian) > > The only numpy version I've come up with is: > isBigEndian = (arr.dtype.descr[0][1][0] == '>'

Re: [Numpy-discussion] Questions about converting to numpy

In article <[EMAIL PROTECTED]>, Robert Kern <[EMAIL PROTECTED]> wrote: > Christopher Barker wrote: > > > I can only help with one: > >> - Even after reading the book I'm not really clear on why one would use > >> numpy.float_ instead of numpy.float or float > > > > They float and numpy.float a

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

Guido van Rossum wrote: > Jeffrey, is there any way you can drop the top of the tree and going > straight from Number to Complex -> Real -> Rational -> Integer? These > are the things that everyone with high school math will know. > Having taught mathematics at a community college for a little w

[Numpy-discussion] numpy endian question

In converting some code from numarray to numpy I had this: isBigendian = (arr.isbyteswapped() != numarray.isBigEndian) The only numpy version I've come up with is: isBigEndian = (arr.dtype.descr[0][1][0] == '>') which is short but very obscure. Has anyone got a suggestion for a clearer test? I f

Re: [Numpy-discussion] sort bug

Travis Oliphant wrote: > cmp(x,y) must return -1, 0, or 1 which doesn't work on arrays with more > than 1 element because it is ambiguous. Thus you get this error. Ah. Since lists *can* be compared, I assumed arrays would inherit that property. > The operation is undefined. What do you actuall

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On Thu, 26 Apr 2007 10:11:27 PDT, Bill Janssen <[EMAIL PROTECTED]> wrote: >> Are the base number operations in Python all that difficult to >> understand? > >Well, they're a little tricky. > >But the basic problem with "number" support, in almost every >programming language, is that they are too lo

Re: [Numpy-discussion] [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Wed, 25 Apr 2007 20:40:14 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> > wrote: > >At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote: > >>On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett <[EMAIL PROTECTED]> > >>wrote: > >> >The curr

Re: [Numpy-discussion] [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote: >On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett <[EMAIL PROTECTED]> wrote: > >The current ABC proposal is to use isinstance as the test; Jeffrey > >Yaskin's numbers PEP highlighted the weakness there with a concrete > >example. > > > >If you n

Re: [Numpy-discussion] [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

At 06:10 PM 4/25/2007 -0400, Jim Jewett wrote: >I suspect Phillip will say that we really need to make the ABCs >generic functions... Nope; they're *already* generic functions: hash(), len(), iter(), various operator.* functions, and I believe we're adding next(). I've got nothing to add to tha

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Jeffrey, is there any way you can drop the top of the tree and going > > straight from Number to Complex -> Real -> Rational -> Integer? These > > are the things that everyone with h

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Jeffrey, is there any way you can drop the top of the tree and going > straight from Number to Complex -> Real -> Rational -> Integer? These > are the things that everyone with high school math will know. I think yes, if you can confirm tha

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Collin Winter <[EMAIL PROTECTED]> wrote: > The following things mean absolutely nothing to me: > > - Monoid > - MonoidUnderPlus > - Group > - Ring > - Semiring > - Field > > So, most of the terminology in the PEP. > > I can see use-cases for this level of formalism, but I'm a strong -1

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

[bcc'ing numpy-discussion. Comments should probably try to stay on the python-3000 list.] On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Are the base number operations in Python all that difficult to > understand? Do we really need to add mathematical formalism into > Python's type syste

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

The following things mean absolutely nothing to me: - Monoid - MonoidUnderPlus - Group - Ring - Semiring - Field So, most of the terminology in the PEP. I can see use-cases for this level of formalism, but I'm a strong -1 on making any part of the stdlib effectively off-limits for people without

Re: [Numpy-discussion] matlab vs. python question

belinda thom kirjoitti: > On Apr 25, 2007, at 12:46 PM, Bill Baxter wrote: > > Agree w/most of what you've said, but will add one other thing that > drives me nuts in python that hasn't been a problem in Matplotlib: > > In Python, if interacting w/the interpreter as your primary IDE, and > if

Re: [Numpy-discussion] [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On Wed, 25 Apr 2007 20:40:14 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote: >>On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett <[EMAIL PROTECTED]> >>wrote: >> >The current ABC proposal is to use isinstance as the test; Jeffrey >> >Yaskin's

Re: [Numpy-discussion] [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett <[EMAIL PROTECTED]> wrote: >The current ABC proposal is to use isinstance as the test; Jeffrey >Yaskin's numbers PEP highlighted the weakness there with a concrete >example. > >If you need to an abstraction less powerful than an existing ABC, >you're o

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > class MonoidUnderPlus(Abstract): Is this useful? Just because two things are both Monoid instances doesn't mean I can add them -- they have to be part of the same Monoid. By the time you do assert isinstance(a, MonoidUnderPlus)

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

[bcc'ing numpy-discussion. Comments should probably try to stay on the python-3000 list.] On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Are the base number operations in Python all that difficult to > understand? Do we really need to add mathematical formalism into > Python's type syste

Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

"Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote: > Here's a draft of the numbers ABCs PEP. The most up to date version > will live in the darcs repository at > http://jeffrey.yasskin.info/darcs/PEPs/pep-3141.txt (unless the number > changes) for now. Naming a PEP about numbers 3.141 seems cute, but of

[Numpy-discussion] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

Here's a draft of the numbers ABCs PEP. The most up to date version will live in the darcs repository at http://jeffrey.yasskin.info/darcs/PEPs/pep-3141.txt (unless the number changes) for now. Naming a PEP about numbers 3.141 seems cute, but of course, I don't get to pick the number. :) This is my

Re: [Numpy-discussion] matlab vs. python question

Brian Blais wrote: > I agree with Sturla here, up until Pyrex. Looking at the Python API, swig, > f2py, > etc. I found mex files far more straightforward. Mostly this is because of > the > (mostly) single datatype in Matlab: the double matrix. well, that's not really fair. I've written extensi

Re: [Numpy-discussion] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

[sage list added] "Travis E. Oliphant" <[EMAIL PROTECTED]> writes: > The SAGE people may be interested in this, but I doubt there will more > than a handful of users of these algebraic base classes. SAGE has quite a sophisticated type hierarchy, and a sophisticated set of coercion methods. Wha

[Numpy-discussion] [ANN] PyTables 2.0rc1 released

Hi all, The development of the second major release of PyTables is steadily approaching its goal! Today we want to announce the *first release candidate version of PyTables 2.0*, i.e. PyTables 2.0rc1. This version settles the API and file format for the following PyTables 2.0 series. No more fea

Re: [Numpy-discussion] matlab vs. python question

On 4/26/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote: > Anyway, IANAL, and I am not to sure if releasing a preprint on a mailing > list renders the article ineligible for CiSE or not but I just put a > version on > http://gael-varoquaux.info/computers/agile_computer_control_of_an_experiment.pdf Y

Re: [Numpy-discussion] matlab vs. python question

On Thu, Apr 26, 2007 at 12:06:56PM +0200, Zdeněk Hurák wrote: > But what makes Matlab difficult to be replaced is that lots of other > projects (commercial: Mathematica, Maple, ... and free: octave, maxima, > scipy, ...) only offer computation and visualization, while engineers in my > field also n

Re: [Numpy-discussion] matlab vs. python question

On 4/26/2007 2:42 PM, David Cournapeau wrote: > You are true for the semantics, but wrong for the consequences on copying, as matlab is using COW, and this works well in matlab. It works well only if you don't change your input arguments. Never try to write to a matrix received as an argument

Re: [Numpy-discussion] matlab vs. python question

On 4/26/2007 2:47 PM, Neal Becker wrote: > That's interesting. How did you find this information? What information? Matlab's pass-by-value semantics is well known to anyone who has ever used Matlab. The Mathwork's employees have numerous times stated that Matlab uses copy-on-write to optimiz

Re: [Numpy-discussion] matlab vs. python question

Sturla Molden wrote: > On 4/26/2007 2:19 PM, Steve Lianoglou wrote: > >>> Beside proper programing paradigm Python easily scales to large- >>> scale number crunching: You can run large-matrices calculations >>> with about 1/2 to 1/4 of memory consumption comparing to Matlab. >> >> Is that really

Re: [Numpy-discussion] matlab vs. python question

Sturla Molden wrote: > On 4/26/2007 2:19 PM, Steve Lianoglou wrote: > >>> Beside proper programing paradigm Python easily scales to large- >>> scale number crunching: You can run large-matrices calculations >>> with about 1/2 to 1/4 of memory consumption comparing to Matlab. >> Is that really tr

Re: [Numpy-discussion] matlab vs. python question

Steve Lianoglou wrote: >> Beside proper programing paradigm Python easily scales to large- >> scale number crunching: You can run large-matrices calculations >> with about 1/2 to 1/4 of memory consumption comparing to Matlab. > > Is that really true? (The large-matrix number crunching, not the >

Re: [Numpy-discussion] matlab vs. python question

On 4/26/2007 2:19 PM, Steve Lianoglou wrote: >> Beside proper programing paradigm Python easily scales to large- >> scale number crunching: You can run large-matrices calculations >> with about 1/2 to 1/4 of memory consumption comparing to Matlab. > > Is that really true? (The large-matrix num

Re: [Numpy-discussion] matlab vs. python question

> Beside proper programing paradigm Python easily scales to large- > scale number crunching: You can run large-matrices calculations > with about 1/2 to 1/4 of memory consumption comparing to Matlab. Is that really true? (The large-matrix number crunching, not the proper programming paradigm

Re: [Numpy-discussion] numexpr efficency depends on the size of the computing kernel

Just a quick followup about this issue: After a bit of investigation, I discovered that the responsible for the difference in performance between the original numexpr and their PyTables counterpart (see the message below) was due *only* to the different flags used for compiling (and not to a ca

Re: [Numpy-discussion] matlab vs. python question

Travis Oliphant wrote: [...] > I would love to see some good contributions in the area of Simulink-like > work. There are several things out there that are good starts. Even though I praised Simulink highly in the previous contribution, I don't think that it would be a good way to mimic it. That

Re: [Numpy-discussion] matlab vs. python question

Zdeněk Hurák wrote: > Coming from the field of control engineering, I don't think that at this > moment there is any replacement for their graphical interface to solvers > for nonlinear differential/difference equations called Simulink. This is correct. This is the one thing that Python needs imp

Re: [Numpy-discussion] matlab vs. python question

Matthew Brett wrote: [...] > I agree that matlab has many attractions as a teaching tool and for > small numeric processing scripts, but if you are writing a large to > medium-sized application, I really don't think there is any > comparison... [...] Matthew, there are also other (engineering) com

Re: [Numpy-discussion] matlab vs. python question

Nadav Horesh wrote: > Matlab added classes in a fairly recent version, ... Just wanted to correct this. Classes were introduced to Matlab something like ten years ago. I guess that it was in version 5. Zdenek ___ Numpy-discussion mailing list Numpy-di

Re: [Numpy-discussion] matlab vs. python question

Well - these threads always go on for a long time, but... I've used matlab heavily for 10 years. I found that I had to use perl and C fairly heavily to get things done that matlab could not do well. Now I've switched to numpy, scipy, matplotlib, there is really nothing I miss in matlab. We woul

Re: [Numpy-discussion] sort bug

Anton Sherwood wrote: > This code -- > > adj = [ [eval(y) for y in x.split()] for x in infile ] > val,vec = numpy.linalg.eig(adj) > master = zip( val, vec.transpose() ) > master.sort() > > *sometimes* gives this error: > > Traceback (most recent call last): > F