commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard (JIRA) <j...@apache.org>
Subject [jira] [Commented] (MATH-581) Support for iterative linear solvers
Date Fri, 24 Jun 2011 07:12:47 GMT

    [ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054273#comment-13054273
] 

Sébastien Brisard commented on MATH-581:
----------------------------------------

Thank you for this in-depth review.
# Regarding interfaces: OK for getting rid of LinearOperator, I just wanted to keep this one
to maintain some similarity with matrices in the existing code. However, I agree, this one
is not really useful. By the way, could you point to interesting docs on design recommendations
regarding the choice between interfaces and abstract classes. I often tend to follow the model
implemented in Swing
{code}
public interface Foo{}
public abstract class AbstractFoo{}
public class BasicFoo{}
{code}
which means that very often, the interface is not really needed. But you seem to indicate
in you previous comments that it might also turn into a *bad* design, which I would like to
avoid...
# Regarding formatting:
** not sure about what you mean by misalignment, but I guess that it has to do with checkstyle,
will look into it
** meta-comments: OK (sorry about that),
** I see your point with Javadoc comments, but I tend to think the contrary : I personally
always have the javadoc opened in a nearby browser, and then really appreciate the rich formatting
it offers, especially for mathematical formulas (fortunately, I didn't embedd MathML in this
proposal, otherwise I would have had you scream...). Nevermind, I'll get rid of these.
# Regarding the exceptions
** I agree with you, it would be highly desirable to keep a reference to the real offending
vector, instead of storing a deep-copy. However, the exceptions can be raised with either
{{double[]}} or {{RealVector}}, which makes it difficult to handle it in a consistent way
with references. That's the reason why I work with copies. From this point of view, the methods
{{copyOffendingVector}} and the likes can be used as "accessors".
** I am not aware of {{ExceptionContext}}, but I will look into it. Sounds interesting indeed
# Regarding the links between {{RealMatrix}} and {{RealLinearOperator}}
** What you suggest is great (have {{RealMatrix}} inherit from {{RealLinearOperator}})! Didn't
think about that...
** What I mean about unit testing is that I used simple matrices (Hilbert) to test the conjugate
gradient, and I then had to reimplement matrix-vector product in a {{RealLinearOperator}},
while it is already implemented in {{RealMatrix}}. Thinking about it, composition would have
done just as well, with a little less sweat. Oh well...

Thank you for proposing to take care of the design of the exceptions. Meanwhile, can you also
correct the formatting of these two classes? I'll take care of the rest. How should I submit
the new, corrected patch? As a new attachment to this ticket (say {{MATH-581-02.patch}}),
or as a new JIRA ticket?

> Support for iterative linear solvers
> ------------------------------------
>
>                 Key: MATH-581
>                 URL: https://issues.apache.org/jira/browse/MATH-581
>             Project: Commons Math
>          Issue Type: New Feature
>    Affects Versions: 3.0, Nightly Builds
>            Reporter: Sébastien Brisard
>              Labels: iterative, linear, solver
>         Attachments: MATH-581-01.patch, linearoperator.zip
>
>
> Dear all,
> this issue has already been discussed on the forum. The idea is to implement the most
popular linear iterative solvers (CG, SYMMLQ, etc...) in commons-math. The beauty of these
solvers is that they do not need direct access to the coefficients of the matrix, only matrix-vector
products are necessary. This is goof, as sometimes it is inetficient to store the coefficients
of the matrix.
> So basically, before implementing the iterative solvers, we need to define an interface
slightly more general than a matrix, namely LinearOperator, with only one basic operation:
matrix-vector product.
> Here are a few interfaces and abstract classes that do that. Nothing fancy yet, I just
wanted to have you advice on the implementation before I commit some solvers.
> I thought these classes could go in a package org.apache.commons.math.linearoperator,
but really, I haven't got a clue...
> Best regards,
> Sebastien

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message