Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sat, 28 Jan 2012 09:55:10 +0000 (UTC)
From: "Thomas Neidhart (Commented) (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <6786088.3951.1327744510163.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <782135791.3947.1327743191819.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (MATH-735) Improvements to linear iterative
 solvers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/MATH-735?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D131954=
72#comment-13195472 ]=20

Thomas Neidhart commented on MATH-735:
--------------------------------------

+1 on bullet 1, this solution is much more elegant.=20
               =20
> Improvements to linear iterative solvers
> ----------------------------------------
>
>                 Key: MATH-735
>                 URL: https://issues.apache.org/jira/browse/MATH-735
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.0
>            Reporter: S=C3=A9bastien Brisard
>            Assignee: S=C3=A9bastien Brisard
>              Labels: event, linear, solver
>
> Before we release version 3.0, I would like to perform some changes to th=
e general framework for linear iterative solvers.
> # Remove interface {{InvertibleRealLinearOperator}}: this was only propos=
ed for handling preconditioners. Let {{M}} be this preconditioner. In the c=
ourse of the iterations, only matrix-vector products of the form {{M^(-1) .=
 y}} are needed, never direct products {{M . x}}. So it's just as simple to=
 provide {{M^(-1)}} as a standard {{RealLinearOperator}}, rather than {{M}}=
 as an {{InvertibleRealLinearOperator}}. This removes a little bit of clutt=
er in the class hierarchy.
> # {{o.a.c.m.util.IterationEvent}} should at the very least have a method =
to get the current iteration number. Overwise, I find myself keeping track =
of the number of times {{o.a.c.m.util.IterationManager.fireIterationPerform=
edEvent(IterationEvent)}} is called, which is both ugly and painfull.
> # {{o.a.c.m.util.linear.IterativeLinearSolverEvent}} should have a method=
 to access the norm of the residual. I was reluctant to specify such a meth=
od in the interface at the start, because I was not sure any iterative solv=
er provides an updated estimate of this quantity at each iteration. In fact=
, I've realized that most (if not all) solvers do, and it's quite nice to b=
e able to access this value while monitoring the progress of the inversion =
(through {{o.a.c.m.utils.IterationListener}}). Otherwise, one has to comput=
e {{b - A . x}} inside the listener, which *doubles* the cost of each itera=
tion!
> # {{o.a.c.m.util.linear.IterativeLinearSolverEvent}} should have a method=
 to access the residual (the vector itself, not only its norm). I'm not sur=
e *all* solvers can do that, so this should be an optional feature, which m=
ight be useful. I see two different possible implementations
> ## specify {{RealVector o.a.c.m.util.linear.IterativeLinearSolverEvent.ge=
tResidual()}} as an optional feature (potentially throwing {{UnsupportedOpe=
rationException}}), together with a method {{boolean o.a.c.m.util.linear.It=
erativeLinearSolverEvent.providesResidual()}}. I think some of us do not li=
ke {{UnsupportedOperationException}}, but this would be similar to what was=
 done in {{RealLinearOperator.operateTranspose(RealVector)}}.
> ## create a new interface {{RealVector o.a.c.m.util.linear.IterativeLinea=
rSolverWithResidualEvent}}.
> I would love to have some feedback on the last point.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira