Introduce an additional level of abstraction for the linear system dynamics so that the different types of systems can be calculated more efficiently efficiently

[GoogleCodeExporter]

The idea of the change is to be able to vary the way of calculating the system 
dynamics depending on the shape of matrices A(t), B(t) etc

Before you start doing anything run gras.ellapx.uncertcalc.run('default')
and make sure that you understand generally what this command is doing.

The description below uses the notations based on the following formula of the 
linear control system:

\dot(x)=A(t)x+ B(t)u(t)+C(t)v(t), u(t)\in E(p(t),P(t)), v(t)\in E(q(t),Q(t))

The system dynamics is represented by classes 
gras.ellapx.lreachplain.LReachProblemDefInterp % - for the systems without 
uncertainty
gras.ellapx.lreachuncert.LReachProblemDefInterp% - for the systems with 
uncertainty

the classes have methods like 

        function AtSpline=getAtSpline(self)
        function BptSpline=getBptSpline(self)
        function xtSpline=getxtSpline(self)
        function Xtt0Spline=getXtt0Spline(self)

that return a spline object of gras.interp.IMatrixInterpolant type 

classdef IMatrixInterpolant<handle
    methods (Abstract)
        mSize=getMatrixSize(self)
        res=evaluate(self,timeVec)
        nDims=getDimensionality(self)
        nCols=getNCols(self)
        nRows=getNRows(self)
    end
end     

You need to do the the following

1) Rename this interface into IMatrixFunction and move it to gras.gen package, 
fix all the references to this interface in classes located in gras.interp 
package

2) Create gras.ellapx.lreachplain.IReachContProblemDef interface with the 
following methods

        function sysDim=getDimensionality(self) %n
        function bCMat=getBMatDef(self) $B(t)
        function aCMat=getAMatDef(self) %A(t)
        function x0Mat=getX0Mat(self) %X_0
        function x0Vec=getx0Vec(self) %x_0
        function tLims=getTimeLimsVec(self) %[t0,t1]
        function t0=gett0(self)
        function t1=gett1(self)
        function pCVec=getpCVec(self) %p(t)
        function pCMat=getPCMat(self) %P(t)

3) Create gras.ellapx.lreachuncert.IReachContProblemDef interface inherited 
from gras.ellapx.lreachplain.IReachContProblemDef
with the following additional methods

        function cCMat=getCMatDef(self) $C(t)
        function qCVec=getqCVec(self) %q(t)
        function qCMat=getQCMat(self) %Q(t)     

4) Create 2 new classes gras.ellapx.lreachplain.LReachContProblemDef 
(implementes gras.ellapx.lreachplain.IReachContProblemDef )
 and gras.ellapx.lreachuncert.LReachContProblemDef (implementes gras.ellapx.lreachuncert.IReachContProblemDef)
These classes will be just the containers for the system definition, nothing 
more. The constructors of these
classes should look exactly like constructors of  
gras.ellapx.lreachplain.LReachProblemDefInterp and 
gras.ellapx.lreachuncert.LReachProblemDefInterp classe. 

5) Rename LReachProblemDefInterp classes into LReachProblemDynamicsInterp,
Rename methods in gras.ellapx.lreachplain.LReachProblemDefInterp and 
gras.ellapx.lreachuncert.LReachProblemDefInterp
classes like this
        getAtSpline -> getAtDynamics
        getXtt0Spline -> getXtt0Dynamics
6) Create interface gras.ellapx.lreachplain.IReachProblemDynamics with the 
methods getAtDynamics and getXtt0Dynamics
and others and interface gras.ellapx.lreachuncert.IReachProblemDynamics, 
inherited from gras.ellapx.lreachplain.IReachProblemDynamics
that defines the additional methods from 
gras.ellapx.lreachuncert.LReachProblemDefInterp class

Inherit the LReachProblemDynamicsInterp classes from these interfaces, i.e.

gras.ellapx.lreachplain.LReachProblemDynamicsInterp should implement 
gras.ellapx.lreachplain.IReachProblemDynamics

gras.ellapx.lreachuncert.LReachProblemDynamicsInterp should implement 
gras.ellapx.lreachuncert.IReachProblemDynamics

7) Change the constructors of LReachProblemDynamicsInterp classes so that 
instead of 
%AtDefMat,BtDefMat,PtDefMat,ptDefVec,X0DefMat,x0DefVec,tLims,calcPrecision
they accept just 2 input arguments: class IReachContProblemDef and calcPrecision

