2011/8/4 Gilles Sadowski :
>> >
>> >> I'm OK to define a new exception. From your PS, I understand that I
should
>> >> wait until what I've already submitted (MATH-581-06.zip) has been
>> committed
>> >> until I submit a patch containing the new exception. Is that right?
>> >
>> > I would have th
Hi,
thanks for your answer.
2011/8/4 Gilles Sadowski :
> Hello.
>
>> I'm OK to define a new exception. From your PS, I understand that I should
>> wait until what I've already submitted (MATH-581-06.zip) has been
committed
>> until I submit a patch containing the new exception. Is that right?
>
>
Hi Gilles,
I'm OK to define a new exception. From your PS, I understand that I should
wait until what I've already submitted (MATH-581-06.zip) has been committed
until I submit a patch containing the new exception. Is that right?
I don't think it's necessary to open a new JIRA ticket for this, do y
Hi,
please review a proposal for the definition of general iterative linear
solvers, as well as the implementation of the conjugate gradient method. This
is file MATH-581-06.zip attached to the JIRA MATH-581 ticket.
Thanks for your comments!
Actually, I *do* have a comment. For the time being,
new
Hi,
I'm finalizing unit tests for the conjugate gradient method, for which I'm
using Hilbert matrices (see http://en.wikipedia.org/wiki/Hilbert_matrix).
These matrices are nice because
i. they are symmetric, positive definite,
ii. they are ill-conditioned,
iii. their inverse is known in closed-form
> My guess is that the final declarations came out of an attempt to avoid
> warnings by over zealous code inspectors that allowing getters and setters
> of private fields to be over-ridden is dangerous. The warning is correct.
> The response was not. The correct response is to not have the privat
I'm sorry. Did you forget to commit {{InvertibleRealLinearOperator}}?
Before I commit new code (Conjugate gradient, SYMMLQ, etc...), I'll open a new
JIRA ticket for having AbstractRealMatrix inherit from RealLinearOperator, if
that's OK with everyone.
Because MATH-581 got a bit messy, I'll also ope
Hello there,
this discussion is now a JIRA ticket (MATH-613).
Have a look and let me know what you think. I'm happy to take care of this if
you all agree on the proposal.
Sebastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons
Thanks to everyone for this interesting discussion.
I've attached a new file to the MATH-581 JIRA ticket, including your comments
(I hope).
Hope this will get integrated into Commons-Math !
Sebastien
-
To unsubscribe, e-mail: dev-
>
> I would go to the natural type we get when building the exception. If we
may
> build the exception from both types, then I would select RealVector. We do
> not intend to perform large processing on elements, but we want to display
> them and I think we do have formatting for vectors.
>
> best r
Hi everyone,
well the message below did not raise much of an interest... My apology, I
forgot to quote [math] in the title.
Anyway, I have a new proposal regarding this issue. I do not know what your
view on the subject is, but I tend to think that exceptions should return
references and not deep c
Ted,
Mahout seems to be fairly large (!). What classes should I look at more
specifically?
Thanks!
Sebastien
>The Colt package used a functional style to implement what you suggest.
> This approach has been inherited by Mahout.
> The basic idea is that there is an assign method that takes other a
That sounds interesting. I was thinking of something like mapping a bivariate
function to two vectors, but was afraid of performance issues. Your feedback
on this is encouraging!
As for the approach used in Mahout, is it similar to the "Procedure"s in GNU
Trove? It takes a little bit of time to gra
Hi,
in Blas, the method DAXPY can lead to very compact code. As far as I know, it
has no equivalent in RealVector. There are a few method called ToSelf,
which modify the calling vector, instead of returning a new one, but these are
restricted to scalars operating on vectors.
In other words, the
It seems a viable option to me, as long as the Javadoc is explicit enough.
Sebastien
Dear all,
following our previous discussions, I'm ready to commit some code regarding
iterative linear solvers. I've read through the Apache web pages on the
subject, but I still have some very silly questions (I do apologize in
advance).
1. Checkstyle complains about a missing version number in my
> [...]
> The question is thus: Is it OK to provide pointless methods?
> I also wonder whether it is reasonable to _generate_ state variables just
> so that the accessors can return them.
> Usually, when a exception is constructed, it is _passed_ data that provide
> the context of the failure (i.e.
2011/5/10 Gilles Sadowski
>
> On Mon, May 09, 2011 at 08:52:57PM +0200, Sébastien Brisard wrote:
> > Le 09/05/11 17:31, Phil Steitz a écrit :
> > >On 5/9/11 4:27 AM, Gilles Sadowski wrote:
> > >>Hi.
> > >>
> > >>>I'm currently trying to integrate my implementation of iterative
linear
> > >>>solv
etColumn() would not always be meaningful.
3. Same remark goes to NonPositiveDefiniteMatrixException. We *should* be able
to raise such an exception when a calculation leads to x'.A.x < 0. Again, it
is neither possible, nor desirable to locate the coefficient which is
inconsistent.
I do not really see a satis
Do you think MAHOUT would be more appropriate to host such solvers?
SB
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
20 matches
Mail list logo
