Issue 72 in ellipsoids: Replace calculation of transition matrix and good direction with the normalized tranzition matrix and normalized good directions

[ellip...@googlecode.com]

Status: New
Owner: swige....@gmail.com
Labels: Type-Enhancement

New issue 72 by heartofm...@gmail.com: Replace calculation of transition
matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Ellipsoid approximation calculator uses the transition matrices X(t,t0) to
calculate the good directions l(t) for ellipsoidal approximation. The
problem is that for certain systems (matrices A(t)) norm of l(t) grows very
fast while a diameter of the reachability domain doesn't change much. You
can find an example of such system in the branch of Kirill Mayantshev:

D:\SVN_Local\EllToolBoxAll\branches\issue_36_kmayantsev\

Just run

gras.ellapx.uncertcalc.test.regr.run_regr_tests({'rot2d'})

The transition matrix X(t,t0) is calculated in the classes located in
+gras\+ellapx\+lreachplain\+probdyn package. The good directions l(t) are
calculated in gras.ellapx.lreachplain.GoodDirectionSet class.

You need to replace the calculation of X(t,t0) with the calculation of
R(t,t0)=X(t,t0)/matrixnorm(X(t,t0)). To do that you need to come up with
ODE for R(t,t0). Please consider different types of matrix norms and come
up with the best. The idea is that the norm of l(t) will not grow as long
as matrix norm of X(t,t0) doesn't grow.

Of course your change should
1) make gras.ellapx.uncertcalc.test.regr.run_regr_tests({'rot2d'}) pass
2) not break any tests run by gras.ellapx.uncertcalc.test.run_tests

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[ellip...@googlecode.com]

Comment #1 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Please copy rot2d.xml files (one for system parameters and one - for the
configuration parameters) into your branch and very carefully delete them
from Kirill's branch. This way we will be able to reintegrate Kirill's
branch into the trunk without introducing any test failures. rot2d
configuration will go into the trunk along with your modifications once you
are done with your task.

[ellip...@googlecode.com]

Comment #2 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Please use the attached configuration as an additional test and put it next
to rot2d into
\products\+gras\+ellapx\+uncertcalc\+test\+regr\+conf\confrepo\_templates

Thanks.

Attachments:
ellDemo3test.xml 4.1 KB

[ellip...@googlecode.com]

Comment #3 on issue 72 by kirill.m...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

(No comment was entered for this change.)

Attachments:
demo3firstBackTest.xml 4.1 KB
demo3firstBackTestSys.xml 1.4 KB

[ellip...@googlecode.com]

Comment #4 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

After reintegration of Kirill's branch in your branch you should enable
testBackward test from ContinuousReachFirstTestCase test case
(demo3firstTest configuration)

[ellip...@googlecode.com]

Updates:
Labels: Priority-Critical

Comment #5 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

(No comment was entered for this change.)

[ellip...@googlecode.com]

Comment #6 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) Study +gras\+ellapx\+lreachplain\GoodDirectionSet.m class, it is
responsible for calculating l(t) based on Xtt0. As the first
step it calculates X(s,t) and then calculates l(t) as l(t)=X(s,t),'l_s
(where s is a touch time, time where the tubes touches the reach set
along the fixed direction l_s specified in configuration). X(s,t) is
calculated based on X(t,t0) as X(s,t0) * X(t0,t)


2) Let us make sure that Xtt0-related methods and variables are renamed to
reflect the fact that we now use Rtt0 everywhere.
Here is the list of places:


- getXtt0Dynamics method and related variables/properties in
AReachProblemDynamics to getRtt0Dynamics().
- getXstTransDynamics methods and related variables/properties in
+gras\+ellapx\+lreachplain\GoodDirectionSet.m
- there are other places - run a search for Xtt0 and Xst strings (Ctrl+F in
matlab main window, don't forget to enable 'Match case' checkbox

When renaming, please make sure that after renames Rtt0 is not used
incorrectly (it could be that some places that use the fact
that Xtt0 is not normalized Xtt0 but actual Xtt0. If you have any questions
regarding the code - please ask.


3) Now, regarding 7 tests that fail.
I think that first of all we need to modify the
support-function test in SuiteSupportFunction. Currently the test in this
test case calculates
rho(l(t)|X(t)) solving an equation for l(t) (not normalized) and rho(l(t)|
X(t)) at the same time
(n+1)-dimensional ODE. Since replacing X(t,t0) with R(t,t0) should
increase a precision of
calculation for some types of systems we need to make sure that

rho(l(t)|X(t)) is calculated based on l(t) normalized as in GoodDirections
class. Thus we need to change the way rho(l(t)|X(t))
is calculated in SuiteSupportFunction: instead of calculating l(t) in
parallel with rho(l(t)|X(t)) we need to use nearly-normalized l(t)
calculated by gras.ellapx.uncertcalc.run (line 96
in SuiteSupportFunction). gras.ellapx.uncertcalc.run on line 74 builds
goodDirSetObj that you can put into SRunProp structure
retured by gras.ellapx.uncertcalc.run. Then you can use nearly-normalized
l(t) returned by
getGoodDirOneCurveSpline/getGoodDirOneCurveSplineList/getGoodDirCurveSpline
methods in GoodDirections and instead of solving (n+1)-dimensional
ODE for rho and l(t) solve 1-dimensional ode for rho given the already
calcualted normalized l(t).

Also we need to introduce a few cosmetic changes to SuiteSupportFunction
test case:

Please introduce the following changes in SuiteSupportFunction

a) In gras.ellapx.uncertcalc.test.regr.run_support_function_tests script use

gras.gen.MatVector.fromFormulaMat
gras.mat.symb.iscellofstringconst

to check for the presence of disturbance.

b) In gras.ellapx.uncertcalc.test.regr.mlunit.SuiteSupportFunction,
getHandleFromCellMat method via using

matOpObj=gras.mat.CompositeMatrixOperations();
matObj=matOpObj.fromSymbMatrix({'sin(t)','sin(t)';'cos(t)','cos(t)'});
%once you have matObj you can calculate its value using
matObj.evaluate(t) %command

b) in derivativeSupportFunction method of SuiteSupportFunction eliminate
the redundant calls evaluating the matrices.

Once you do 1-3 we should run the tests again and decide what to do next.

[ellip...@googlecode.com]

Updates:
Summary: Replace calculation of transition matrix and good direction with

the normalized tranzition matrix and normalized good directions

Comment #8 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Sorry for summary change.

[ellip...@googlecode.com]

Comment #9 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

The calcRtt0Dynamics method was moved to GoodDirectionSet class. Because
some AReachProblemDynamics properties have been required for calculations,
I made them public for reading.

Another question: the AReachProblem* classes now don't do anything with
Rtt0Dynamics property. Is it necessary to be kept in superclass?

[ellip...@googlecode.com]

Comment #10 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) Making properties public is something you should never do. First of all,
we do not use public properties in the project, we use getters instead.
Also, already have the getters for both At dynamics and timeVec (see the
interface). Please make all the properties private/protected again.

2) No, that is why you should have deleted getRtt0Dynamics getter from the
interface and Rtt0Dynamics property from abstract class

[ellip...@googlecode.com]

