STLification

[mvukov]

There is a new branch of ACADO, the one which should heavily use STL. Currently it is on my remote: https://github.com/mvukov/acado/tree/stlification. In the main CMakeLists.txt you can see what is compiling so far.

Some of the ideas behind this adventure:

• clean code that already exists in STL and make it more compact
• make code more readable
• prepare the code friendly for automatic wrapper generation, e.g. SWIG

Task list:

• [x] BooleanType is typedef of bool
• [x] Remove String, Stream classes, use std::stream and std::string
• [x] Remove dependencies on FILE pointers, as well as on stdio.h
• [x] All file I/O should work on std::ostream and std::istream
• [x] Improved formatting -- e.g. each matrix print should preserve std::ostream flags;
• [x] Most of the code made for Stream and String pointer mangling is removed
• [x] Remove acadoFPrintf and similar creations
• [x] String, const char* -> std::string
• [ ] Improve memory management and use STL containers and shared pointers where possible
• [ ] Make a list of non-backwards compatible changes
• [x] Revive BDF integrator.

Organizational:

• [ ] Unit-testing based on the Boost unittest framework
• [x] Configure Travis-CI builds for unit-testing.

[mvukov]

So far I can compile what was called acado_integrators once upon the time... Moreover, I can compile compile all examples from basic_data_structures folder, and execute them without a problem. However, unit-testing should really check whether all results are correct.

[rienq]

I love this initiative ! good work ;-)

[mvukov]

Everything except CGT is compiling so far... Anyways, compiling code piece-by-piece was a nightmare...

[jgillis]

:+1:

[mvukov]

So far, as of 5e9d42b3bc940b555efc9ce873a9e4529348de13, "standard"/"offline" ACADO works -- I debugged a lot of things (mainly bugs which I introduced while refactoring :facepunch: ). Libs compile as well as examples. Tests, aka make test works fine.

[mvukov]

Some news...

I refactored CGT, completely. It does not work yet, though it compiles. I changed some API functions, so I had to comment some pieces of the code.

Major thing to make CGT working again will be to refactor Matrix class, add sparsity pattern functionality. ... and remove this responsibility from the ExportVariable class.

STL is awesome.

At the end, CGT is gonna be a like plugin to ACADO, really sitting on the top.

BTW, I refactored Options functionality a few days ago, using std::map, templates, shared pointers etc. And added std::string like options. We can later add whatever like options we want :yum:

[ghorn]

Wow!

[rienq]

That sounds really promising indeed ! I should check it out soon..

[mvukov]

I rebased all matrix/vector/linear algebra stuff to use the Eigen3 library, which is gonna be shipped with ACADO, licenses are compatible. I packed version 3.2.0.

The Matrix and Vector classes are now just wrappers around Eigen's classes.

During refactoring, I screwed up BDF integrator, and disabled it for now. Except this, everything works smoothly; I checked a few examples on OSX with valgrind, and they seen to work fine; make test works (except for examples that use BDF integrator). CGT is not being touched, yet.

CGT is the next step...

[ghorn]

:smile_cat:

[jgillis]

I'm wondering what kind of benefits you will see with Eigen. I made a proof-of-concept Eigen backend for casadi matrix arithmetic once ( casadi/casadi@8667ff697ad8e428290084f321ff5ba43c55bd1f ), but if i recall correctly, @joelandersson suspected it would not deliver much benefits.

[ghorn]

I'm wondering exactly the same thing. I'm especially curious about http://eigen.tuxfamily.org/dox/group__SparseQuickRefPage.html

[mvukov]

The main reason for the upgrade of m/v/la functionality is to have something rock-solid. I saw a lot of fishy things happening lately. IMO, Eigen is pretty mature piece of code to be used. So far, I am happy using it :)

Here are more things:

• ideally, we could switch to column major format easily -- via a template parameter.
• I do not have to maintain it on my own
• I can accelerate m/v computation with OpenMP
• FYI, Eigen3 has support for MKL, SuiteSparse, SparseLU and other packages.
• Ah yes, I needed generic matrix type to be able to use something like matrix of bools and matrix of integers.
• It is coded in C++ and documentation and support are fantastic.

To conclude, from something that was not well maintained, I made an upgrade to a mature piece of code.

