[ 
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


Reply via email to