Comment #11 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) The same question for getOdePropList in AReachProblemDynamics (it was
protected method). Keep it public or look for some other way?

[ellip...@googlecode.com]

Comment #12 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Just copy-paste this protected method with the corresponding constants into
GoodDirectionsSet. It is ok for the latter to have its own getOdePropList
method.

[ellip...@googlecode.com]

Comment #13 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

It means that constant protected properties from AReachProblemDynamics:
ODE_NORM_CONTROL and CALC_PRECISION_FACTOR must also be copy-pasted to
GoodDirectionsSet. Is it ok to spread parameters definitions?

[ellip...@googlecode.com]

Comment #14 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Yes, it is normal as in GoodDirectionSet we might need to use ode settings
different from the ones in Dynamics classes.

[ellip...@googlecode.com]

Comment #15 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

As far as I can see you are almost done with the cosmetic changes.

As you know there are two groups of configurations:

a) those for which the tests from SuiteSupportFunction failed even before
you replaced X with R
b) those that caused failures after your changes.
I think the most efficient way for you to proceed is to pick a
configuration from group b) and figure out what is broken. Once all
SuiteSupportFunction tests for configurations from group b) pass we can
start dealing with group a)

[ellip...@googlecode.com]

Comment #16 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I have compared v(t) = l(t) / norm(l(t)) results for algorithms:
0) X(t, t0);
1) normalized X(t, t0);
2) R(t, t0);

The difference between 0) and 1) is ~1e-10; between 0) and 2) [also 1) and
2)] is ~1e-9. So the l(t) calculations are correct in all cases.

[ellip...@googlecode.com]

Comment #17 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

The file with rot2d and other error tests.

Attachments:
bad_tests.rar 6.4 KB

[ellip...@googlecode.com]

Comment #18 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Please, no rar. Only zip or 7z.

[ellip...@googlecode.com]

Comment #19 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

The file with rot2d and other error tests.

Attachments:

bad_tests.zip 7.5 KB

[ellip...@googlecode.com]

Comment #20 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Partial tests results:

PASSED:
lib_run_tests()
elltool.linsys.test.run_tests()
elltool.conf.test.run_tests()

FAILED:
gras.test.run_tests() (20 errors - non existent field & tolerance)
elltool.reach.test.run_tests() (25 errors - tolerance)
elltool.core.test.run_tests() (2 errors - cvx failed)
elltool.demo.test.run_tests() (1 error - tolerance)

[ellip...@googlecode.com]

Comment #21 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Ok, aglorithm assumes no difference with trunk in terms number of failed
tests. Thus you just have introduced some bug when refactoring stuff.
Please have them fixed so that all the tests that pass in trunk pass in
your brunch.

[ellip...@googlecode.com]

Comment #22 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

And once again, no need to run everything everytime, just choose one
configuration and use it for debugging.

[ellip...@googlecode.com]

Comment #23 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

At first about "Reference to non-existent field 'goodDirSetObj'" error: in
SuiteRegression.m we are loading resMap from disk (line 62) then getting
SExpRes (line 89). During the work on the issue i added a field
goodDirSetObj field to struct, which returns from run() (we need it to get
access to cubic spline of calculated Rst and goodDirVec). But the cache
file was created before, in loaded SExpRes there is no
field 'goodDirSetObj'.

The error raised on line 93, when we try to read the field 'goodDirSetObj'
which exists in SRunProp, which is returned by modified run() and doesn't
exist in SExpRes, which is stored on disk.

[ellip...@googlecode.com]

Comment #24 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

At first about "Reference to non-existent field 'goodDirSetObj'" error: in
SuiteRegression.m we are loading resMap from disk (line 62) then getting

SExpRes (line 89). During the work on the issue I added a
field 'goodDirSetObj' to struct, which is returned by run() (we need it to
get access to spline of calculated Rst and goodDirVec). But the cache file
was created before, and in loaded SExpRes there is no field 'goodDirSetObj'.

[ellip...@googlecode.com]

Comment #25 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

There is a simple solution - just make gras.ellapx.uncertcalc.run return an
additional structure SRunAuxProp with a single field (for now) -
goodDirSetObj. In the support function check test suite just take this
object from the second structure. This way the regression test suite will
remain untouched.

[ellip...@googlecode.com]

Comment #26 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

In r1414 all support function tests were passed. I left old code, because
it will be necessary in my future work. As soon as all problems with
current tests are solved, I'll remove the old code. Now I'm going to run
all tests.

[ellip...@googlecode.com]

Comment #27 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Ok, makes sense, once you run the tests - please fix the problems I found.

[ellip...@googlecode.com]

Comment #28 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Replacement of the X(s, t) equations by R(s, t) equations in that manner:

dx = -x * fAt(t);

by:

cachedMat = -x * fAt(t);
dx = cachedMat - x * sum(x(:) .* cachedMat(:)); % norm(x) = 1 and it's
important.
% x here is R(s, t)

can solve 'ellDemo3Test'. But it doesn't work for 'demo3firstTest':

(SData):(1)...
ltGoodDirMat-->{1}Max. difference (525844227911575808) is greater than the
specified tolerance(1.000000e-06)
(1).ltGoodDirNormOrigVec-->{1}Max. difference (568059436781805952) is
greater than the specified tolerance(1.000000e-06)
(1).ltGoodDirNormVec-->{1}Max. difference (568059436781805952) is greater
than the specified tolerance(1.000000e-06)

It also raises failures in other tests. Some tolerance errors can be solved
by replacing euclidean norm (enorm) for matrices to enorm'() = enorm() /
sqrt(n). It was chosen because enorm'(eye(n)) = 1. So in regr_tests()
vector norms are also important and in many cases we can't just replace
X(s, t) with R(s, t) - we get l'(t) = l(t) / norm(X(s, t)). But if we use
l(t) = R'(s, t) l(s) * norm(X(s, t)) we have errors with tolerance because
of huge value of norm(X(s, t)) (~1e+18).

[ellip...@googlecode.com]

Comment #29 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Finally we are getting somewhere!

1) We NEED to reingetrate ASAP until you continue with replacing X(s,t)
with R(s,t). Thus please
a) Finish cleaning the code
b) Re-cache 'ellDemo3Test' and 'demo3firstTest' if necessary
c) Finish investigation of N_POITNS and PRECISION_FACTOR. You also may
re-cache some configurations if you get tolerance about 1.2e-6 while the
expected one is 1e-6. This is not very significant difference.

Please concentrate on 1) so that we can do this reintegrate. After that
you'll be able to continue with R

2) Now about R. Regression tests are not very representative because the
data in the cache files is not precise so when something fails can you
please tell me what kind of error are we talking about:

a) comparison with cache error (CacheErr) OR

b) EllTube consistency error (ConsErr) OR

c) support function tests error. (SuppErr) This is very important. We can
even use the aforementioned codes for these errors to save time. Please
always specify these codes when you talk about errors/failures.

3) Do you have an idea which kind of matrix norm would solve ConsErr and
SuppErr?

[ellip...@googlecode.com]

Comment #30 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

All errors are CacheErr for gras.ellapx.test.regr.run_regr_tests():

'test3d': tolerance is 5.2e-6 and grows while PRECISION_FACTOR is
decreased, doesn't depend of CGRID_COUNT. Will be recached.

'demo3thirdTest': tolerance is 1.17e-6. Will be recached.
'osc8': tolerance is 1.93e-6. Will be recached.

'x2dtest': QArray tolerance is 6.86e-5 and decreasing the PRECISION_FACTOR
doesn't make anything better.
xTouchCurveMat & xTouchOpCurveMat tolerance is 1.78e-6.

'uosc8': .MArray tolerance is 5.85e-4. QArray tolerance is 2.16e-6.

'ellDemo3Test' and 'demo3firstTest' will be recached in separate commit.

[ellip...@googlecode.com]

Updates:
Status: ReadyForReview

Comment #31 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Test data for regr_tests() was recached. Code for R(s, t) was removed.

[ellip...@googlecode.com]

Updates:
Status: ReviewFailed

Comment #32 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I really want to reintegrate but I still see two problems:

1) CALC_PRECISION_FACTOR is TOO low, 1e-2, 1e-3 would be fine, but 1e-5 is
just way too low and I'm concerned that it would slow down the calculation
significantly. What is the performance difference between 1e-3 and 1e-5?
Use profile or tic/toc to meansure the calculation time. You can even use
log4j logging to report the calculation time, this way this functionality
will be useful for a future use.

2) calcHalfRstDynamics function structure doesn't comply with the
encapsulation principle because the function knows whether sTime is less
that endTime or not (i.e. it contains if operator).

You need to make sTime and endTime comparison outside this function and
make the function code unified, not dependent on whether sTime is less that
endTime or not. This might require changing the input parameters of the
function or/and its structure - please figure out how this can be done.



function [timeRstHalfVec, dataRstHalfArray] = ...
calcHalfRstDynamics(self, endTime, fRstDerivFunc, ...
sRstInitialMat, calcPrecision)
%
import gras.ode.MatrixODESolver;
%
odeArgList = self.getOdePropList(calcPrecision);
sizeSysVec = size(sRstInitialMat);
%
solverObj = MatrixODESolver(sizeSysVec, @ode45, ...
odeArgList{:});
if (self.sTime ~= endTime)
if (endTime < self.sTime)
timeVec = linspace(0, self.sTime - endTime, ...
self.CALC_CGRID_COUNT + 1);
else
timeVec = linspace(self.sTime, endTime, ...
self.CALC_CGRID_COUNT + 1);
end
[timeRstHalfVec, dataRstHalfArray] = solverObj.solve( ...
fRstDerivFunc, timeVec, sRstInitialMat);
%
dataRstHalfArray(:,:,1) = [];
if (endTime < self.sTime)
timeRstHalfVec(end) = [];
timeRstHalfVec = endTime + timeRstHalfVec;
dataRstHalfArray = flipdim(dataRstHalfArray, 3);
else
timeRstHalfVec(1) = [];
end
else
timeRstHalfVec = [];
dataRstHalfArray = [];
end
end

[ellip...@googlecode.com]

Updates:
Status: Started

Comment #33 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I reduced CALC_PRECISION_FACTOR to reduce tolerance errors in all tests. If
the CALC_PRECISION_FACTOR is lesser there is no serious advantage. We can
after all increase it to 5e-4 (and I think it will be optimal), and also
increase CALC_CGRID_COUNT to 7500 or 8000 - it gives an advantage on high
CALC_PRECISION_FACTOR to 'x2dtest' but also increase tolerance error
in 'demo3thirdTest' and 'osc8'

On 'x2dtest':
*) CALC_PRECISION_FACTOR = 1e-4; CALC_CGRID_COUNT=7500
tolerance error = 6.796e-5 for QArray, 1.695e-6 for xTouchCurveMat

*) CALC_PRECISION_FACTOR = 5e-5; CALC_CGRID_COUNT=7500
tolerance error = 6.973e-5 for QArray, 1.75e-6 for xTouchCurveMat (it was
increased)

On 'demo3thirdTest' and 'osc8' - the Opposite behaviour:
*) CALC_PRECISION_FACTOR = 5e-5; CALC_CGRID_COUNT=750 is more accurate than
*) CALC_PRECISION_FACTOR = 1e-4; CALC_CGRID_COUNT=7500

[ellip...@googlecode.com]

Comment #34 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

What time does it take to calculate R(s,t) for 1e-5? for 1e-4? I would
prefer to have the logging (see how it is done in
gras.ellapx.uncertcalc.run, line 99).

[ellip...@googlecode.com]

Comment #35 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Also, the question is - do we have configurations for all three cases:

a) s is between t0,t1,
b) s=t0
c) s=t1

If we don't I think it would make sense to create separate simple test case
GoodDirections class just to make sure that all three case are handled
correctly.

[ellip...@googlecode.com]

Comment #36 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Now we have config for:
*) s is between t0, t1 - 'x2dtest'
*) s = t0 - 'demo3thirdTest'

I didn't find any tests where s = t1.

[ellip...@googlecode.com]

Comment #37 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

To avoid writing the tests for GoodDirections you can change some
configuration to make s equal t1.

[ellip...@googlecode.com]

Comment #38 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

And what about MatrixODESolver?

[ellip...@googlecode.com]

Comment #39 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Have it fixed and write the addition tests for the case t0=t1. Then remove
if (endTime~=startTime).

[ellip...@googlecode.com]

Comment #40 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Added 'onedirend' test, based upon 'onedir' test. There s=t1=6.

[ellip...@googlecode.com]

Comment #41 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Calculations performed by gras.ellapx.uncertcalc.run are not cheap. I think
you need to change the existing configuration and update the cache.
Creating a new configuration just to check t1=s case is an overkill.

OR you can add a new configuration but it has to be 3 or 2 dimensional
system which is fast to calculate.

[ellip...@googlecode.com]

Comment #42 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Here is the deal - in our project we do not implement/fix anything without
the tests. For the bug you fixed in MatrixSolver you also need to write a
new test. Actually the test should have been the first, and the
implementation - the second. The tests for the matrix solver already exist,
you just need to a new one.

[ellip...@googlecode.com]

Comment #43 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

So, if GoodDirectionSet.m is ok, I must (re)write tests for:

*) s = t1
*) t0 = t1

How can I do it? Is there another method than create new config?

[ellip...@googlecode.com]

Comment #44 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) You need to create a simple xml config/create a new one for 2-3
dimensional system for the case when s=t1.

2) You need to write a test for MatrixODESolver that would reproduce the
bug in MatrixODESolver that you already fixed. The tests for this class are
located in gras.ode.test.mlunit.SuiteBasic

I won't be available till 6th so you can reintegrate if you do 1-2. If you
break something in trunk - please revert immediately.

GoodDirections is ok.

[ellip...@googlecode.com]

Comment #45 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Test configuration for s = t1 case was changed to test2dend (based upon
demo3secondTestSys (size = 2x2; [t0 t1] = [0 3]; s = 3)

[ellip...@googlecode.com]

Comment #46 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

MatrixODESolver test for (t0 == t1) case was added to testMatrixODESolver()
in SuiteBasic.m (gras.ode.test.mlunit.SuiteBasic)

[ellip...@googlecode.com]

Comment #47 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