8) Create the classes

gras.ellapx.lreachuncert.ReachContLTIProblemDef implementing  
gras.ellapx.lreachplain.IReachContProblemDef
    and
gras.ellapx.lreachuncert.ReachContLTIProblemDef implementing  
gras.ellapx.lreachplain.IReachContProblemDef

ReachContLTIProblemDef should have the same constructor but internally should 
check that ALL the matrices do not 
depend on t.

9) Create a simple implementation of IMatrixFunction interface (see above) 
called ConstMatrixFunction,
this implementation would represent a constant function M(t)=M 

10) Create 
gras.ellapx.lreachplain.LReachProblemLTIDynamics class that would implement 
gras.ellapx.lreachplain.IReachProblemDynamics
interface 

and 

gras.ellapx.lreachuncert.LReachProblemLTIDynamics class that would implement 
gras.ellapx.lreachuncert.IReachProblemDynamics
interface 
a) The constructors of these new classes should check that pDefObj (the first 
argument) has 
"ReachContLTIProblemDef" type (use isa(x,'typeName..'))

b) Internally these classes should work differently from 
LReachProblemDynamicsInterp classes - instead of creating
the interplants they should create an instances of ConstMatrixFunction class.

11) Create 2 new classes

    a) 
    classdef gras.ellapx.lreachplain.LReachProblemDynamicsFactory
        methods
            pDynamicsObject=function create(pDefObj,calcPrecision)
            %this method would get an instance of IReachContProblemDef interface and construct
            % and instance of gras.ellapx.lreachplain.IReachProblemDynamics type
            % if pDefObj has type ReachContLTIProblemDef - create LReachProblemLTIDynamics,
            % otherwise - create LReachProblemDynamicsInterp

        end
    end
    b)  
    classdef gras.ellapx.lreachuncert.LReachProblemDynamicsFactory
        methods
            pDynamicsObject=function create(pDefObj,calcPrecision)
            %this method would get an instance of IReachContProblemDef interface and construct
            % and instance of gras.ellapx.lreachuncert.IReachProblemDynamics type
            % if pDefObj has type ReachContLTIProblemDef - create LReachProblemLTIDynamics,
            % otherwise - create LReachProblemDynamicsInterp
        end
    end
12) Test that everything works for both constant and non-constant systems. To 
do that

* See a list of existing system definitions via running 

gras.ellapx.uncertcalc.listsysconf()

* To see the details of an existing definition use 
gras.ellapx.uncertcalc.editsysconf(sysName), 
gras.ellapx.uncertcalc.editsysconf('default') for instance

* Copy existing definition via running 
gras.ellapx.uncertcalc.copysysconf('default','testsys');

* Edit the copied system definition: 
gras.ellapx.uncertcalc.editsysconf('testsys'); If you want to define a system 
with the matrices not-depending on t - make sure that definitions of matrices 
A,B etc do not depend on it.

* See a list of configurations: gras.ellapx.uncertcalc.listconf

* To see  the details of an existing configuration use 
gras.ellapx.uncertcalc.editconf(confName), 
gras.ellapx.uncertcalc.editconf('default')

* Copy the configuration 
Copy existing definition via running 
gras.ellapx.uncertcalc.copyconf('default','testconf');

* Edit the copied configuration
Copy existing definition via running 
gras.ellapx.uncertcalc.editconf('testconf'); make sure to put a correct system
name into 'systemDefinitionConfName' section. I.e. to refer to the system 
'testsys' you need to write 'testsys'.

Once both the system and cofiguraiton are set up type 
gras.ellapx.uncertcalc('testconf') to run the calculation of reachability tubes.

13) Once the implementation has been tested via manual runs you need to run the 
existing test pack to make sure that
nothing is broken, to do that run 

gras.ellapx.uncertcalc.test.run_tests();

if that passes - 

run 

elltool.test.run_tests();

Original issue reported on code.google.com by heartofm...@gmail.com on 31 Oct 2012 at 10:13

[GoogleCodeExporter]

Regarding your questions:

1) A^{-1} - for the constant matrices let's use the same approach of finding 
the center dynamics as the one we use for the time-varying systems (i.e. via 
solving ODE).

2) q(t) is ignored when calculating a center dynamics for the systems with 
uncertainty. Please fix this by creating a protected method "getXtDerivFunc" 
and overriding it in the subclass. The method would return a handle to the 
function that calculates a derivative of xt. In the super class (for the system 
without uncertainty) the method would return

            fHandleR_xt=@(t,x)LReachProblemDefInterp.R_xt(...
                self.AtSpline,...
                self.BptSpline,t,x);

