search

SystemAnalysisDpt-CMC-MSU / ellipsoids

Ellipsoidal Toolbox for MATLAB is a standalone set of easy-to-use configurable MATLAB routines and classes to perform operations with ellipsoids and hyperplanes of arbitrary dimensions
http://systemanalysisdpt-cmc-msu.github.io/ellipsoids
Other
19 stars 7 forks source link

Finish getting rid of dependency on Symbolic toolbox and deploy doxygen-based documentation #50

Open irublev opened 6 years ago

NikolayTrusov commented 6 years ago

I got rid of symbolic computations in elltool.reach.ReachContinous, ran a command elltool.reach.test.run_cont_tests and got the following result: +-----------------------------------------------------+ | << PASSED >> || TESTS: 81, RUN TIME(sec.): 4677.6 | +-----------------------------------------------------+ Does that still mean that I have to run the ETB tests on MatLab without Symbolic TB, or I can just run all the tests related to the classes/functions I've made changes?

irublev commented 6 years ago

Nikolay, unfortunately you pushed changes that led to multiple fails (43 errors due absence of isdependent function, you haven't changed the corresponding code). I've found this out after I looked at the results of tests performed on your branch directly on the build server. I'd like to ask you the following: 1) to lauch at least those tests that are directly connected to changes you make each time before you push your branch into the remote repository. 2) to perform rebase on master according to my instructions as soon as possible just to be able to see testing results in the corresponding google group (your branch in its current state is configured so that it uses wrong SMTP server, so the build server is not able to send testing results via e-mail).

irublev commented 6 years ago
  1. Please remove empty section (properties end) and empty function set_up_param from products/+gras/+sym/+test/+mlunit/SuiteBasic.m
  2. In products/+gras/+sym/varreplace.m it is better to use modgen.common.checkvar and modgen.common.checkmultvar functions for checking of input arguments (see our Coding policy for example of how it is to be done).
  3. It is necessary to update help for verreplace, firstly, by pointing what cells of mCMat may be (numbers, strings and symbolic expressions), secondly, by changing the sense of this function (the current contents of this help is out-of-date, because it says something about reverse time, about "reflection" of the system matrix, it is better not to say anything about the system at all, the function is rather abstract), thirdly, by giving a couple of simple examples how this function can be used. The help to varreplace as whole should be reworked to comply with the rules for help headers described in our Coding policy (indents, types of arguments). The reason for this is that this help header is automatically processed by the help collector to provide the manual for the toolbox.

After all the mentioned above is done it is necessary to ask me for reviewing the code once again, then I'll merge this branch into local master, check that all is good and push myself this code to the remote repository.

After this it is necessary to perform rebase on master (just to make new starting point in the branch leading to new loop in log). New commits concerning doxygen should be performed strictly only after this rebase (but while it is not done you can investigate mxberry-core and store the corresponding files locally without commiting them).

irublev commented 6 years ago

By now the function gras.sym.varreplace still has a possibility to take symbolic expressions in its input (it simply transforms them into strings). And this possibility is covered by tests (automatically switched off in the case Symbolic Toolbox is not installed). But it is reasonable to remove all this completely, because in any case Ellipsoidal Toolbox works no longer with symbolic expressions. Another option is to extend this possibility to use symbolic expression to Ellipsoidal Toolbox as whole.

And there are a couple of issues concerning doxygen documentation.

  1. There is a problem with how three dot leaders ("...") are processed by doxygen. It is strange but doxygen thinks it is something special and removes ... from all help headers in verbatim (one dot . and two dots .. remain on their places). And there were attempts to change ... to some special character in prep4doxymat.py (for example &hellip;). But all these attempts were unsuccessful (for &hellip; the problem was that & was transformed by doxygen into &amp;hellip; and it was not possible to force doxygen not to perform this transformation in verbatim). So the temporary solution was to change in prep4doxymat.py ... to . . . (i.e. by inserting spaces between dots). But it is necessary to find some better solution or to send a report in doxygen about this bug. It is also possible that this may be fixed by changing some configuration parameters in Doxyfile configuration.

  2. Currently it is possible to generate doxygen documentation both from Windows (by using bat scripts) and from Linux and MacOS (by using bash scripts). But it is strange that generating of documentation at least from MacOS leads to several <br> in headers of some functions (see for example help for gras.sym.isdependent). Possibly this is connected to improper processing of line ends in prep4doxymat.py under Linux and MacOS. But this problem should be investigated further.