There is a problem. Two tests 'ellDemo3Test' and 'demo3firstTest' were
recached using calculation results of my system. However there are
differences in calculation between my system and yours (on server). The
difference is tiny, however for such tests it becomes valuable. So there
are three solutions:

1) Wait R(s, t) implementation.
2) Recache these tests on your computer (or server) and then update the
cache in trunk after reintegration (so these tests will be passed on
server, but may won't be passed on other systems)
3) Delete cache files for these tests and then 1). The tests will pass on
all systems (but in fact it's like switch them off).

[ellip...@googlecode.com]

Comment #48 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Here is the list of changes we discussed:

1) Create AGoodDirections interface and two implementations:
GoodDirectionsGeneric and GoodDirectionsLTI inherited from AGoodDirections

2) Create a factory with create method that accepts the same input
parameters as GoodDirections constructors. Within this create method you
use the following approach to decide which class to construct:

if isa(pDynObj,'gras.ellapx.lreachplain.probdyn.AReachProblemLTIDynamics')

goodDirObj=....GoodDirectionsLTI(...);

else

goodDirObj=....GoodDirectionsGeneric(...);

end

and please do not forget to rename pDefObj into pDynObj in GoodDirections
class.

3) You replace all calls of GoodDirections constructor with Factory.create.
Please do not forget to change ReachContinuous as the latter also uses
GoodDirections class.

[ellip...@googlecode.com]

Comment #49 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Please use GoodDirsContinuousGen and GoodDirsContinuousLTI names instead of
the ones specified above.

[ellip...@googlecode.com]

Comment #50 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

In r1602 all Support Function tests are passed.

[ellip...@googlecode.com]

Comment #51 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

There are several errors for elltool.test.run_tests(). All errors in
elltool.core are specific for my system and will not affect trunk via
reintegration. So there are 3 regr tests: ellDemo3test, demo3firstTest (we
had problems with them at last reitegration). And another one is uosc8. I'm
going to copy cache data from trunk for these tests and run them again.

[ellip...@googlecode.com]

Comment #52 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Tests were not passed. In trunk calculating algorithm is:
1)Get X(t, t0)
2)Get X(s, t) by using X(s, t) = X(s, t0) * inv(X(t, t0)).
3)Get X'(s, t) by using transpose.

The new algorithm is:
1) Get X(s, t)
2) Get X'(s, t) by using transpose.

Probably, that's the reason of test failures. Therefore these tests need to
be recached and then tested on your server.

[ellip...@googlecode.com]

Comment #53 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

So the test data was recached in r1604. elltool.test.run_tests() return
only specific errors in elltool.core. Would you kindly run tests for my
branch to investigate two things:

1) Are there any errors in elltool.core on you server.
2) Did we find the proper algorithm, which passes all regr tests with my
calculated data on your server.

[ellip...@googlecode.com]

Comment #54 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

And are there any parts of code to be corrected?

[ellip...@googlecode.com]

Updates:
Status: ReadyForReview

Comment #55 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

In the rot2d.xml (regr/conf/sysdef) the matrix A is not a rotation matrix.
You can find the test in bed_tests.zip from the issue 72 comment by 22 Apr.
The A matrix in rot2d is:
[ 0 1 ]
[ 1 0 ]
It has eigenvalues 1 and -1 and eigenvectors [1 1]' and [-1 1]'. So some
trajectories' norm has an infinite limit.

The rotation matrix can be:
[ 0 -1] or [ 0 1]
[ 1 0 ] [ -1 0 ]

These matrices have no real eigenvalues.

[ellip...@googlecode.com]

Updates:
Status: ReviewFailed

Comment #56 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) AGoodDirsContinuousFactory.m needs to be renamed into
GoodDirsContinuousFactory as "A"
prefix is only used for abstract classes.

2) I'll run the tests right now and let you know the results.

3) Regarding rot2d - ok, please keep rot2d but rename it into inftraj2d and
please create a proper rot2d config.

[ellip...@googlecode.com]

Comment #57 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I tested support function test with results:

(a.p. - actual precision, e.p. expected precision)

rot2d - works fine.
inftraj2d - a.p. 2.31e-4 for X(s, t); 4.83e-4 for R(s, t); e.p. 2e-4
demo3firstBackTest - a.p. 2.74e+12 for X(s, t); 2.70e+12 for R(s, t); e.p.
2e-5

demo3firstBackTest: error was raised in EllTubeTouchCurveBasic.m lines
154-159. There valList{iTuple}{1} and valList{iTuple}{iVal} ~ 1e+17

inftraj2d: error was raised in EllTubeBasic.m line 167. QArray ~1e+12.

[ellip...@googlecode.com]

Comment #58 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Previous comment was related to current X(s, t) algoritm. I can add all
tests (or just rot2d) to my branch. Support function test results file is
attached. All errors are raised before support function checking, so the
support function checking algorithm can't be reason of these errors.

Attachments:
elltool_curbranch_bt.mat 2.4 KB

[ellip...@googlecode.com]

Comment #59 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I have added bad tests to my branch. So from now on test will be failed. If
you want to run server again please let me know - I'll remove bad tests
configs.

[ellip...@googlecode.com]

Updates:
Status: Started

Comment #60 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

(No comment was entered for this change.)

[ellip...@googlecode.com]

Comment #61 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

The calcEllApxMatrixDeriv function in IntEllApxBuilder.m (lines 11-19) and
DExtEllApxBuilder.m (lines 10-20) may be the reason of errors. It uses
splines and I don't know its behavior on huge values of Q.

[ellip...@googlecode.com]

Updates:
Status: ReadyForReintegration

Comment #62 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Please reintegrate the X part (without the configurations on which the
tests fail).

[ellip...@googlecode.com]

Comment #63 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I've removed all bad configs. Is r1665 good enough to start reitegration?

[ellip...@googlecode.com]

Updates:
Status: Reintegrated

Comment #64 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

(No comment was entered for this change.)

[ellip...@googlecode.com]

Comment #65 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

The branch was reintegrated in r1668. Last revision (r1669) passed all
tests on your server at 15.05.2013 6:34. So I will delete my current
branch. What next?

[ellip...@googlecode.com]

Updates:
Status: New

Comment #66 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

The next step is R implementation.

Also, transpose operation seems to contain the same bug as uminus. Do the
tests you added pass for it?

[ellip...@googlecode.com]

Comment #67 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Now it isn't. It's the only function that works correctly with such code.
The transpose operation makes NxM matrix from MxN. The test can be found in
SuiteOp.m.

I've written a comment #57. It also related to current R(s, t)
implementation.

[ellip...@googlecode.com]

Comment #68 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

0)
Let us forget about bad configs for a second...

Am I correct that the only thing that doesn't allow us to switch from X to
R (without
bad configs) is inability to calculate R as precisely as we calculated X
for LTI systems?

If so - maybe ODE for R will give more precise results than exp/norm(exp)
even for LTI?
Have you checked that?



1) +gras/+gen/matdot.m

% MATDOT calculates the dot production of two square matrices

should be replaced with

% MATDOT calculates the dot product of two square matrices

Also, why do you divide resArr by nMatDim?

2) We need a test for matdot

3) Please write a test for BugFix: MatrixBinaryTimesFunc works with scalar
functions.
4) Please rename

