On 7/14/06, Bill Baxter <[EMAIL PROTECTED]> wrote:
> I believe that's the problem that the indexing PEP from Travis is
> supposed to address:
> http://www.python.org/dev/peps/pep-0357/
> So I think there's not much anyone can do about it untill the PEP is
> accepted and implemented.
>
> Maybe you
I believe that's the problem that the indexing PEP from Travis is
supposed to address:
http://www.python.org/dev/peps/pep-0357/
So I think there's not much anyone can do about it untill the PEP is
accepted and implemented.
Maybe you can cast to int?
> In [34]: (1,2)[int(a[0]==b)]
--bb
On 7/15
Is there much speed to be gained by compiling atlas for a dual core system?
I'm running Ubuntu on a Macbook. It's the first time I've had a dual
core system.
My one line benchmark shows that the Macbook is slow compared to my
(old) desktop.
>> t1=time.time();x=randn(500,1000);x =
x*x.T;a,b=linal
Hi all,
I just got bit by this problem, and I'm not really sure if this is
something that should be considered a numpy bug or not. It is a bit
unpleasant, at the least, though it can be easily worked around.
Here's a simple demonstration:
In [32]: a=array([1,2])
In [33]: b=1
In [34]: (1,2)[a[0
Keith Goodman wrote:
> I like seeing the bug reports on the list. It is an easy way to get
> alerts of what to look out for.
There are read-only mailing lists for new and updated tickets:
http://www.scipy.org/Mailing_Lists
--
Robert Kern
"I have come to believe that the whole world is an en
On 7/14/06, Bill Baxter <[EMAIL PROTECTED]> wrote:
> On 7/15/06, Robert Kern <[EMAIL PROTECTED]> wrote:
> > Nils Wagner wrote:
> >
> > > >>> p = linalg.pinv(a)
> > > Traceback (most recent call last):
> > > File "", line 1, in ?
> > > File "/usr/lib64/python2.4/site-packages/numpy/linalg/linal
Victoria G. Laidler schrieb:
>
> I understand that for interactive use, short names are more convenient;
> but shouldn't they be available aliases to the more general names? Since
> numpy is primarily a software library, I wouldn't expect it to sacrifice
> a standard best-practice in order to
On Fri, 14 Jul 2006 12:29:39 -0500
Robert Kern <[EMAIL PROTECTED]> wrote:
> Nils Wagner wrote:
>
> > >>> p = linalg.pinv(a)
> > Traceback (most recent call last):
> > File "", line 1, in ?
> > File "/usr/lib64/python2.4/site-packages/numpy/linalg/linalg.py", line
> > 426, in pinv
> > if
Bill Baxter wrote:
> On 7/15/06, Robert Kern <[EMAIL PROTECTED]> wrote:
>> Nils Wagner wrote:
>>
>>> >>> p = linalg.pinv(a)
>>> Traceback (most recent call last):
>>> File "", line 1, in ?
>>> File "/usr/lib64/python2.4/site-packages/numpy/linalg/linalg.py", line
>>> 426, in pinv
>>> if is
On 7/15/06, Robert Kern <[EMAIL PROTECTED]> wrote:
> Nils Wagner wrote:
>
> > >>> p = linalg.pinv(a)
> > Traceback (most recent call last):
> > File "", line 1, in ?
> > File "/usr/lib64/python2.4/site-packages/numpy/linalg/linalg.py", line
> > 426, in pinv
> > if issubclass(a.dtype.dtype,
On Jul 14, 2006, at 12:56 PM, Tim Hochberg wrote:
> I think I'd try psyco (http://psyco.sourceforge.net/). That's
> pretty painless to try and may result in a significant improvement.
I've been doing more and more development on my PPC Mac, where psyco
is not an option. If the speed issue
Nils Wagner wrote:
> >>> p = linalg.pinv(a)
> Traceback (most recent call last):
> File "", line 1, in ?
> File "/usr/lib64/python2.4/site-packages/numpy/linalg/linalg.py", line
> 426, in pinv
> if issubclass(a.dtype.dtype, complexfloating):
> AttributeError: 'numpy.dtype' object has no
Greetings,
The SciPy 2006 Conference (http://www.scipy.org/SciPy2006) is August
17-18 this year. The deadline for early registration is *today*, July
14, 2006. The registration price will increase from $100 to $150 after
today. You can register online at https://www.enthought.com/scipy06 .
Nick Fotopoulos wrote:
> On Jul 13, 2006, at 10:17 PM, Tim Hochberg wrote:
>
>
>> Nick Fotopoulos wrote:
>>
>>> Dear all,
>>>
>>> I often make use of numpy.vectorize to make programs read more
>>> like the physics equations I write on paper. numpy.vectorize is
>>> basically a wrapper
On Jul 13, 2006, at 10:17 PM, Tim Hochberg wrote:
> Nick Fotopoulos wrote:
>> Dear all,
>>
>> I often make use of numpy.vectorize to make programs read more
>> like the physics equations I write on paper. numpy.vectorize is
>> basically a wrapper for numpy.frompyfunc. Reading Travis's Scip
David Cournapeau wrote:
> Andrew Jaffe wrote:
>> Hi All,
>>
>> I have just switched from RHEL to debian, and all of a sudden I started
>> getting floating point exception errors in various contexts.
>>
>> Apparently, this has to do with some faulty error stuff in glibc,
>> specifically related to
Alan G Isaac wrote:
On Fri, 14 Jul 2006, Sven Schreiber apparently wrote:
So maybe that's a feature request, complementing the
nansum function by a nanaverage?
This is not an objection; just an observation.
It has always seemed to me that such descriptive
statistics make more sense as class
GNU libc version 2.3.2 has a bug[1] "feclearexcept() error on CPUs with
SSE" (fixed in 2.3.3) which has been submitted to Debian[2] but not
fixed in sarge.
See http://www.its.caltech.edu/~astraw/coding.html#id3 for more
information and .debs which fix the problem.
[1] http://sources.redhat.com/bu
Jonathan Taylor wrote:
> pseudoinverse
>
> it's the same name matlab uses:
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/pinv.html
Thanks for the explanation.
I'm puzzled by the naming choice, however. Standard best practice in
writing software is to give understandable names, t
pseudoinverse
it's the same name matlab uses:
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/pinv.html
Victoria G. Laidler wrote:
>Sven Schreiber wrote:
>
>
>
>>Jon Peirce schrieb:
>>
>>
>>
>>
>>>There used to be a function generalized_inverse in the numpy.linalg
>>>module (c
Sven Schreiber wrote:
>Jon Peirce schrieb:
>
>
>>There used to be a function generalized_inverse in the numpy.linalg
>>module (certainly in 0.9.2).
>>
>>In numpy0.9.8 it seems to have been moved to the numpy.linalg.old
>>subpackage. Does that mean it's being dropped? Did it have to move? Now
On Fri, 14 Jul 2006, Sven Schreiber apparently wrote:
> So maybe that's a feature request, complementing the
> nansum function by a nanaverage?
This is not an objection; just an observation.
It has always seemed to me that such descriptive
statistics make more sense as class attributes.
In this
Andrew Jaffe wrote:
> Hi All,
>
> I have just switched from RHEL to debian, and all of a sudden I started
> getting floating point exception errors in various contexts.
>
> Apparently, this has to do with some faulty error stuff in glibc,
> specifically related to the sse. I would prefer to fix t
Curzio Basso schrieb:
>> Well try it out and see for yourself ;-)
>
> good point :-)
>
>> But for sums it doesn't make a difference, right... Note that it's
>> called nan*sum* and not nanwhatever.
>
> sure, I was still thinking about the first post which was referring to
> the average...
>
> qr
Hi All,
I have just switched from RHEL to debian, and all of a sudden I started
getting floating point exception errors in various contexts.
Apparently, this has to do with some faulty error stuff in glibc,
specifically related to the sse. I would prefer to fix the actual
problem, but I can't
Jon Peirce schrieb:
> There used to be a function generalized_inverse in the numpy.linalg
> module (certainly in 0.9.2).
>
> In numpy0.9.8 it seems to have been moved to the numpy.linalg.old
> subpackage. Does that mean it's being dropped? Did it have to move? Now
> i have to add code to my pac
Webb Sprague schrieb:
> Could someone recommend a way to average an array along the columns
> without propagating the nans and without turning them into some weird
> number which bias the result? I guess I can just keep using an
> indexing array for fooArray, but if there is somehting more gracefu
Pietro Berkes wrote:
> On Thu, 13 Jul 2006, Nils Wagner wrote:
>
>
>> It seems to be line 281 instead of 269. I am using latest svn.
>> BTW, in linalg.py in
>>
>> def pinv:
>>
>> there is another Complex with capital C.
>>
>
> Well, the problem is not really the capital 'C', but rather the
28 matches
Mail list logo
