On Mon, Nov 8, 2010 at 3:20 PM, Warren Weckesser <
warren.weckes...@enthought.com> wrote:
>
>
> On Mon, Nov 8, 2010 at 2:52 PM, Skipper Seabold wrote:
>
>> On Mon, Nov 8, 2010 at 3:45 PM, Warren Weckesser
>> wrote:
>> >
>> >
>> > On Mon, Nov 8, 2010 at 2:17 PM, Skipper Seabold
>> wrote:
>> >>
>>
On Mon, Nov 8, 2010 at 11:33 PM, David Warde-Farley
wrote:
> On 2010-11-08, at 8:52 PM, David wrote:
>
>> Please tell us what error you got - saying that something did not
>> working is really not useful to help you. You need to say exactly what
>> fails, and which steps you followed before that f
On 2010-11-08, at 8:52 PM, David wrote:
> Please tell us what error you got - saying that something did not
> working is really not useful to help you. You need to say exactly what
> fails, and which steps you followed before that failure.
I think what he means is that it's very slow, there's n
Hi Ian,
On 11/08/2010 11:18 PM, Ian Goodfellow wrote:
> I'm wondering if anyone here has successfully built numpy with ATLAS
> and a Core i7 CPU on Ubuntu 10.04. If so, I could really use your
> help. I've been trying since August (see my earlier messages to this
> list) to get numpy running at fu
Matthew Brett :
> Hi,
>
> On Mon, Nov 8, 2010 at 10:34 AM, Pauli Virtanen wrote:
>
>> Mon, 08 Nov 2010 19:31:31 +0100, Pauli Virtanen wrote:
>>
>>
>>> ma, 2010-11-08 kello 18:56 +0100, LittleBigBrain kirjoitti:
>>>
In my system '<' is the native byte-order, but unless I change
Thanks, Nathaniel. Your reply was very helpful.
-Joon
On Mon, 08 Nov 2010 15:47:22 -0600, Nathaniel Smith wrote:
> On Mon, Nov 8, 2010 at 12:00 PM, Joon wrote:
>> Another question is, is it better to do cho_solve(cho_factor(A), b) than
>> solve(A, b)?
>
> If A is symmetric positive definite, t
In article
,
Ralf Gommers wrote:
> On Mon, Nov 8, 2010 at 5:16 AM, Vincent Davis
> wrote:
> >
> >
> > On Sun, Nov 7, 2010 at 1:51 AM, Ralf Gommers
> > wrote:
> >>
> >> Hi,
> >>
> >> Since we weren't able to stick to the original schedule for 1.5.1,
> >> here's a short note about the current
On 8 November 2010 14:38, Joon wrote:
> Oh I see. So I guess in invA = solve(Ax, I) and then x = dot(invA, b) case,
> there are more places where numerical errors occur, than just x = solve(Ax,
> b) case.
That's the heart of the matter, but one can be more specific. You can
think of a matrix by
On Mon, Nov 8, 2010 at 12:00 PM, Joon wrote:
> Another question is, is it better to do cho_solve(cho_factor(A), b) than
> solve(A, b)?
If A is symmetric positive definite, then using the cholesky
decomposition should be somewhat faster than using a more general
solver. (Because, basically, the ch
On Mon, Nov 8, 2010 at 2:52 PM, Skipper Seabold wrote:
> On Mon, Nov 8, 2010 at 3:45 PM, Warren Weckesser
> wrote:
> >
> >
> > On Mon, Nov 8, 2010 at 2:17 PM, Skipper Seabold
> wrote:
> >>
> >> On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold
> >> wrote:
> >> > I am doing some optimizations on
Hi,
> Since the change to git the numpy version in setup.py is '2.0.0.dev'
> regardless because the prior numbering was determined by svn.
>
> Is there a plan to add some numbering system to numpy developmental version?
>
> Regardless of the answer, the 'numpy/numpy/version.py' will need to
> chan
On Mon, Nov 8, 2010 at 4:04 PM, Bruce Southey wrote:
> On 11/08/2010 02:52 PM, Skipper Seabold wrote:
>> On Mon, Nov 8, 2010 at 3:42 PM, Bruce Southey wrote:
>>> On 11/08/2010 02:17 PM, Skipper Seabold wrote:
On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold
wrote:
> I am doing so
On 11/08/2010 02:52 PM, Skipper Seabold wrote:
> On Mon, Nov 8, 2010 at 3:42 PM, Bruce Southey wrote:
>> On 11/08/2010 02:17 PM, Skipper Seabold wrote:
>>> On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold
>>> wrote:
I am doing some optimizations on random samples. In a small number of
>>>
Pierre GM gmail.com> writes:
> On Nov 6, 2010, at 2:22 PM, Damien Moore wrote:
>
> > Hi List,
> >
> > I'm trying to import csv data as a numpy array using genfromtxt.
>
[...]
> Please open a ticket so that I don't forget about it. Thx in advance!
>
The ticket is here: http://projects.scipy.o
On Mon, Nov 8, 2010 at 3:45 PM, Warren Weckesser
wrote:
>
>
> On Mon, Nov 8, 2010 at 2:17 PM, Skipper Seabold wrote:
>>
>> On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold
>> wrote:
>> > I am doing some optimizations on random samples. In a small number of
>> > cases, the objective is not well-d
On Mon, Nov 8, 2010 at 3:42 PM, Bruce Southey wrote:
> On 11/08/2010 02:17 PM, Skipper Seabold wrote:
>> On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold wrote:
>>> I am doing some optimizations on random samples. In a small number of
>>> cases, the objective is not well-defined for a given sampl
On Mon, Nov 8, 2010 at 2:17 PM, Skipper Seabold wrote:
> On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold
> wrote:
> > I am doing some optimizations on random samples. In a small number of
> > cases, the objective is not well-defined for a given sample (it's not
> > possible to tell beforehand a
On 11/08/2010 02:17 PM, Skipper Seabold wrote:
> On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold wrote:
>> I am doing some optimizations on random samples. In a small number of
>> cases, the objective is not well-defined for a given sample (it's not
>> possible to tell beforehand and hopefully wo
On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold wrote:
> I am doing some optimizations on random samples. In a small number of
> cases, the objective is not well-defined for a given sample (it's not
> possible to tell beforehand and hopefully won't happen much in
> practice). What is the most nu
On Mon, 08 Nov 2010 14:06:03 -0600, Bruce Southey wrote:
[clip]
> Numpy uses SVD to get the (pseudo) inverse, which is usually very
> accurate at getting (pseudo) inverse.
numpy.linalg.inv does
solve(a, identity(a.shape[0], dtype=a.dtype))
It doesn't use xGETRI since that's not included
I am doing some optimizations on random samples. In a small number of
cases, the objective is not well-defined for a given sample (it's not
possible to tell beforehand and hopefully won't happen much in
practice). What is the most numpythonic way to handle this? It
doesn't look like I can use np
On 11/08/2010 01:38 PM, Joon wrote:
> On Mon, 08 Nov 2010 13:23:46 -0600, Pauli Virtanen wrote:
>
> > Mon, 08 Nov 2010 13:17:11 -0600, Joon wrote:
> >> I was wondering when it is better to store cholesky factor and use
> it to
> >> solve Ax = b, instead of storing the inverse of A. (A is a symmet
On Mon, 08 Nov 2010 13:23:46 -0600, Pauli Virtanen wrote:
> Mon, 08 Nov 2010 13:17:11 -0600, Joon wrote:
>> I was wondering when it is better to store cholesky factor and use it to
>> solve Ax = b, instead of storing the inverse of A. (A is a symmetric,
>> positive-definite matrix.)
>>
>> Even in
On Mon, 08 Nov 2010 13:23:46 -0600, Pauli Virtanen wrote:> Mon, 08 Nov 2010 13:17:11 -0600, Joon wrote:>> I was wondering when it is better to store cholesky factor and use it to>> solve Ax = b, instead of storing the inverse of A. (A is a symmetric,>> positive-definite matrix.) Even in the
Hi,
Since the change to git the numpy version in setup.py is '2.0.0.dev'
regardless because the prior numbering was determined by svn.
Is there a plan to add some numbering system to numpy developmental version?
Regardless of the answer, the 'numpy/numpy/version.py' will need to
changed because
Mon, 08 Nov 2010 13:17:11 -0600, Joon wrote:
> I was wondering when it is better to store cholesky factor and use it to
> solve Ax = b, instead of storing the inverse of A. (A is a symmetric,
> positive-definite matrix.)
>
> Even in the repeated case, if I have the inverse of A (invA) stored,
> th
Hi,I was wondering when it is better to store cholesky factor and use it to solve Ax = b, instead of storing the inverse of A. (A is a symmetric, positive-definite matrix.)Even in the repeated case, if I have the inverse of A (invA) stored, then I can solve Ax = b_i, i = 1, ... , n, by x = dot(i
Hi,I was wondering when it is better to store cholesky factor and use it to solve Ax = b, instead of storing the inverse of A. (A is a symmetric, positive-definite matrix.)Even in the repeated case, if I have the inverse of A (invA) stored, then I can solve Ax = b_i, i = 1, ... , n, by x = dot(i
Mon, 08 Nov 2010 17:00:34 -0200, Renato Fabbri wrote:
[clip: offtopic]
Please post this on the scipy-user list instead, it's more suitable for
misc questions.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.
Hi,
On Mon, Nov 8, 2010 at 10:34 AM, Pauli Virtanen wrote:
> Mon, 08 Nov 2010 19:31:31 +0100, Pauli Virtanen wrote:
>
>> ma, 2010-11-08 kello 18:56 +0100, LittleBigBrain kirjoitti:
>>> In my system '<' is the native byte-order, but unless I change the
>>> byte-order label to '=', it won't work in
Dear All,
i want to find simple databases, like a 5 dimensional with more than 30 samples.
i am having difficult times with this.
where do you get them?
all the best,
rf
--
GNU/Linux User #479299
skype: fabbri.renato
___
NumPy-Discussion mailing lis
Mon, 08 Nov 2010 19:31:31 +0100, Pauli Virtanen wrote:
> ma, 2010-11-08 kello 18:56 +0100, LittleBigBrain kirjoitti:
>> In my system '<' is the native byte-order, but unless I change the
>> byte-order label to '=', it won't work in linalg sub-module, but in
>> others works OK. I am not sure whethe
ma, 2010-11-08 kello 18:56 +0100, LittleBigBrain kirjoitti:
> In my system '<' is the native byte-order, but unless I change the
> byte-order label to '=', it won't work in linalg sub-module, but in
> others works OK. I am not sure whether this is an expected behavior or
> a bug?
> >>> import sys
>
Hi everyone,
In my system '<' is the native byte-order, but unless I change the
byte-order label to '=', it won't work in linalg sub-module, but in
others works OK. I am not sure whether this is an expected behavior or
a bug?
>>> import sys
>>> sys.byteorder
'little'
>>> a.dtype.byteorder
'<'
>>> b
On Sun, 7 Nov 2010, Ralf Gommers wrote:
> That will require renaming those files in the source tree from *.txt
> to *.rst, otherwise there's no way to have github render them
> properly. Unless I missed something. Would that be fine?
I think a *.rst.txt extension would also be recognized by github
I'm wondering if anyone here has successfully built numpy with ATLAS
and a Core i7 CPU on Ubuntu 10.04. If so, I could really use your
help. I've been trying since August (see my earlier messages to this
list) to get numpy running at full speed on my machine with no luck.
The Ubuntu packages don't
36 matches
Mail list logo