while in the subclass it would return a different handle that accounts for q(t).

3) getDimensionality for non-square matrices. The thing is that 
IMatrixInterpolant was not meant to be used for the non-square matrices. That 
is because instead of interpolating B(t) and C(t) separately we calculate 
B(t)P(t)B^{'}(t) first and then interpolate it. Please rename IMatrixFunction 
into ISquareMatrixFunction. Later, if we need support for the rectangle 
matrices we will just create IMatrixFunction interface without 
getDimensionality method and make ISquareMatrixFunction extend it.

Original comment by heartofm...@gmail.com on 13 Nov 2012 at 7:28

[GoogleCodeExporter]

Regarding 3) - actually I have a better idea - let's just rename 
getDimensionality method in getMaxDimensionality. This way we will know that it 
returns max(n,m) for the matrices from R^{n x m}

Original comment by heartofm...@gmail.com on 13 Nov 2012 at 7:31

[GoogleCodeExporter]

> max(n,m) for the matrices from R^{n x m}

Shouldn't dimensionality be equal to 2 for matrices from R^{n x m}, n > 1, m > 
1? From the AMatrixCubicSpline class:

% dataArray: double[nCols,nRows,nTimePoints]
dSizeVec=size(dataArray);
mSizeVec=dSizeVec(1:end-1);
nDims=length(mSizeVec);

So
dSizeVec == [nCols,nRows,nTimePoints]
mSizeVec == [nCols,nRows]
nDims == 2

My question was, how to deal with empty matrices and matrices from R^{n x 1}, 
R^{1 x m}, R.

Original comment by ivan.v.menshikov on 13 Nov 2012 at 10:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> getXtDerivFunc

Then why do we need LReachProblemDefInterp.R_xt method at all? It does nothing 
but compute x(t) dynamics, and isn't used anywhere else. We could completely 
get rid of it:

% superclass

function fHandleR_xt = getXtDerivFunc(AtSpline,BptSpline)
    fHandleR_xt = @(t,x) AtSpline.evaluate(t)*x+BptSpline.evaluate(t);
end

% subclass

function fHandleR_xt = getXtDerivFunc(AtSpline,BptSpline,CqtSpline)
    fHandleR_xt = @(t,x) AtSpline.evaluate(t)*x+BptSpline.evaluate(t)+CqtSpline.evaluate(t);
end

Original comment by ivan.v.menshikov on 13 Nov 2012 at 10:37

[GoogleCodeExporter]

Anyway, there is a general problem with this approach. The thing is, matlab 
requires a superclass constructor to be called before any other references to 
the object, so even if we redefine getXtDerivFunc method in the subclass so it 
would return something like

@(t,x) 
self.AtSpline.evaluate(t)*x+self.BptSpline.evaluate(t)+self.CqtSpline.evaluate(t
);

we won't be able to use it in superclass constructor, because self.CqtSpline 
property isn't (and can't possibly be) set yet.

Original comment by ivan.v.menshikov on 13 Nov 2012 at 11:27

[GoogleCodeExporter]

1. Matrix X(t,t_0) For LTI systems is now computed as ode solution, since the 
following code is approximately 2 times slower:

data_Xtt0 = zeros([sysDim, sysDim, nTimePoints]);
for iTimePoint = 1:nTimePoints
    data_Xtt0(:,:,iTimePoint)=expm(AMat*(tVec(iTimePoint)-t0));
end

Should I leave it this way?

2. It seems to me that it would better to move isConst method out of 
ReachContLTIProblemDef class. It would be convenient to use something like this 
(couldn't think of a decent name that would cover also discrete-time variable 
k):

modgen.common.type.simple.checkgen(x, 'iscellofstringconst(x)');

3. As for fHandleR_xt issue, I added type check of self to 
LReachProblemDynamicsInterp constructor, so x(t) will be computed only if the 
constructor is called directly (not from subclass constructor). If it's called 
from subclass, the task of computing x(t) fell upon that subclass constructor. 
I don't think it's the best way, but I couldn't think of anything else.

4. There are two properties (N_TIME_POINTS and ODE_NORM_CONTROL) with values 
hardcoded into IReachProblemDynamics implementation, shouldn't we do something 
about that? It's not exactly clear why N_TIME_POINTS should be equal to 1000 in 
all cases. Btw, setting both AbsTol and RelTol to calcPrecision doesn't seem 
like a good decision also.

5. There is a problem with elltool.core.test.run_tests on my machine, more 
specifically, with +elltool\+core\+test\+mlunit\EllipsoidTestCase.m test at 
line 145:

testResVec = 0     Inf    1.0000    2.0000    3.0000    4.0000    5.0000
testAnswVec = 0     0     1     2     3     4     5

I've tested that on unmodified trunk rev. 351. I have Matlab R2012a 32bit, 
Windows 7 64bit.

Original comment by ivan.v.menshikov on 14 Nov 2012 at 7:29

[GoogleCodeExporter]

% dataArray: double[nCols,nRows,nTimePoints]
dSizeVec=size(dataArray);
mSizeVec=dSizeVec(1:end-1);
nDims=length(mSizeVec);

So
dSizeVec == [nCols,nRows,nTimePoints]
mSizeVec == [nCols,nRows]
nDims == 2

this code is located in an abstract class just to avoid a copy-paste. In you 
look at the content of gras.interp package you'll see that it contains 
different classes for rows, columns and matrices. I could have written a 
dimensionality-specific code in the constructor of those classes but I have 
chosen to write a generic code in the constructor of the abstract class instead.

>My question was, how to deal with empty matrices and matrices from R^{n x 1}, 
R^{1 x >m}, R.

You need to implement 3 classes
ConstMatrixFunction,ConstRowFunction,ConstColFunction. As for the empty 
matrices - we do not need them. You can either put the dimensionality 
initialization into AConstMatrixFunction class or initialize it directly in 
each of the aforementioned classes, your choice.

Also you need to implement a factory similar to MatrixInterpolantFactory that 
would choose a class depending on dimensionality of input cell matrix and a 
flag (see how MatrixInterpolantFactory  is implemented). 

One more thing - I know that it is close call, but could you put 
IMatrixFunction and ConstMatrixFunction into gras.mat package?
Thanks.

Finally, we need the tests for the constant matrices, please put them into

gras.mat.test.mlunit.SuiteBasic ( you can use the tests from 
gras.interp.test.mlunit.SuiteBasic as an example).

Original comment by heartofm...@gmail.com on 14 Nov 2012 at 11:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

>Then why do we need LReachProblemDefInterp.R_xt method at all? 
Let's remove it.

>Anyway, there is a general problem with this approach. 
Right, let us introduce a property named 'xtDynamics' (not a class property but 
a property as a named optional input argument) for the super-class constructor. 
If the property is specified - the superclass doesn't try to calculate the 
dynamics by itself. The subclass then would calculate the dynamics before 
calling the super-class constructor and pass the calculated dynamics object as 
an input parameter for the constructor call.

Original comment by heartofm...@gmail.com on 14 Nov 2012 at 12:15

[GoogleCodeExporter]

1. No, please use the matrix exponent as the precision is much more important 
than speed.

2. Please create such function in gras.mat.symb package
Then you will be able to write

import gras.mat.symb.iscellofstringconst;
modgen.common.type.simple.checkgen(x,@iscellofstringconst);

Also, could you please move gras.interp.MatrixSF* and gras.interp.MatrixSymb* 
classes into the same package and fix all the references to them?

3. I suggest we use a constructor property (see above). For parsing the 
properties please use modgen.common.parseparext function.

4. I agree that it doesn't look good but I have a bunch of very strict tests in 
gras.ellapx.uncertcalc.test.mlunit.SuiteRegression/SuiteBasic that make sure 
that 1000 points and absTol=calcPrecision and relTol=calcPrecision is 
sufficient to provide a precision of the final solution equal to calcPrecision. 

Ideally we need to choose a number of points adaptively but this is a separate 
task of questionable usefulness as it is not the speed of interpolation that is 
a performance bottleneck in the system. Before optimizing this part I would 
concentrate on more performance-critical parts of the system first.

5. Thanks for letting me know! Can you please create a Defect and assign it to 
Vitaly Baranov (this is his test). I'll make sure that it gets fixed. Please 
provide as much details as possible.

Good job so far!

Original comment by heartofm...@gmail.com on 14 Nov 2012 at 12:32

[GoogleCodeExporter]

> Right, let us introduce a property named 'xtDynamics'

Unfortunately, there is exactly the same problem with that approach. You see, 
if we want to compute x(t) dynamics before the call to the superclass 
constructor, we'll have to compute AtSpline and BptSpline in the subclass, so 
there won't be much point in calling superclass constructor at all. 