MatrixRealsqrtFunc into MatrixRealSqrtFunc
MatrixRDivideScalarFunc into MatrixRDivideByScalarFunc


5) We need to do something with copy-pasting in SuiteOp, when it was just
6 functions
it was ok to have a copy-pasted block of code for each of them but it
cannot continue forever.
Please create a nested function (or a few nested functions) that perform the
common actions present in each code block. You probably need to
parameterize this
function by op name etc.
See how it was done in elltool.core.test.mlunit.GenEllipsoidTestCase for
example.

6) The following code in SuiteOp is very bad for 2 reasons

a) rsqrt_bspline_test is not logical but still you use it as it were logical
b) rsqrt_bspline_test is named incorrectly

168 + rsqrt_bspline_test = 0;
169 + if rsqrt_bspline_test

Please fix that.

[ellip...@googlecode.com]

Comment #69 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

0) If we'll forget about bad configs, we only need to:

a) recache regr test data (QArray, ltNorm tolerance failures appears
because we changed calculation method)
b) do something with rsqrt_bspline_test (test realsqrt #3 - bad spline)
(the test fails when we try to evaluate rMatFun.evaluate(0). It must be 0
but it's ~3e-4 for spline.

All support function tests work fine (there are errors only in 'inftraj2d'
and 'demo3firstBackTest', which were called 'bad configs').

The only reason to return expm was instability of ode45. It means:
*) ode45 is unstable: the result calculated on my system may be different
from your one on some configurations. And the difference is greater than
expected precision. We investigated it in regr tests.
*) expm is stable (it probably uses infinite series). It means that
difference between your and my result will be lesser than expected
tolerance.

___
What about bad configs:

The problem is that expm and ode45 return different results in configs
where results can reach huge values (it depends not only on X(s, t) or R(s,
t) but also on other system parameters).

As I've written in comment #57 the expm() and expm()/norm(expm()) work with
the same error (~1e-4 in 'inftraj2d' and ~1e+12 in 'demo3firstBackTest').

As I've written in comment #58 and #61: errors with bad configs are raised
before support function checking. The probably reason may be code in
gras.ellapx.lreachplain.ATightEllApxBuilder (lines 54-60). In fact we calc
l(t) by expm and then try to compare it with QArray results of ode45 (test
for touching if I've understood). But Q approximation reaches ~1e+12
(inftraj2d) and ~1e+17 (demo3fistBackTest) on direction, which fails the
test. And we investigated in regr tests that result of ode45 differs from
result of expm on such norm values.

[ellip...@googlecode.com]

Comment #70 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) I divide resArr by NMatDim, because I want this property:

matdot(eye(n), eye(n)) == 1.

It will fix problems with OrigNorms in regr tests.

[ellip...@googlecode.com]

Comment #71 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I also remember that ode45 reported (on one of bad configs) that it needs
time step lesser than 1e-15 (minimal step). It can be the reason of
difference in results of ode45 and expm().

[ellip...@googlecode.com]

Comment #72 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

0)
a) How big are the differences in QArray when switching from X to R for
good configs?
b) For me rsqrt_bspline_test doesn't prove much to be honest because any
method of interpolation is inprecise by its nature. Nothing stops us from
increasing a number of knows which would lead to rMatFun.evaluate(0)
converging to zero.

Can you confirm that exp/norm(exp) is not less precise? For instance, do we
have to re-cache QArray for LTI systems when switching from exp to
exp/norm(exp)/

Regarding bad configs - comparing large values in absolute sense is
useless. We need to compare them in terms of relative difference
2*(Q1Array-QArray2)/(Q1Array+Q2Array).

Can you please temporarily change the error reporting in EllTube and other
relations to show the relative precision as well? This way we will at least
know whether we can safely re-cache.

[ellip...@googlecode.com]

Comment #73 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

So, about your comment #68:

1) fixed in r1732
2) added in in r1732
3) added in r1843
4) fixed in r1843
6) fixed in r1843

5) I made changes in r1854. I've added tests for size consistency, it
compares nCols, nRows and nDim:
[nRows x nCols] ~ nDim that must be.

[1 x 1] ~ 1, [1 x n] ~ 1, [n x 1] ~ 1;
[n x m] ~ 2, empty ~ 2

There were many problems with nDims in spline functions. I covered some
bugs in SuiteOp tests, others will be covered a bit later. There is
inconvenience - when evaluates function with nDim == 1: ConstFunction
returns [n x 1 x t] array (code in AConstMatrixFunction.evaluate(), while
SplineFunction returns [n x t] matrix. It makes the comparison of such
results a bit harder.

I found that ConstMatrixFunction() always set dimensionality to 2. It seems
that ConstMatrixFunction() calls usage is a bad practice. IMHO we must use
ConstMatrixFunctionFactory.CreateInstance() instead.

I added MatrixFunctionFactory class. After some time I had realized, that
the only difference from AMatrixOperations.fromSymbMatrix was checkgen
usage. Is it better to replace the code back to
AMatrixOperations.fromSymbMatrix, or to leave it in current state. Also we
can unite code from MatrixFunctionFactory and ConstMatrixFunctionFactory
into one class.

P.S. In r1854 I switched off plotting in uosc8 config. Is it better to
revert this changing?

[ellip...@googlecode.com]

Updates:
Status: ReadyForReview

Comment #74 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

(No comment was entered for this change.)

[ellip...@googlecode.com]

Comment #75 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

5) Covered nearly all gras.mat.* classes with tests.

[ellip...@googlecode.com]

Comment #76 on issue 72 by swige....@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

5) Covered nearly all gras.mat.* classes with tests in r1865.

[ellip...@googlecode.com]

Updates:
Status: ReviewFailed

Comment #77 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) >Is it better to replace the code back to

AMatrixOperations.fromSymbMatrix,
> or to leave it in current state. Also we can unite code from
> MatrixFunctionFactory and ConstMatrixFunctionFactory into one class.

I agree that the current architecture needs a bit of improvement but we
need to keep our priorities in mind.
The priority #1 is correct X->R replacement, the other things go second.
Thus I suggest that

a) You revert the changes, remove MatrixFunctionFactory class
b) create a new issue describing the need for MatrixFunctionFactory and the
need to merge
ConstMatrixFunctionFactory with ConstMatrixFunctionFactory. If you see
other aspects that require
improvement but not critical right now - please include their description
as well. The issue has to be assigned to me.
we will deal with it in the near future, hopefully in the next semester.


2) >IMHO we must use ConstMatrixFunctionFactory.CreateInstance() instead.
I competely agree, please replace all calls you find or at least those that
stand in your way.

3) >In r1854 I switched off plotting in uosc8 config. Is it better to
revert this changing?

It is ok, you can keep it this way.
-------------

What about the tests for R, do they pass, are we ready to switch from X to
R?

[ellip...@googlecode.com]

Comment #78 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Now, the new facts about subjects of comment #72:

a) In fact, the QArray algorithm became wrong after switching from X to R.
We can't use simplified formulas for l(t) = X'(s, t)l(s) with values l_r(t)
= R'(s, t)l(s).

