commons-issues mailing list archives

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

    [ 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

       

Mime
View raw message