On Fri, 21 Sep 2007, Stephen McInerney apparently wrote:
> The pure Pythonic solution is a list comprehension involving multiple
> sequences:
> x = range(0,n)
> y = x
> z = x
> t = [(xx,yy,zz) for xx in x for yy in y for zz in z]
Different question ...
Cheers,
Alan Isaac
__
Gael,
The pure Pythonic solution is a list comprehension involving multiple sequences:
x = range(0,n)
y = x
z = x
t = [(xx,yy,zz) for xx in x for yy in y for zz in z]
You don't need subscripting, or recursive fns, or Knuth.
Runtime is almost instant (for n=10).
All the NumPy solutions look more
In reply to your reply (which I inadvertently deleted :-[ ) to my reply:
Point well-made and taken. :-)
DG
Stuart Brorson wrote:
>> No. It is a matter of sorting first on the real part, and then resolving
>> duplicates by sorting on the imaginary part. The magnitude is not used:
>>
> [sni
On Fri, 21 Sep 2007, David Goldsmith wrote:
> Not to be snide, but I found this thread very "entertaining," as,
> precisely because there is no single, well-defined (partial) ordering of
> C, I regard it as poor coding practice to rely on whatever partial
> ordering the language you're using may (
On 9/21/07, Gary Ruben <[EMAIL PROTECTED]> wrote:
>
> Gael Varoquaux wrote:
> > On Fri, Sep 21, 2007 at 02:58:43PM -0600, Charles R Harris wrote:
> >>I found generators a good approach to this sort of thing:
> >
> >>for (i,j,k) in triplets(n) :
> >
> > That's what we where doing so far, bu
Apparently so.
Not to be snide, but I found this thread very "entertaining," as,
precisely because there is no single, well-defined (partial) ordering of
C, I regard it as poor coding practice to rely on whatever partial
ordering the language you're using may (IMO unwisely) provide: if you
wan
Gael Varoquaux wrote:
> On Fri, Sep 21, 2007 at 02:58:43PM -0600, Charles R Harris wrote:
>>I found generators a good approach to this sort of thing:
>
>>for (i,j,k) in triplets(n) :
>
> That's what we where doing so far, but in the code itself. The result was
> unbearably slow.
> I thin
> No. It is a matter of sorting first on the real part, and then resolving
> duplicates by sorting on the imaginary part. The magnitude is not used:
[snip]
Oh, OK. So the ordering algorithm for complex numbers is:
1. First sort on real part.
2. Then sort on imag part.
Right?
Stuart
On 9/21/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
>
> On Fri, Sep 21, 2007 at 02:58:43PM -0600, Charles R Harris wrote:
> >I found generators a good approach to this sort of thing:
>
> >for (i,j,k) in triplets(n) :
>
> That's what we where doing so far, but in the code itself. The resu
On Fri, Sep 21, 2007 at 08:27:51PM -0400, Stuart Brorson wrote:
>>>> a
>array([[ 1. +1.j , 1. +2.j ],
> [ 2. +1.j , 1.9+1.9j]])
>>>> numpy.max(a)
>(2+1j)
This is numpy. You are dealing with arrays, so its numpy.
>>>> a = 2+1j
>>>> b = 2+2j
>>>> a>b
>Tra
Stuart Brorson wrote:
> On Fri, 21 Sep 2007, Robert Kern wrote:
>> Stuart Brorson wrote:
> Is it NumPy's goal to be as compatible with Matlab as possible?
No.
>>> OK, so that's fair enough. But how about self-consistency?
>>> I was thinking about this issue as I was biking home this eveni
>> Is it NumPy's goal to be as compatible with Matlab as possible?
>
> No.
OK, so that's fair enough. But how about self-consistency?
I was thinking about this issue as I was biking home this evening.
To review my question:
>>> a
array([[ 1. +1.j , 1. +2.j ],
[ 2. +1.j , 1.9+1
Stuart Brorson wrote:
>>> Is it NumPy's goal to be as compatible with Matlab as possible?
>> No.
>
> OK, so that's fair enough. But how about self-consistency?
> I was thinking about this issue as I was biking home this evening.
>
> To review my question:
>
>>>> a
>array([[ 1. +1.j , 1
On Fri, 21 Sep 2007, Robert Kern wrote:
> Stuart Brorson wrote:
Is it NumPy's goal to be as compatible with Matlab as possible?
>>> No.
>>
>> OK, so that's fair enough. But how about self-consistency?
>> I was thinking about this issue as I was biking home this evening.
>>
>> To review my que
On Fri, Sep 21, 2007 at 02:58:43PM -0600, Charles R Harris wrote:
>I found generators a good approach to this sort of thing:
>for (i,j,k) in triplets(n) :
That's what we where doing so far, but in the code itself. The result was
unbearably slow.
I think for our purposes we should build a
Stuart Brorson wrote:
> Is it NumPy's goal to be as compatible with Matlab as possible?
No.
Whatever gave you that idea? That's what Octave is for.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Wa
On 9/21/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
>
> On Fri, Sep 21, 2007 at 02:33:42PM -0600, Charles R Harris wrote:
> >I wrote up some of the combinatorial algorithms in python a few years
> ago
> >for my own use in writing a paper, ( Harris, C. R. Solution of the
> >aliasing an
Stuart Brorson wrote:
> Thank you for your answer!
>
>>> As a NumPy newbie, I am still learning things about NumPy which I didn't
>>> expect. Today I learned that for a matrix of complex numbers,
>>> numpy.max() returns the element with the largest *real* part, not the
>>> element with the larges
Thank you for your answer!
>> As a NumPy newbie, I am still learning things about NumPy which I didn't
>> expect. Today I learned that for a matrix of complex numbers,
>> numpy.max() returns the element with the largest *real* part, not the
>> element with the largest *magnitude*.
>
> There isn't
On Fri, Sep 21, 2007 at 02:33:42PM -0600, Charles R Harris wrote:
>I wrote up some of the combinatorial algorithms in python a few years ago
>for my own use in writing a paper, ( Harris, C. R. Solution of the
>aliasing and least squares problems of spaced antenna interferometric
>me
On 9/21/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
>
> On Fri, Sep 21, 2007 at 01:52:31PM -0600, Charles R Harris wrote:
> >Go here, http://www.cs.utsa.edu/~wagner/knuth/. I think you want
> fascicle
> >4A, http://www.cs.utsa.edu/~wagner/knuth/fasc4a.pdf. Some of the
> fascicles
> >f
On 9/21/07, Alexander Schmolck <[EMAIL PROTECTED]> wrote:
>
> David Cournapeau <[EMAIL PROTECTED]> writes:
>
> > Alexander Schmolck wrote:
> >> "Charles R Harris" <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>> The automatic handling of pointers for the default allocation type is
> also
> >>> convenien
On 9/21/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
>
> On Fri, Sep 21, 2007 at 01:52:31PM -0600, Charles R Harris wrote:
> >Go here, http://www.cs.utsa.edu/~wagner/knuth/. I think you want
> fascicle
> >4A, http://www.cs.utsa.edu/~wagner/knuth/fasc4a.pdf. Some of the
> fascicles
> >f
On Fri, Sep 21, 2007 at 01:52:31PM -0600, Charles R Harris wrote:
>Go here, http://www.cs.utsa.edu/~wagner/knuth/. I think you want fascicle
>4A, http://www.cs.utsa.edu/~wagner/knuth/fasc4a.pdf. Some of the fascicles
>from Vol 4 of TAOCP are now in print, http://tinyurl.com/2goxpr.
:->
On 9/21/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
>
>
> On 9/21/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> >
> > Hi all,
> >
> > I want to generate all the possible triplets of integers in [0, n]. I am
> > wondering want the best possible way to do this is.
> >
> > To make things clear
On 9/21/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I want to generate all the possible triplets of integers in [0, n]. I am
> wondering want the best possible way to do this is.
>
> To make things clearer, I could generate i, j, k using indices:
>
> i, j, k = indices((n, n, n))
>
Travis E. Oliphant skrev:
> Jörgen Stenarson wrote:
>> Hi,
>>
>> I cannot compile numpy (rev 2042) for python2.4 on win32, it works on
>> python2.5. It looks like the call to function get_build_architecture in
>> distutils.misc_util.py is python2.5 specific.
>>
> Yes. This needs to be fixed.
Hi all,
I want to generate all the possible triplets of integers in [0, n]. I am
wondering want the best possible way to do this is.
To make things clearer, I could generate i, j, k using indices:
i, j, k = indices((n, n, n))
But I will have several times the same triplet with different ordenin
Stuart Brorson wrote:
> Hi guys,
>
> As a NumPy newbie, I am still learning things about NumPy which I didn't
> expect. Today I learned that for a matrix of complex numbers,
> numpy.max() returns the element with the largest *real* part, not the
> element with the largest *magnitude*.
There isn'
Hi guys,
As a NumPy newbie, I am still learning things about NumPy which I didn't
expect. Today I learned that for a matrix of complex numbers,
numpy.max() returns the element with the largest *real* part, not the
element with the largest *magnitude*.
Is this the desired behavior?
Here's an exa
If you take a look at the source of numpy's linalg.py, you'll see that
solves uses dgesv /zgesv for real /complex solves. If you Google dgesv, you
get:
DGESV computes the solution to a real system of linear equations
A * X = B,
where A is an N-by-N matrix and X and B are N-by-NRHS m
Hello, anybody know what approach is used in linalg.solve?
I used it in a paper and some reviewer wants to know.
Some Gaussian elimination with pivoting or something more fancy?
Thanks,
Mark
___
Numpy-discussion mailing list
Numpy-discussion@scipy.or
David Cournapeau <[EMAIL PROTECTED]> writes:
> Alexander Schmolck wrote:
>> "Charles R Harris" <[EMAIL PROTECTED]> writes:
>>
>>
>>> The automatic handling of pointers for the default allocation type is also
>>> convenient and makes it reasonable to have functions return matrices and
>>> vector
- Forwarded message from Jarrod Millman <[EMAIL PROTECTED]> -
From: Jarrod Millman <[EMAIL PROTECTED]>
To: SciPy Users List <[EMAIL PROTECTED]>
Subject: [SciPy-user] ANN: SciPy 0.6.0
Reply-To: SciPy Users List <[EMAIL PROTECTED]>
Date: Fri, 21 Sep 2007 02:04:32 -0700
Message-ID: <[EMAIL PR
34 matches
Mail list logo