If we open
(http://paleale.eecs.berkeley.edu/~varaiya/papers_ps.dir/part1.pdf) then:
if we use l_r(t) in (19) and (20) everything will be fine: well get p_r(t)
= p(t) / norm(G(t0, t)); p_r0(t) = p_0(t) / norm(G(t0, t)). The multiplier
norm(G(t0, t)) will not affect (19). Then we transform it into (21) by
using good directions. That is fine for l_r(t) too. All problems begin when
we simplify G'(t0, s)l into l(s) by using the definition of good
directions. That's good for l(t) but incorrect for l_r(t):

l(s) = G'(t0, s)l, but l_r(s) = G'(t0, s)l / norm(G(t0, s)). It depends on
s and will influence to pi(t) in (25) and then to Q derivative in (26). The
only way is to muliply pi(t) in (25) by norm(G(t0, t)) but it's an exact
equivalent of using just l(t) to calc QArray. So here switching to R has no
point.

b) About 'inftraj2d'. Even if we calc QArray correctly it will fail
xTouchCurveMat tests. When we check if xTouchCurveMat point lies on
ellipsoid border we use lrDivideVector:
gras.ellapx.smartdb.rels.EllTubeBasic checkNorm() function.

Here we can find this:
normVec=gras.gen.SquareMatVector.lrDivideVec(QArray,xTouchCurveMat-aMat);
The problem is that Q=QArray(i) here is nearly degenerated. It means that
difference of Q form degenerated matrix is much lesser than norm(Q). If we
calc norm(Q \ Q - eye(n)) we'll get error ~ 9e-4 > testing max tolerance
2e-4. So this error depends on the difference of Q from degenerated matrix.
There is a trick to reduce inv tolerance, but we must solve QArray problem
first.

P.S. If we want ET to work with such systems as inftraj2d, we need to avoid
using inv or divide without checking tolerance of these operations (like
norm(Q \ Q - eye) for example).

[ellip...@googlecode.com]

Updates:
Status: Started

Comment #79 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

In r1931 added mdivide precision checker to EllTubeBasic. So we need to
make a decision about R and X. I suggest to calculate R(s,t) and norm(X(s,
t)) as separate variables. Then real l(t) = R(s,t)*norm(X(s,t)) can be used
for EllTube calculations. After that, for calculated approximations we can
use l_r(t) = R'(s, t)l(s) for example for support function testing &
xTouchCurve testing.

[ellip...@googlecode.com]

Comment #80 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

And a bit about bad configs. I temporarily switched back to X (3 files) and
ran tests. mdivide precision checker solved one problem for 'inftraj2d'
(probably we need to throw error about ill-conditioned QArray matrix if
invPrecision exceeds some threshold. The problem for two bad configs became
the same:

Error: value of field xTouchCurveMat is expected to be dependent only on
(sTime,lsGoodDirVec,MArray).

[ellip...@googlecode.com]

Updates:
Status: ReadyForReview

Comment #81 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

In current state (r1977) several things were done:

1) We can't purely replace X(s, t) with R(s, t) (comment #78) so the new
algorithm calculates R(s, t) and norm(X(s, t)) and then uses X(s, t) =
norm(X(s, t)) * R(s, t) for approximation calculations. We can get access
both to R(s, t) and X(s, t) by using new GoodDirs methods. Current
SuiteSupportFunction uses R(s, t) for testing. After returning to X some
configs (4) needed to be recached (previous cache was the same as the trunk
one). There was a MArray error for 'ellDemo3Test' (~1e-5). For all configs
there were ltGoodDir* errors, but no other MArray, QArray or xTouchCurveMat
errors.

2) The common reason of bad configs failures was ill-conditioned Q matrix.
I added mdivide precision checking into EllTubeBasic. I also was to
increase tolerance in 'inftraj2d'. (We also can decrease t1 instead).

3) The same problem for xTouchCurveMat dependence. Ill-conditioned matrix
is the reason of difference between xTouchCurveMats for external and
internal approximations. I added relative precision checking to
EllTubeTouchCurveBasic, so now it uses both relative and absolute precision
checking. The reason why I've left absolute precision checking is
insufficient calculation precision for 'uosc8' and 'test3d'. The absolute
precision is < 2e-4 but they don't pass relative precision test (the norm
of vectors ~ 3e-1). As all bad configs and new discrete configs pass the
relative precision test, I disabled negative regularization tests (these
configs have failed EllTubeTouchCurveBasic dependence tests before, and
these tests were checking for it to be so).

Current revision (r1977) passes all tests.

[ellip...@googlecode.com]

Comment #82 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I saw your commits but need time to review your code, hopefully I'll be
done today...

[ellip...@googlecode.com]

Updates:
Status: ReviewFailed

Comment #83 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Good job, I think that you are almost done and mixed R/X solution makes a
perfect sense. We just need to do some minor refactoring of your code and
then reintegrate.

0) Please merge from trunk.
1) What did you have to introduce the scalar matrix function class for?
Just explain, I do not understand why...

2) Please eliminate a copy-pasting in AGoodDirsContinuous in the following
code:

self.ltGoodDirOneCurveSplineList = cell(nGoodDirs, 1);
self.ltRGoodDirOneCurveSplineList = cell(nGoodDirs, 1);
for iGoodDir = 1:nGoodDirs
lsGoodDirConstColFunc = ...
ConstMatrixFunctionFactory.createInstance(...
lsGoodDirMat(:, iGoodDir));
self.ltGoodDirOneCurveSplineList{iGoodDir} = ...
matOpFactory.rMultiply(self.XstTransDynamics, ...
lsGoodDirConstColFunc);
self.ltRGoodDirOneCurveSplineList{iGoodDir} = ...
matOpFactory.rMultiply(self.RstTransDynamics, ...
lsGoodDirConstColFunc);
end
%
lsGoodDirConstMatFunc = ...
ConstMatrixFunctionFactory.createInstance(lsGoodDirMat);
self.ltGoodDirCurveSpline = matOpFactory.rMultiply(...
self.XstTransDynamics, lsGoodDirConstMatFunc);
self.ltRGoodDirCurveSpline = matOpFactory.rMultiply(...
self.RstTransDynamics, lsGoodDirConstMatFunc);

Probably the best way to do that is to use a nested function parameterized
by a dynamics object
(self.RstTransDynamics or self.XstTransDynamics)

3) You cannot just disable the regression tests for elltool.reach. Instead
please investigate
which of them fail and try to teak the parameters to achieve the same
failure.
If you feel that you are out of options trying to achieve the same failure
- please disable the specific case in the test case
(and remove the corresponding code in elltool.reach.AReach or
ReachContinuous). But before doing so you need to be sure
that this specific exception cannot appear again.

4) The following code from EllTubeBasic needs to be moved to
invprecforillcond function in in gras.la package.

a) the function needs to be covered with simple tests
b) number of iterations needs to be an input parameter for the function
and should be declared as a constant in EllTubeBasic.
c) Did you use any article/book to come up with the implemented algorithm
for inv precision calcualtion? If so - please specify it in
the help header of the function. If no - just describe shortly in the
help header what are the mathematical considerations for such algorithm.
d) Naming of certain variables needs to be fixed (see the table in Wiki).
For instance we should not use "i" and "j" names for counters.
Also, please rename ierrVec into invErrVec
e) What will happen if in 10 iteration condition if addInvPrecision < eps
doesn't hold. Do you have an examples of such matrices - if so, please
include them into the tests for invprecforillcond function.
g) How big is the slowdown caused by use of this function in EllTubeBasic?

