[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054733#comment-13054733
]
Gilles commented on MATH-581:
-----------------------------
# The issue is not that it would lead to a bad design. It is just a compromise
between being backward-compatible while still allowing the design to evolve.
Thus it was suggested to limit the potential sources of incompatibilities. A
Java interface is such a source because you cannot add or remove a method
without breaking compatibility. An abstract class is more lenient since you can
add a method and still be backward-compatible.
# Formatting
#* Sometimes a line of code is not aligned with its counterpart in the previous
line, like
{noformat}
void doSomething(final double param1,
final double param2) { // ...
{noformat}
instead of
{noformat}
void doSomething(final double param1,
final double param2) { // ...
{noformat}
#* There are several levels of documentations and several target audiences.
Javadoc comment is a mix of user help and developer help. It should probably
explain how to use to the code to a user experienced with the concept at hand;
and it should also help the developer understand how the concepts are
implemented. But IMHO, it should not try to be a math textbook because HTML is
not suited for that (I mean, _both_ the source and the rendering of
mathematical formulas are ugly). I recently stumbled upon "LaTeXlet" which
enables the embedding of LaTeX code in Javadocs. I had proposed to use it for
complex formulas but the idea was not accepted. Can MathML be used in Javadoc?
# There is a {{getData}} method in {{RealVector}}. So, we can always retrieve a
{{double[]}}, the accessor will return it, and it can used to format a message
that will display the contents of the offending vector.
Personally, I'd prefer plain files (not a patch), which you can attach here (no
need for a new issue). After the first commit of a new file, we can go on with
patches for further modifications.
> 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
