2009/6/8 Gael Varoquaux :
> On Mon, Jun 08, 2009 at 12:29:08AM -0400, David Warde-Farley wrote:
>> On 7-Jun-09, at 6:12 AM, Gael Varoquaux wrote:
>
>> > Well, I do bootstrapping of PCAs, that is SVDs. I can tell you, it
>> > makes
>> > a big difference, especially since I have 8 cores.
>
>> Just cu
On Mon, Jun 08, 2009 at 02:17:45PM +0900, David Cournapeau wrote:
> > However, being fairly new to statistics, I am not aware of the EM
> > algorithm that you mention. I'd be interested in a reference, to see
> > if I can use that algorithm.
> I would not be surprised if David had this paper in m
Gael Varoquaux wrote:
> I am using the heuristic exposed in
> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4562996
>
> We have very noisy and long time series. My experience is that most
> model-based heuristics for choosing the number of PCs retained give us
> way too much on this probl
On Mon, Jun 08, 2009 at 12:29:08AM -0400, David Warde-Farley wrote:
> On 7-Jun-09, at 6:12 AM, Gael Varoquaux wrote:
> > Well, I do bootstrapping of PCAs, that is SVDs. I can tell you, it
> > makes
> > a big difference, especially since I have 8 cores.
> Just curious Gael: how many PC's are you
On 7-Jun-09, at 6:12 AM, Gael Varoquaux wrote:
> Well, I do bootstrapping of PCAs, that is SVDs. I can tell you, it
> makes
> a big difference, especially since I have 8 cores.
Just curious Gael: how many PC's are you retaining? Have you tried
iterative methods (i.e. the EM algorithm for PCA)
On Sun, Jun 7, 2009 at 20:44, Fernando Perez wrote:
> On Sun, Jun 7, 2009 at 4:31 PM, David Warde-Farley wrote:
>> A question was raised on the #scipy IRC earlier today, about the
>> behaviour of array() with structured dtypes. After some educated
>> guessing I figured out that for record arrays, t
Gabriel Beckers wrote:
> On Sun, 2009-06-07 at 18:37 +0900, David Cournapeau wrote:
>
>> That's why compiling atlas by yourself is hard, and I generally advise
>> against it: there is nothing intrinsically hard about it, but you need
>> to know a lot of small details and platform oddities to get
On Sun, Jun 7, 2009 at 4:31 PM, David Warde-Farley wrote:
> A question was raised on the #scipy IRC earlier today, about the
> behaviour of array() with structured dtypes. After some educated
> guessing I figured out that for record arrays, tuples (rather than
> lists) must be used to indicate atom
On Sun, Jun 7, 2009 at 18:44, Eric Firing wrote:
> Robert Kern wrote:
>> On Sun, Jun 7, 2009 at 04:44, Olivier Verdier wrote:
>>> Yes, I found the thread you are referring
>>> to: http://mail.python.org/pipermail/python-dev/2008-July/081554.html
>>> However, since A*B*C exists for matrices and act
>> On Sun, Jun 7, 2009 at 04:44, Olivier Verdier wrote:
>>> Yes, I found the thread you are referring
>>> to: http://mail.python.org/pipermail/python-dev/2008-July/081554.html
>>> However, since A*B*C exists for matrices and actually computes (A*B)*C, why
>>> not do the same with dot? I.e. why
Robert Kern wrote:
> On Sun, Jun 7, 2009 at 04:44, Olivier Verdier wrote:
>> Yes, I found the thread you are referring
>> to: http://mail.python.org/pipermail/python-dev/2008-July/081554.html
>> However, since A*B*C exists for matrices and actually computes (A*B)*C, why
>> not do the same with dot
A question was raised on the #scipy IRC earlier today, about the
behaviour of array() with structured dtypes. After some educated
guessing I figured out that for record arrays, tuples (rather than
lists) must be used to indicate atomic elements. What I wondered is
whether this behaviour is
EuroSciPy 2009 Presentation Schedule Published
==
The schedule of presentations for the EuroSciPy conference is online:
http://www.euroscipy.org/presentations/schedule.html
We have 16 talks from a variety of scientific fields.
All about using Python fo
Robert Kern-2 wrote:
>
> On Sun, Jun 7, 2009 at 07:20, Tom K. wrote:
>> Going back to Alan Isaac's example:
>> 1) beta = (X.T*X).I * X.T * Y
> ...
> 4) beta = la.lstsq(X, Y)[0]
>
> I really hate that example.
>
Understood. Maybe propose a different one?
Robert Kern-2 wrote:
>
>
>> See
Olivier Verdier-2 wrote:
>
> There are two solutions to the A*B*C problem that are not quite
> comparable,
> and are not mutually exclusive either.
> 1) allow dot(A,B,C): this would be a great improvement over
> dot(dot(A,B),C),
> and it could virtually be done within a day. It is easy to implem
On Sun, Jun 7, 2009 at 07:20, Tom K. wrote:
>
>
> Olivier Verdier-2 wrote:
>>
>> There would be a much simpler solution than allowing a new operator. Just
>> allow the numpy function dot to take more than two arguments. Then A*B*C
>> in
>> matrix notation would simply be:
>> dot(A,B,C)
>>
>> with
On Sun, Jun 7, 2009 at 04:44, Olivier Verdier wrote:
> Yes, I found the thread you are referring
> to: http://mail.python.org/pipermail/python-dev/2008-July/081554.html
> However, since A*B*C exists for matrices and actually computes (A*B)*C, why
> not do the same with dot? I.e. why not decide tha
when i had problems building atlas in the past (i.e. numpy.test()
failed) it was a problem with my lapack build, not atlas. The netlib
website gives instructions for building the lapack test suite. I
suggest you do that and run the tests on lapack and make sure
everything is kosher.
Chris
On Sun,
thanks for catching the typos!
Chris
On Sun, Jun 7, 2009 at 4:20 AM, Gabriel Beckers wrote:
> On Sat, 2009-06-06 at 12:59 -0400, Chris Colbert wrote:
>> ../configure -b 64 -D c -DPentiumCPS=2400 -Fa -alg -fPIC
>> --with-netlib-lapack=/home/your-user-name/build/lapack/lapack-3.2.1/Lapack_LINUX.a
Based on your site.cfg you posted earlier, your install seems to be
working fine. Your site.cfg doesnt have threaded libraries enabled. If
you want to add threads (assuming you built the threaded atlas .so's),
your site.cfg should look like this (assuming the threaded libs are in
the same directory
There are two solutions to the A*B*C problem that are not quite comparable,
and are not mutually exclusive either.
1) allow dot(A,B,C): this would be a great improvement over dot(dot(A,B),C),
and it could virtually be done within a day. It is easy to implement, does
not require a new syntax, and do
On Sun, Jun 7, 2009 at 3:37 AM, Fernando Perez wrote:
> On Sun, Jun 7, 2009 at 1:28 AM, Fernando Perez wrote:
>>
>> OK. Will send it in when I know whether you'd want the fill_diagonal
>> one, and where that should go.
>>
>
> One more question. For these *_indices() functions, would you want an
On Sun, Jun 7, 2009 at 6:05 AM, David Cournapeau
wrote:
> (Please do not send twice your message to numpy/scipy ML, thank you)
>
> wierob wrote:
>> Hi,
>>
>> int64 and float seem to work for the stderr calculation. Now, the
>> calculation of the p-value causes an underflow.
>>
>> File "C:\Python26
On Sun, 2009-06-07 at 18:37 +0900, David Cournapeau wrote:
> That's why compiling atlas by yourself is hard, and I generally advise
> against it: there is nothing intrinsically hard about it, but you need
> to know a lot of small details and platform oddities to get it right
> every time. That's ju
Olivier Verdier-2 wrote:
>
> There would be a much simpler solution than allowing a new operator. Just
> allow the numpy function dot to take more than two arguments. Then A*B*C
> in
> matrix notation would simply be:
> dot(A,B,C)
>
> with arrays. Wouldn't that make everybody happy? Plus it doe
Thanks for the quick fix.
2009/6/7 David Cournapeau :
> George Nurser wrote:
>> Sorry, I should have said that I'd always deleted the build directories.
>> I now have a better idea about what the problem is.
>>
>> python setup.py config_fc --fcompiler=gnu95 build_clib
>> --fcompiler=gnu95 build_ex
On Sun, 2009-06-07 at 19:00 +0900, David Cournapeau wrote:
> hence *most* :) I doubt most numpy users need to do PCA on
> high-dimensional data.
OK a quick look on the MDP website learns that I am one of the
exceptions (as Gaël's email already suggested).
Gabriel
George Nurser wrote:
> Sorry, I should have said that I'd always deleted the build directories.
> I now have a better idea about what the problem is.
>
> python setup.py config_fc --fcompiler=gnu95 build_clib
> --fcompiler=gnu95 build_ext --fcompiler=gnu95 install
>
> works OK for svn versions < 64
(Please do not send twice your message to numpy/scipy ML, thank you)
wierob wrote:
> Hi,
>
> int64 and float seem to work for the stderr calculation. Now, the
> calculation of the p-value causes an underflow.
>
> File "C:\Python26\lib\site-packages\scipy\stats\distributions.py", line
> 2829,in _
On Sun, 2009-06-07 at 18:37 +0900, David Cournapeau wrote:
> Maybe you did not use the same fortran compiler with atlas and numpy,
> or
> maybe something else. make check/make ptchek do not test anything
> useful
> to avoid problems with numpy, in my experience.
>
> That's why compiling atlas by y
Gael Varoquaux wrote:
> On Sun, Jun 07, 2009 at 06:37:21PM +0900, David Cournapeau wrote:
>
>> That's why compiling atlas by yourself is hard, and I generally advise
>> against it: there is nothing intrinsically hard about it, but you need
>> to know a lot of small details and platform oddities
On Sun, Jun 07, 2009 at 06:37:21PM +0900, David Cournapeau wrote:
> That's why compiling atlas by yourself is hard, and I generally advise
> against it: there is nothing intrinsically hard about it, but you need
> to know a lot of small details and platform oddities to get it right
> every time. Th
Sorry, I should have said that I'd always deleted the build directories.
I now have a better idea about what the problem is.
python setup.py config_fc --fcompiler=gnu95 build_clib
--fcompiler=gnu95 build_ext --fcompiler=gnu95 install
works OK for svn versions < 6481 (where coremath was merged).
I
Apparently the bugfix has been undone in the current bleeding edge
version of numpy:
--- numpy_float64_issue.py
--
from numpy import *
import numpy
print 'numpy.__version__=',numpy.__version__
class adouble:
def __init__(self,x):
Gabriel Beckers wrote:
> OK, perhaps I drank that beer too soon...
>
> Now, numpy.test() hangs at:
>
> test_pinv (test_defmatrix.TestProperties) ...
>
> So perhaps something is wrong with ATLAS, even though the building went
> fine, and "make check" and "make ptcheck" reported no errors.
>
Ma
OK, perhaps I drank that beer too soon...
Now, numpy.test() hangs at:
test_pinv (test_defmatrix.TestProperties) ...
So perhaps something is wrong with ATLAS, even though the building went
fine, and "make check" and "make ptcheck" reported no errors.
Gabriel
On Sun, 2009-06-07 at 10:20 +0200,
Yes, I found the thread you are referring to:
http://mail.python.org/pipermail/python-dev/2008-July/081554.html
However, since A*B*C exists for matrices and actually computes (A*B)*C, why
not do the same with dot? I.e. why not decide that dot(A,B,C) does what
would A*B*C do, i.e., dot(dot(A,B),C)?
Hi,
int64 and float seem to work for the stderr calculation. Now, the
calculation of the p-value causes an underflow.
File "C:\Python26\lib\site-packages\scipy\stats\distributions.py", line 2829,in
_cdf
return special.stdtr(df, x)
FloatingPointError: underflow encountered in stdtr
It seems
On Thu, Jun 4, 2009 at 12:28 PM, Pierre GM wrote:
> I foresee serious disturbance in the force...
> When I use structured arrays, each field usually represents a
> different variable, and I may not be keen on having a same operation
> applied to all variables. At least, the current behavior (raise
Sorry for cross posting
Hello to all,
I've done a script for importing all spectra files in a directory and merge all
them in one matrix. The file imported are dx files. the bad part is that the
file is in matlab and it requite a function from bioinformatic toolbox (jcamp
read).
And now I just
On Sun, Jun 7, 2009 at 1:40 AM, Robert Kern wrote:
>> Both can be useful depending on the case, but it means leaving the
>> first argument as an untyped placeholder and typechecking on it. I
>> don't know if numpy has a policy on avoiding that kind of shenanigans.
>
> *I* do.
OK. I'll go for t
On Sun, Jun 7, 2009 at 03:37, Fernando Perez wrote:
> On Sun, Jun 7, 2009 at 1:28 AM, Fernando Perez wrote:
>>
>> OK. Will send it in when I know whether you'd want the fill_diagonal
>> one, and where that should go.
>>
>
> One more question. For these *_indices() functions, would you want an
>
On Sun, Jun 7, 2009 at 1:28 AM, Fernando Perez wrote:
>
> OK. Will send it in when I know whether you'd want the fill_diagonal
> one, and where that should go.
>
One more question. For these *_indices() functions, would you want an
interface that accepts *either*
diag_indices(size,ndim)
or
d
On Sat, Jun 6, 2009 at 2:01 PM, Robert Kern wrote:
> On Sat, Jun 6, 2009 at 13:30, Fernando Perez wrote:
> Oops! Never mind. I thought it was using mask_indices like the others.
> There is a neat trick for accessing the diagonal of an existing array
> (a.flat[::a.shape[1]+1]), but it won't work
On Sat, 2009-06-06 at 12:59 -0400, Chris Colbert wrote:
> ../configure -b 64 -D c -DPentiumCPS=2400 -Fa -alg -fPIC
> --with-netlib-lapack=/home/your-user-name/build/lapack/lapack-3.2.1/Lapack_LINUX.a
Many thanks Chris, I succeeded in building it.
The configure command above contained two problem
On Sun, Jun 7, 2009 at 02:43, Olivier Verdier wrote:
> There would be a much simpler solution than allowing a new operator. Just
> allow the numpy function dot to take more than two arguments. Then A*B*C in
> matrix notation would simply be:
> dot(A,B,C)
> with arrays. Wouldn't that make everybody
There would be a much simpler solution than allowing a new operator. Just
allow the numpy function dot to take more than two arguments. Then A*B*C in
matrix notation would simply be:
dot(A,B,C)
with arrays. Wouldn't that make everybody happy? Plus it does not break
backward compatibility. Am I mis
47 matches
Mail list logo