I say, let's make xtDynamics property logical, so if false is passed to the 
superclass constructor, it won't compute x(t). 

Another idea, we could introduce an additional class, let's call it 
AReachProblemDynamicsInterp (it won't be exactly abstract, but I couldn't think 
of a better name), which will do the basic initialization and compute A(t), 
B(t)P(t)B'(t) and B(t)p(t) dynamics, and let *.LReachProblemDynamicsInterp 
classes extend it, so lreachplain.LReachProblemDynamicsInterp will only compute 
x(t), and lreachuncert.LReachProblemDynamicsInterp will compute C(t)q(t), 
C(t)Q(t)Q'(t) and, after that, x(t).

Original comment by ivan.v.menshikov on 14 Nov 2012 at 1:17

[GoogleCodeExporter]

Let's adopt your second idea (the first one creates a backdoor in the 
interface).

Original comment by heartofm...@gmail.com on 14 Nov 2012 at 1:35

[GoogleCodeExporter]

Btw - please change the status of the issue to Started.

Original comment by heartofm...@gmail.com on 14 Nov 2012 at 1:36

[GoogleCodeExporter]

> Let's define xtSpline property as Abstract
Then we'll have to copy it's definition and getter four times, is that wise?

Original comment by ivan.v.menshikov on 15 Nov 2012 at 10:29

• Changed state: Started

[GoogleCodeExporter]

In the last commit a change was made in old LReachProblemDefInterp class so it 
now tries to create
ReachContLTIProblemDef first. That enables the new logic to be used for LTI 
systems without any modifications in
run function. Since test2dbad test system definition is LTI, 
ReachContLTIProblemDef instance is created, and, as consequence, 
LReachProblemLTIDynamics class is used. That results in an insignificant 
divergence between computed and reference data, which is stored in 
+gras\+ellapx\+uncertcalc\+test\+mlunit\TestData\SuiteRegression\testRegression_
out\f784df42b7de668f6fd0287a3fd40d7d266bbb0c.mat file. 

 INFO mlunit.logprintf - ======================================================================
 INFO mlunit.logprintf - FAIL: gras.ellapx.uncertcalc.test.mlunit.SuiteRegression[test2dbad]('testRegression')
 INFO mlunit.logprintf - ----------------------------------------------------------------------
 INFO mlunit.logprintf - confName=test2dbad
 (SData):(1).QArray-->{1}Max. difference (6.140833e-05) is greater than the specified tolerance(1.000000e-06)
(1).ltGoodDirMat-->{1}Max. difference (2.303313e-06) is greater than the 
specified tolerance(1.000000e-06)
(1).ltGoodDirNormOrigVec-->{1}Max. difference (1.908904e-06) is greater than 
the specified tolerance(1.000000e-06)
(1).ltGoodDirNormVec-->{1}Max. difference (1.908904e-06) is greater than the 
specified tolerance(1.000000e-06)
(1).xTouchCurveMat-->{1}Max. difference (6.380940e-06) is greater than the 
specified tolerance(1.000000e-06)
(1).xTouchOpCurveMat-->{1}Max. difference (6.380940e-06) is greater than the 
specified tolerance(1.000000e-06)
(1).xsTouchOpVec-->{1}Max. difference (6.262857e-06) is greater than the 
specified tolerance(1.000000e-06)
(1).xsTouchVec-->{1}Max. difference (6.262857e-06) is greater than the 
specified tolerance(1.000000e-06)

Original comment by ivan.v.menshikov on 16 Nov 2012 at 1:50

[GoogleCodeExporter]

If I delete that file, all tests pass, and new 
f784df42b7de668f6fd0287a3fd40d7d266bbb0c.mat file is created. Should I commit 
it?

Original comment by ivan.v.menshikov on 16 Nov 2012 at 2:29

[GoogleCodeExporter]

>Then we'll have to copy it's definition and getter four times, is that wise?
Well, we would have to re-define only the property, the getter for the abstract 
property doesn't have to be abstract so it wouldn't be redefined. 

Re-defining xtSpline property 4 time is not that big of a deal and in return we 
make the top-level class really abstract so that a user can't instantiate it 
without inheriting from it. 

Original comment by heartofm...@gmail.com on 16 Nov 2012 at 5:03

[GoogleCodeExporter]

