Refine implementation of elltool.reach.ReachDiscrete to eliminate all the bugs

[GoogleCodeExporter]

The task in tightly related to issue 58. The goal here is to identify the 
implementation problems within the class and have them fixed. Rewriting parts 
of the class code might be necessary. As the first step please start with the 
tests that 

1) compare the internal and external approximations along good directions and 
perform some other consistency checks.
2) compare the results with the ethalon data for simple examples (for which the 
results can be obtained analytically).

I suggest that you move to the approach #2 only once you are done with the 
first approach.
As part of the first approach (item #1 in the list above) you need to use the 
objects of gras.ellapx.smartdb.rels.EllTube and 
gras.ellapx.smartdb.rels.EllTubeProj classes by placing the calculated 
ellipsoidal approximations into these objects as containers. I.e. you need to 
1) Run calculation of reach tube approximations by calling some methods of 
ReachDiscrete class
2) Then extract the paramters of the tubes for both external and internal 
approximations via calling get_ia/get_ea methods
3) Place the parameters for the tubes into EllTube object.
4) Find the projection of the tubes via calling project method of ReachDiscrete 
class
5) Compare the projection with that EllTube.project method returns

Please note that the comparison of support functions along the good directions 
that you did will be done AUTOMATICALLY by EllTube class once you put all the 
data into it (this comparison is implemented in its internal checkConsistency 
method and is called from the constructor)

System parameters should be stored in xml configurations as it is done for the 
continuous system tests. Please refer to item #2 from the description of the 
ticket http://code.google.com/p/ellipsoids/issues/detail?id=37 to understand 
how xml configurations work. You can also talk to Daniil Stepensky and Kirill 
Mayantsev.

Original issue reported on code.google.com by heartofm...@gmail.com on 18 Mar 2013 at 5:56

[GoogleCodeExporter]

Please make it an input property for ReachDiscrete constructor:

ReachDiscrete(.....,'isMinMax',true)%,'isMinMax=false by default.

Original comment by heartofm...@gmail.com on 19 May 2013 at 12:36

[GoogleCodeExporter]

Please remove the garbage folder 
branches/issue_75_ikitsenko/products/+gras/+ellapx/+uncertcalc/+test/+regr/+conf
/+sysdef/confrepo/89.249.160.102 from svn. Thanks.

Original comment by heartofm...@gmail.com on 27 May 2013 at 3:38

[GoogleCodeExporter]

Looks like you forgot to add the following test cases in run_discrete_tests:

ContinuousReachProjTestCase (see run_continuous_reach_tests)
ContinuousReachProjAdvTestCase (see run_reachcont_proj_adv_tests)

As we discussed, all you need to do is parameterize these test cases with a 
factory and replace ReachContinuous constructor calls with 
reachFactObj.createInstance(...).

To avoid copy-pasting run_reachcont_proj_adv_tests you can rename 
run_reachcont_proj_adv_tests into aux_run_reachcont_proj_adv_tests, 
parameterize this function with a factory and just make both 
run_reachcont_proj_adv_tests and run_reachdiscr_proj_adv_tests call it with 2 
different factories. Then just add run_reachdiscr_proj_adv_tests call to 
run_tests.

Original comment by heartofm...@gmail.com on 28 May 2013 at 10:48

[GoogleCodeExporter]

Original comment by heartofm...@gmail.com on 31 May 2013 at 6:34

• Changed state: ReadyForReintegration

[GoogleCodeExporter]

Original comment by kitse...@gmail.com on 31 May 2013 at 7:23

• Changed state: Started

[GoogleCodeExporter]

After reintegration the branch is useless, please make sure to delete it and 
create a new one with the same name.

Original comment by heartofm...@gmail.com on 31 May 2013 at 7:27

[GoogleCodeExporter]

Original comment by kitse...@gmail.com on 1 Jun 2013 at 8:57

• Changed state: ReadyForReview

[GoogleCodeExporter]

one question and one problem:

1) Constants they are not used in AReach should be moved to 
ReachContinous/Discrete classes, for instance ETAG_ODE_45_REG_TOL  is obviously 
used only in ReachContinous while ETAG_SH_MAT_CALC_FAILURE - only in 
ReachDiscrete.

2) Can you please explain why you think that MATLAB:realsqrt:complexResult 
exception that you catch in ReachDiscrete is not a bug in ReachDiscrete 
implementation and rather a limitation of the solver? Is it because the 
internal estimate degrades? If so - shouldn't we verify for internal estimate 
degradation within the solver and throw a specific exception as opposed to 
saying that any MATLAB:realsqrt:complexResult exception thrown by the solver is 
actualy a result of estimate degradation? What if it is just a bug?

Original comment by heartofm...@gmail.com on 1 Jun 2013 at 6:38

• Changed state: ReviewFailed

[GoogleCodeExporter]

I thought that it was a limitation of the solver because this error was thrown 
during working with shape matrix with numbers about 1.0e+65.

Original comment by kitse...@gmail.com on 1 Jun 2013 at 7:33

[GoogleCodeExporter]

The error was produced by too small lVec and although shape matrix wasn't 
actually degraded (it was regularized) it seemed that calculation accuracy 
wasn't enough to get positive result of calculation <lVec, qMat * lVec>. 
Problem was solved by passing normalized directions to mink* functions. So 
MATLAB:realsqrt:complexResult exception was deleted of try-catch block.

Original comment by kitse...@gmail.com on 1 Jun 2013 at 10:34

[GoogleCodeExporter]

Original comment by kitse...@gmail.com on 1 Jun 2013 at 11:30

• Changed state: ReadyForReview

[GoogleCodeExporter]

Please reintegrate.

Original comment by heartofm...@gmail.com on 2 Jun 2013 at 9:23

[GoogleCodeExporter]

Original comment by kitse...@gmail.com on 2 Jun 2013 at 9:39

• Changed state: Reintegrated

[GoogleCodeExporter]

Original comment by heartofm...@gmail.com on 9 Jun 2013 at 3:27

• Changed state: Fixed