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):
File 3work.py, line 14, in
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
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)
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
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
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
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 number
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
proper
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 true? (The
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 true? (The
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
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 need
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
You're
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
[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. What is
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 extensions
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
[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 system
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 out of
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 numbers PEP
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
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
[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 system
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
on making
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 high school
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 low-level an
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 actually
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
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 are the same, and
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.
The
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 into
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
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?
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
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
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, but will
36 matches
Mail list logo