1) LReachProblemDefInterp class should be replaced with IReachProblemDynamics, 
if necessary - extend IReachProblemDynamics so that it contains all necessary 
methods. uncertcalc.ApproxProblemPropertyBuilder should be modified to create 
an instance of IReachProblemDynamics, not LReachProblemDefInterp 

2) LReachProblemDynamicsFactory should have an additional createByParams method 
which would accept a the same input as ProblemDef constructors.  ProblemDef 
classes should have an additional isCompatible method that would return true or 
false depending on whether a set of problem parameters is compatible with the 
class. For instance LReachContProblemDef.isCompatible(aCMat,...) would return 
true for LTI system and false otherwise. The factory should use these methods 
instead of try-catch to decide which class to use. ApproxProblemPropertyBuilder 
 should be modified to use this factory. Use of try-catch is a very bad style, 
I wrote about it on http://code.google.com/p/ellipsoids/wiki/Coding_policy long 
time ago...

3) Should I commit it? Not now. The fact that different approaches give the 
results that differ more than calcPrecision allows that either my old classes 
or new LTI classes doesn't work precisely enough. We need to implement a set of 
tests that would compare LTI vs non-LTI classes on LTI systems. To do that 
could you please implement the third test suite by just copy-pasting 
SuiteRegression making it compare two different classes. The new suite should 
be called SuiteCompare It is easy to do - you just need to create a few pairs 
of mirror configurations: one with a constant A and one - with A(1,1) modified 
like this A(1,1)*t/t. 
Since we do not want the tests from SuiteRegression to run longer because of 
additional configurations you would have to 
a) move everything in package uncertcalc.test to uncertcalc.test.regr  
b) create an additional pair of configuraiton repo mangers in 
uncertcalc.test.conf.comp
c) Write the third suite uncertcalc.test.comp.mluni.SuiteCompare (as described 
above)
d) Write uncertcalc.test.comp.run_tests function so that it loads the 
configurations for SuiteCompare by pairs. The pairs should be hard-coded in 
run_tests
e) Write uncertcalc.test.run_tests which would call test.regrs.run_tests and 
test.comp.run_tests

Once the comparison test suite is done we will see how my old (or new LTI) 
classes should be modified so that the results do not differ more than 
calcPrecision allows.

Please do not think that I do not keep track of the task scope, the more you do 
in this ticket - the less will have to be done for the next one.

Thanks.

Original comment by heartofm...@gmail.com on 16 Nov 2012 at 6:04

[GoogleCodeExporter]

> LReachProblemDefInterp class should be replaced with IReachProblemDynamics, 
if necessary - extend IReachProblemDynamics so that it contains all necessary 
methods. uncertcalc.ApproxProblemPropertyBuilder should be modified to create 
an instance of IReachProblemDynamics, not LReachProblemDefInterp 

So what I sould do is add to IReachProblemDynamics interface all these getters?

        getBPBTransSpline(self)
        getAtSpline(self)
        getBptSpline(self)
        getxtSpline(self)
        getXtt0Spline(self)
        getX0Mat(self)
        getx0Vec(self)
        getTimeLimsVec(self)
        gett0(self)
        gett1(self)

It already contains

        getBPBTransDynamics(self)
        getAtDynamics(self)
        getBptDynamics(self)
        getxtDynamics(self)
        getXtt0Dynamics(self)
        getTimeVec(self)

Is that a good decision? I mean, if you want to replace LReachProblemDefInterp 
class with IReachProblemDynamics class everywhere, you might as well replace 
all calls to methods like getBPBTransSpline with calls to methods like 
getBPBTransDynamics. You'll have to do it sometime, why don't do it now?

Original comment by ivan.v.menshikov on 16 Nov 2012 at 9:48

[GoogleCodeExporter]

>I mean, if you want to replace LReachProblemDefInterp class with 
>IReachProblemDynamics class everywhere, you might as well replace all calls to 
>methods like getBPBTransSpline with calls to methods like getBPBTransDynamics. 
You'll >have to do it sometime, why don't do it now?

This is exactly what I wanted you to do. Please go ahead.

Original comment by heartofm...@gmail.com on 16 Nov 2012 at 9:51

[GoogleCodeExporter]

You can reintegrate.

Original comment by heartofm...@gmail.com on 18 Nov 2012 at 10:40

• Changed state: ReadyForReintegration

[GoogleCodeExporter]

Original comment by heartofm...@gmail.com on 19 Nov 2012 at 10:02

• Changed state: Fixed