5) The following code in EllTubeTouchCurveBasic needs to be refactored.

cDims = 1:length(valSizeVec)-1;
v1CMat = num2cell(valList{iTuple}{1}, cDims);
v1NormVec = cellfun(@norm, v1CMat);
for iVal=2:nVals
isOk=isequal(valSizeVec,...
size(valList{iTuple}{iVal}));
if ~isOk
throwError('size',fieldName);
end
%
v2CMat = ...
num2cell(valList{iTuple}{iVal}, cDims);
v2NormVec = cellfun(@norm, v2CMat);
%
actAbsTolVec = abs(valList{iTuple}{1}-...
valList{iTuple}{iVal});
actRelTolVec = 2 .* actAbsTolVec ./ ...
repmat(v1NormVec + v2NormVec, ...
[valSizeVec(1:end-1), 1]);
actRelTol = max(actRelTolVec(:));
actAbsTol = max(actAbsTolVec(:));
%
expTol=(tolVec(1)+tolVec(iVal));
isOk=(actRelTol<=expTol) || ...
(actAbsTol<=expTol);
if ~isOk
optMsg=sprintf(...
['relative tolerance=%g,'...
' absolute tolerance=%g,',...
' expected tolerance=%g'], ...
actRelTol, actAbsTol, expTol);


a) You use the same code for calculating v2NormVec and v1NormVec, please
put it into a subfunction/nested function.
b) I'm concerned with the time it might take to calculate these vectors
because of very inefficient num2cell(valList{iTuple}{1}, cDims); call.
I'd suggest to use gras.gen.MatVector methods to calculate norm for
array and matrix fields of EllTube-like relations. To do that please
-- Move evalMFunc methods from gras.gen.SquareMatVector to
gras.gen.MatVector class
-- Check for dimensionality of valList{iTuple}{1} (within the
newly-created sub/nested function). if =3 - use evalMFunc directly. If =2
use shiftdim to transform n x m arrays (like aMat or others) into 1 x n x
m. After that apply evalMFunc. If =1 - no need to calculate norm. If >3 -
throw an exception
saying that such fields are not supported.

[ellip...@googlecode.com]

Updates:
Status: Started

Comment #84 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

0) Ok.

1) The constant matrix function was introduced when I was working on
dimensionality problems. I have wanted it to be used, but after I declined
it. The MatrixScalarCubicSpline is necessary because of problems of issue
127 number 7. Now it's the only 1-dimensional class which returns the
[1x1xnTimePoints] format result of evaluation. The MatrixColCubicSpline and
MatrixRowCubicSpline returns [1 x nTimePoints] format result and cannot be
used in multiply function. You said to concentrate on R / X problem, so I
just implemented the scalar class which is able to be used for Multiply
operation.

3) I'll try to find the system, but I think that we'll need a new config.

4) In fact it's quite rough estimation of error (I increased tolerance in
inftraj2d because this method couldn't achieve good estimation (the
estimation was lesser than the real difference). However it was the only
config with such problem.

e) In fact it reaches eps in 3 iterations for current configs. The absolute
value of series elements grow down with exponential speed. About such
matrices - it's a difficult question, because it depends on mdivide
implementation. And I don't know what method they use for mdivide.

g) With current configs I didn't find any noticeable slowdown. But I think
that it may appear for systems with large dimensionality.

[ellip...@googlecode.com]

Updates:
Status: ReadyForReview

Comment #85 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

So about your comment #83:

2) I added subfunction in r1992.
3) I found parameters values which make same failures in r1995.
4) I added function 'elldistprec', tests and help header. We can control
function with N, maxTol and minTol. The last version is r1997, and it'll be
great if you check help header for mistakes and misprints.
5) Done in r1992.

So I suggest to run tests for the branch on your server. We need to
investigate - will the results for reach regr tests and new gras.la tests
be the same as on my machine.

Now all tests are passed.

[ellip...@googlecode.com]

Comment #86 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I think the current way of calculating the relative distance between
vectors v1 and v2 is not 100% correct because v1-v2 you calculate
element-wise as abs(v1-v2) while norms of v1 and v2 are calculated in terms
of Eucledean norm. I think that we need to calculate absolute distance
between v1 and v2 as ||v1-v2||_2. For absolute tolerance I would also use
the same norm. Would you agree?

I've scheduled the tests to run at 7 in the morning.

[ellip...@googlecode.com]

Comment #87 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Ok, I'll try the other relative distance algorithm. As for absolute one -
there are two test cases, which don't pass relative distance (comment #81 -
3). However I'll try the vector norm for absolute tolerance too.

And what about last commits. Is everything (first of all 'elldistprec' help
header) ok?

[ellip...@googlecode.com]

Comment #88 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

gras.ellapx.regr.* tests were passed with vector norm, so I'll commit it.

[ellip...@googlecode.com]

Comment #89 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

The tests have been launched at 7 AM but haven't finished for some reason,
I'll be able to investigate it only late in the evening...

[ellip...@googlecode.com]

Comment #90 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Yesterday's run never finished for some reason, the tests still were
running when I killed the process, probably this was caused by CPU/RAM
shortage. Anyways, today's run seems to be in better shape - still running
and according to the logs in passes the stage the previous run was at.
Waiting for results...

[ellip...@googlecode.com]

Comment #91 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

Yes, on my machine such behavior appeared when I have started tree MATLAB
processes simultaneously (to test trunk, and two versions of my branch).
One process just stops its calculations (but not hangs).

[ellip...@googlecode.com]

Updates:
Status: ReviewFailed

Comment #92 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) Tests on the sever have not passed, you should have received an email.
2) Test run has modified the following mat file on disk
+gras/+ellapx/+uncertcalc/+test/+regr/+mlunit/TestData/SuiteRegression/testRegression_out/ab79db56d38825ea4f9e63a2ca8663db9d71c914.mat

which shouldn't have happened.

3) Run time increased by 1 hour which is very strange given that you've
disabled plotting in uosc8 and added 3 more configurations. Do you have an
idea why this can be? There are perf_tops_tc.csv and perf_tops.csv
attachements that can provide some information about this especially if you
compare for both your branch and trunk.

4) I'm going to re-run the tests on your branch right now to make sure that
the slow-down is now just a fluctuation caused by the server overload...

[ellip...@googlecode.com]

Updates:
Status: Started

Comment #93 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

3) The most slowdown I've noticed appeared in support function tests. The
main reason is the complexity of derivative function (and the slowdown
grows with config (t1-10) and dimensionality). Probably it's the main
reason. On my machine time ratio is mybranch / trunk ~ 1.22 (I switched off
plotting for uosc8* configs in my trunk local copy too). For your machine
it's nearly a hour more time to test.

2) Thats very strange. Can you send me the modified file?

1) Yes, and that's why I suggested to run them. As you have noticed the
results on my machine and yours may be different. Now the ideas config by
config:

a) Errors: both for 'inftraj2d' in EllTubeBasic. We can do two things:
increase precision in 'inftraj2d' config OR (AND) decrease t1 to 9. Current
distance prec algorithm works quite well for this config and (act_prec -
dist_prec - expect_prec) ~ 1.5e-4

b) demo3firstBackTest - diff in QArray ~ 1e+22, xTouchCurve & OpCurve ~
2e+3. I've got the same errors before recaching. The QArray here reaches ~
1e+27 and it's ill-conditioned. So we can 1) calc relative precision (as we
did in EllBasicTouchCurve), 2) reduce t1. It passes EllTouchCurveBasic
tests so relative prec wiil be fine.

c) discrFirstTest: here are only errors in ltGoodDirMat,
ltGoodDirNormOrigVec, ltGoodDirNormVec ~1e-4 vs tol ~ 1e-6. No QArray and
TouchCurve problems. So, I think that we need to compare normalized good
directions (l(t) / norm l(t)).

d) uosc8: MArray error ~2e-6 vs tol 1e-6. A also got it before recaching.
The same way: 1) increase tolerance 2) reduce time. The relative precision
here may fail as it is in EllTubeTouchCurveBasic.

e) discrete Regularization test. I used here ill-conditioned ellipsoid as
control boundary and it failed the negative test, but the error was raised
(probably a different type than test was checking for).

[ellip...@googlecode.com]

Comment #94 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

I optimized EllTubeBasic in r2009 - now it calculates elldistprec only for
time point with maximum absolute precision. The testing time must reduce,
but the complexity of derivative support function will give you at least
0.08 (~20 min)

[ellip...@googlecode.com]

Comment #95 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

As I see, the second test time is much lesser than the first one. It seems,
that we need to run tests twice to get the real time.

And now about comment #93 - 1e.

I changed the reg test in r2010. Can you run the:

elltool.reach.test.run_discrete_reach_tests()

(not all tests, but only this part). It consumes much lesser time to get
results.

[ellip...@googlecode.com]

Updates:
Status: ReadyForReview

Comment #96 on issue 72 by swige.ide: Replace calculation of transition

matrix and good direction with the normalized tranzition matrix and
normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

0) Have you checked changes in trunk, made by Viktor Gribov. May I merge
with trunk.

1) I've added relative comparison in suite regression and others in r2014.
Some configs may fail the tests even with such changes.

2) I tried to find optimal parameters for 'inftraj2d' (r2012 and r2013). So
it works for algorithm in my branch and in the trunk. I suppose that it
must work on your machine too. I also made elldistprec algorithm to work
only when needed.

3) I changed regularization test. Now it doesn't raise error of the
different type on my machine. (r2010)

Now we need to review and test all changes. I recached all configs, which
have failed the tests. I suggest at first run only (if it's possible):

gras.ellapx.uncertcalc.test.regr.run_regr_tests()
elltool.reach.test.run_discrete_reach_tests()

, because all errors appeared in this parts (the problems with 'inftraj2d'
apeeared in supp. function and regr tests together).

[ellip...@googlecode.com]

Comment #97 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

1) In elldistprec

a) please specify type and size for all inputs in a formal way:

"nCount: positive integer" - type is still double I guess and size is [1,1]
- right?
Same for minTol, maxTol and prec, what matters is Matlab size and type,
whether a value
is integer or no can be described in plain words

b) Is there any particular reason you haven't used
modgen.common.checkvar/multivar functions
for input argument checking? If this wasn't delibirate - please use those
functions.

c) maxTol/minTol type/size checking and error reporting code is similar,
please create
a subfunction for that.

d) All constants should be declared, 1e-10 in
'if (abs(nCount - round(nCount)) > 1e-10) || (nCount < 1)' is not an
exception.

e) Please add "Example" section to help header.
g) Please remove "end" at the end of the function.


2) Regarding "Errors: both for 'inftraj2d' in EllTubeBasic." I would
suggest to decrease
precision BUT why don't you use relative precision as in
checkTouchCurveIndependence?

3)

> b) demo3firstBackTest - diff in QArray ~ 1e+22, xTouchCurve & OpCurve ~
> 2e+3.
> I've got the same errors before recaching. The QArray here reaches ~
> 1e+27 and
> it's ill-conditioned. So we can 1) calc relative precision

Let us use relative precision here as well please.

Also, please see if you can re-use
the code from checkTouchCurveIndependence by placing it into some separate
function in gras package?

This way you would use this functin in checkNorm,
checkTouchCurveIndependence and SuiteSupportFunction...

4)

> c) discrFirstTest: here are only errors in ltGoodDirMat,
> ltGoodDirNormOrigVec,
> ltGoodDirNormVec ~1e-4 vs tol ~ 1e-6. No QArray and TouchCurve problems.
> So, I think that we need to compare normalized good directions (l(t) /
> norm l(t)).

Ok but since the cache file wasn't commited we could just re-cache the
results, right?


5)

> d) uosc8: MArray error ~2e-6 vs tol 1e-6. A also got it before recaching.
> The same way: 1) increase tolerance 2) reduce time.
> The relative precision here may fail as it is in EllTubeTouchCurveBasic.

I would still try to use relative precision and it doesn't work - then
reduce precision.
We need to keep t1 intact.

6)

> e) discrete Regularization test. I used here ill-conditioned ellipsoid as
> control boundary and it failed the negative test

If you cannot reproduce exactly the same exception - please switch this
part of the test off,
I already have a test for degenerate control boundaries.



7)

> 0) Have you checked changes in trunk, made by Viktor Gribov. May I merge
> with trunk.

Yes, you can merge.

I'm reviewing your changes right now...

[ellip...@googlecode.com]

Comment #98 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

8) we structcompare please add a few more tests to check various
combinations of absTol/relTol.
Just one test is not enough to provide a dense test coverage.

9) Please write a test for maxRelativeTol using EllTube class (see existing
tests in gras.ellapx.smartdb.test.mlunit.SuiteEllTube)
10) Please modify CubeStruct help header as well.
11) In structcomparevec we need a cleaner way of calculating relDistance:
instead of dividing absDistance but sum of norms (which can be zero) and
then checking for Nan
we need to treat "tol" as absTol (please rename "tol" into absTol) which
means that we need to
calculate relative distance only for values with norm greater than absTol.
I.e. if
norm(a)<absTol AND norm(b)<absTol you use JUST absDistance, otherwise - use
relative distance.
This will allow to get rid of check for nan. Actually I would do the same
in other places
you calculate the relative distance just to eliminate a possibility of
denominator being too close to zero.

12) Please revert the changes to t1 because this is not good approach the
problem. Lowering a precision is ok but tweaking the problem parameters to
that the system can solve it is not ok.

[ellip...@googlecode.com]

Comment #99 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

13) As you can see there are some test failures in ellipsoid and hyperplane
tests caused by the changes you made to structcompare function. Please make
sure that your changes are backward-compatible i.e. when no relTol is
specified the function works as previously.

[ellip...@googlecode.com]

Updates:
Status: ReviewFailed

Comment #100 on issue 72 by heartofm...@gmail.com: Replace calculation of

transition matrix and good direction with the normalized tranzition matrix
and normalized good directions
http://code.google.com/p/ellipsoids/issues/detail?id=72

(No comment was entered for this change.)