-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make ReachContinous return an original system dynamics even for a system in a backward time (for a attainability domains) #17
Comments
After several days of looking at the code of ReachContinious and AReach classes, I still can't understand several things:
|
I think that adding a second output for an existing method is a good idea. Let make this method return original dynamics (not modified) as the first output and modified - as a second. Some existing tests expect a modified dynamics as the first output so those tests need to be slightly modified so that they use a second output. Some of the tests perform a transformation upon transformation to restore the original dynamics. Such tests needs to be slightly modified so that they just use the first output wihout any additional transformations. Now about ReachDiscrete. The reason ReachDiscrete wasn't mentioned in the task description in the first place is because for a discrete systems there are already two implementations of ProblemDynamics objects (see implementation of "getSysWithDisturb" in ReachDiscrete) one for the forward time and one - for the opposite time. Thus for ReachDiscrete the solution is a bit simpler - you just construct both dynamics instead of constructing either forward or backward dynamics and return them as different outputs from getIntProbDynamicsList and use only the second output while ReachDiscrete and ReachContinuous should provide their specific implementation of this method. Please let me know if this doesn't answer your question or if you have any other questions. Thus you need to modify ReachDiscrete, AReach and ReachContinuous. AReach should now expect two outputs from |
OK, code has been implemented and tested on sample from issue description (only had to change first line, because in description it's incorrect). Probably this test should be added to test coverage? But I don't quite understand hierarchy of tests in elltool/+reach/+test/+mlunit. Should my test extend some of the test classes there or just mlunitext.test_case (with a single assert on the end in that case)? |
Please note that you when ALL the tests are put into a single test suite See a help header for run_cont_tests for examples that show how to run a particular test Finally some test cases are run for both discrete and continuous systems, for instance the following DiscreteSecReachTestCase < elltool.reach.test.mlunit.ATestDynGettersBaseTestCase I suggest you put your tests into elltool.reach.test.mlunit.ATestDynGettersBaseTestCase elltool.reach.run_cont_tests('.','.','myTestName'); These commands will run your tests for all kinds of systems. Please note that there is no need to create a reach object in your test - will automatically be available I think your test should check a) the first output is the dynamics in forward time
|
Please rename your branch using your real name instead of account name |
Please delete branch issue_17_shm512 |
Can you please explain what function isEqualBPBandpDynBPBatCurTime(pDynBPBMat,curTime,iLinSys) in elltool.reach.test.mlunit.ATestDynGettersBaseTestCase does in test case elltool.reach.test.mlunit.ContinuousSecReachTestCase/testBaseTestDynGetters[demo3fourthTest_IsBackTrueIsEvolveTrue]? Stack trace: |
To keep it brief - this function compares B_P_B.' extracted from probDynObj returned by getIntProbDynamicsList and getExtProbDynamicsList with the same matrix extracted from a list of linear system definition objects called linSysList (the same list passed as input to both ReachContinuous and ReachDiscrete). This list is returned by getSystemList method of ReachContinous/Dynamics. The difference between a system definition object and a problem dynamics object is that the latter contains methods for calculating expressions like B(t)_P(t)_B(t).' that are used directly in ellipsoidal approximation formulas and control synthesis. The best way to see a difference is to compare a linear system definition interface |
I can't understand why linSysCVec (which is returned by getSystemList method) is different from probDynOriginObj (which is returned by getProbDynamics), except for their different class. Both of them are set by linSys parameter of constructor of class AReach. I'm still trying to change it from different places in code - probably that's the only thing I can do, because I still can't understand how this test works. |
The best way is to use a debugger and conditional breakpoints. Please keep trying - I can answer questions but you need to do it by yourself. You can talk to Anastasia Semenova (if she is still around) who is an author of these tests. |
What's the meaning of "BPBTransDynamics" property of class gras.ellapx.lreachplain.probdyn.AReachProblemDynamics (specifically its descendant gras.ellapx.lreachplain.probdyn.LReachProblemLTIDynamics)? Should it be based on system used in calculations or original system? |
BPBTransDynamics object represents B(t)_P(t)_B^{'}(t) matrix function where B(t) is from
Encapsulation OOP concept assumes that classes do not know anything about the way they are used.
Both intProbDynList and extProbDynList are not used in any calculations inside of AReach, at least that was an idea. These properties are there for a record so that class users can get them to see which systems an ellipsoidal approximation correspond to. And I think your idea to make the corresponding getters return two outputs instead of one was a good one. |
In spite of all my attempts (I've completely rewritten my edits several times), this test (elltool.reach.test.mlunit.ContinuousSecReachTestCase/testBaseTestDynGetters[demo3fourthTest_IsBackTrueIsEvolveTrue]) still fails. The only difference causing test failure is between I have only two idea about possible reasons:
Consequently I still have no ideas what to do with it. The only thing I can do - move to issue 38. |
mlunitext.assert_equals(true, isOk,"Something is wrong, bla bla bla"0)
P.S. You can work on your next task in parallel but this one needs to be finished anyway. |
That's not what I'd done. However, now it doesn't matter, as I rewrited all code once more, and finally made it pass. That's because now I used different semantic: |
Right, not now the question is - can we Please note that the goal of this task is to make the "action" object the internal business of Reach classes. The way it is right now all the tests still use action object which should not be a part of the tested interface. This is what we need. We need to make only 'original' object a part of the public interface and keep 'action' object internal. |
Deadline - 1st of November, by that date the code with all the tests should be in "master" branch.
Currently evaluating an solvability tube as per the following example
aMat = {'2_sin(t)' '0'; '0' '2_sin(t)'}; bMat = eye(2);
SUBounds = struct();
SUBounds.center = {'0'; 't/10'};
SUBounds.shape = [.1 0; 0 .1];
sys = elltool.linsys.LinSysContinuous(aMat, bMat, SUBounds);
x0EllObj = ell_unitball(2);
timeVec = [2 0];
dirsMat = [1 0; 0 1]';
rsObj = elltool.reach.ReachContinuous(sys, x0EllObj, dirsMat, timeVec);
rsObj.evolve(-1,sys);
would result into modifying the system parameters so that A(0) is no longer [2 0;0 2]:
pdl = rsObj.getIntProbDynamicsList;
pdl1 = pdl{1}{1};
at = pdl1.getAtDynamics();
at.evaluate(0)
ans =
-1.8186 0
0 -1.8186
This is because "prepareSysParam" method in ReachContinous transforms the system parameters in a such way that a reachability tube for the modified system equals a solvability domain for the original system in an opposite time.
One needs to make sure that modifying the system parameters becomes an internal business of ReachContinous while the system dynamics returned by getIntProbDynamicsList method (and others) corresponds to the original (non-modified) system.
The way to implement this is to create a class that would be a "wrapper" system for any system in forward time. This way instead of manually modifying each system matrix (A(t), C(t), B(t) etc) in prepareSysParam we would just create an instance of the wrapper system like this
backTimeWrapperSysObj=BackwardTimeWrapSystem(sysDynObj);
and then would use this backTimeWrapperSysObj internally while externally getIntProbDynamicsList method and others would return the original dynamics no matter what.
The new wrapper class needs to be placed into products+elltool+linsys package next to other LinSys classes and separately covered with tests in a new test case placed into products+elltool+linsys+test+mlunit package.
Obviously we will have to have 2 different wrapper classes for both discrete and continuous systems.
Also the correct behavior of ReachContinuous and ReachDiscrete classes needs to be covered with
a few tests
\products+elltool+reach+test+mlunit
Finally all the existing tests need to be fixed because in some places it is currently assumed that the getIntProbDynamicsList works the way it works now so those places will have to be fixed so that all the tests pass.
The text was updated successfully, but these errors were encountered: