Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Thu, 8 Sep 2011 19:18:08 +0000 (UTC)
From: "Luc Maisonobe (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <1252578755.4486.1315509488965.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <85379048.23185.1315360876592.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (MATH-659) Remove solve(double[][]) from
 DecompositionSolver
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/MATH-659?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D131006=
03#comment-13100603 ]=20

Luc Maisonobe commented on MATH-659:
------------------------------------

ODE code is one of the places where a lot of medium size data sets are chan=
ged all the time.
This means that allocating/deallocating is not negligible with respect to d=
ata overwriting. Also as is is a domain where the time to live of data is s=
mall (duration of one of few steps).

These two features implied that we selected to do overwriting and reuse of =
the same arrays and avoided reallocation for the sake of performance. In th=
is specific case, the transformer also acts on matrices that are used by ot=
her classes (see both the parameters and the return type of the update upda=
teHighOrderDerivativesPhase{1,2} methods) and in fact the layout of these a=
rrays is used by the above classes to avoid both reallocation and copies.

This design in the general case was done several years ago, and the specifi=
c case for MultistepIntegrator is more recent. MultistepIntegrator is the b=
ase class of both Adams integrator and also the base class of another integ=
rator I want to include, namely the BDFIntegrator).

This design may well not be adapted anymore to current processors and JVM. =
The multistep integrators are also quite in a flux, there are other JIRA is=
sues about them. So I would really much like to have some benchmarks agains=
t real problems before changing this (i.e. state vector between 2 and 50 el=
ements, integrations of several thousand steps, both very simple and very c=
ostly differential equations, a small set of events detectors ...). It may =
also be wise to wait a little on this class as work is done on it for the o=
ther issues


> Remove solve(double[][]) from DecompositionSolver
> -------------------------------------------------
>
>                 Key: MATH-659
>                 URL: https://issues.apache.org/jira/browse/MATH-659
>             Project: Commons Math
>          Issue Type: Task
>    Affects Versions: 3.0
>            Reporter: S=C3=A9bastien Brisard
>            Assignee: S=C3=A9bastien Brisard
>            Priority: Trivial
>              Labels: linear
>
> Following MATH-653, where {{double[]}} were removed from {{RealVector}}, =
and {{double[] solve(double[])}} was removed from {{DecompositionSolver}}, =
the method {{double[][] solve(double[][])}} should be removed from {{Decomp=
ositionSolver}}. {{RealMatrix solve(RealMatrix)}} should be called instead.

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