[ghorn]

I hope you didn't interpret my statement as criticism. I meant that I think it is a great move, and I'm excited to see exactly how great.

[mvukov]

Nope :) I just wanted to back up my decision :)

[jaeandersson]

Good job! I think this will improve the maintainability of the code a lot. I'm curious if it also improves speed, and if so for what operations.

[mvukov]

As of bc501fa2ec28f3cee00aa32283aebe4beae7e703, CGT should work on the level as before. I need to do further checks, so far examples/code_gen.../mpc_mhe/getting_started.cpp works -- here I also illustrated the new syntax to forward sparsity of the weighting matrices.

As more info will come later, here are some important things: matrix and vector classes are templated, and I typedefed a few data types:

• DMatrix - ... of doubles,
• IMatrix - ... of ints (signed!)
• BMatrix - ... of bools

Vector data types are named in a similar fashion. Yes, I stole names from CasADi :p.

As ExportVariable is not exposed any more to users (!), BMatrix is used to convey sparsity pattern of a matrix to the CGT. This is why I refactored half of ACADO, mainly...

From user point of view, this is more/less everything for this round. Now I am gonna work on internals, to make them more efficient and rock-solid.

BTW, BDF integrator is still not working.

All in all, after I test a bit this I will merge this to master.

[jaeandersson]

Yes, I stole names from CasADi :p.

See you in court.

[mvukov]

:smiley:

[ghorn]

FYI:

http://linalg.rubyforge.org/classes/Linalg/DMatrix.html

http://trilinos.sandia.gov/packages/docs/r7.0/packages/moocho/src/DenseLinAlgPack/doc/html/classDenseLinAlgPack_1_1DMatrix.html

http://www.iro.umontreal.ca/~simardr/ssj/doc/html/umontreal/iro/lecuyer/util/DMatrix.html

http://stat.ethz.ch/R-manual/R-devel/library/Matrix/html/dMatrix-class.html

http://patsy.readthedocs.org/en/v0.1.0/API-reference.html

http://aszt.inf.elte.hu/~gsd/pny2/html/eaC_stl/dmatrix.cpp.html

http://www.indiana.edu/~pavlab/software/gclgrid/html/dmatrix_8h_source.html

http://www.geom.uiuc.edu/java/Kali/DMatrix.html

http://digilander.libero.it/carmine.lia/jroboop/doc/javax/robotics/vecmath/DMatrix.html

http://nicta.github.io/scoobi/api/SCOOBI-0.7.0-cdh4/index.html#com.nicta.scoobi.lib.DMatrix

http://robotics.naist.jp/~akihiko-y/doxy/ode0.9/classdMatrix.html

http://www.stanford.edu/~boyd/l1_logreg/structdmatrix.html

http://www.brtt.com/w/index.php?title=Dmatrix(3)

http://www.stata.com/manuals13/m-5dmatrix.pdf

:neutral_face:

[mvukov]

@ghorn good job! :smile:

[mvukov]

As of a292e6c3c17fadd96d5eb641d067581aabab8fd5, there is a new symbolic data type OnlineData, which should replace functionality for which we use Parameter in the CGT.

So far I managed to add the new type to the symbolic core as well as to partially tunnel it to the CGT. Since we abused Parameter functionality a lot in past 2 years, it requires more time to update the whole infrastructure...

All in all, after this upgrade, we will use OnlineData instead of Parameter class for the same stuff. True parameter estimation should be the next step then.

[mvukov]

BTW, @ghorn made a comment that we are gonna use dense matrix type BMatrix for representing sparsity pattern. In case someone is not happy with that, (s)he can convert it to sparse: sparse = dense.sparseView(); ...

[rienq]

nice! :+1:

[mvukov]

With 36bc9e6 the BDF integrator is revived. Because of the dodgy memory management, I was not able to fix factorizations. So, the integrator is not reusing the factorization and the more complex fix should be developed.

[mvukov]

OK, the tests seem to work. They are included now to pass, mandatory (before it was allowed for them to fail executing).

[mvukov]

• to std::string conversion is partly done. Too much old code to be converted...
• Travis is included, AFAIK, to run unit tests. (The thing is that we don't have a lot unit-tests).