Enum class operation

[schwieni]

The original behavior was that an operation was defined in different
integer values (mostly unsigned char and casadi_int). This is a more
strict definition.
Moreover, in a debugging session reading the words is much easier than
numbers.

[schwieni]

@jaeandersson and @jgillis could someone review this PR, please?
Would this PR be of interested to you?
Thanks!

[jgillis]

@jaeandersson your thoughts?

[schwieni]

Please note, that the type of Operation is controlled by the enum, see: casadi/core/calculus.hpp:60
enum class Operation : unsigned char {
So, in this PR it is set to unsigned char. This can be changed.

[schwieni]

Hi @jaeandersson and @jgillis, sorry to bother you again.
Would this PR be of interested to you?
The issue is just: the more Operations are added the more work it is to merge your work again. I did a rebase twice now.
A simple feedback would be appreciated.
Thank you! :-)

[jaeandersson]

Sorry for the late answer. If I recall correctly, the int data type was originally chosen for efficiency reasons after some experimenting about what ran faster in practice. I think that makes the data size of the virtual machine instruction 16 bytes on common architectures:

• For binary operations: 4 bytes for operation id, 4 bytes for output memory location and 2x4 bytes for input memory location
• For constants: 4 bytes for operation id, 4 bytes for output memory location and 8 bytes for double constant

I definitely think an unsigned data type or enum would be cleaner. You might want to ensure that the data type is an unsigned 4 bytes integer in that case. In general, I wouldn't touch this code however without thoroughly investigating how it impacts existing use across applications. Any change to how the SX virtual machine operates or how SXElem are stored can lead to big performance issues. See also https://github.com/casadi/casadi/blob/main/CONTRIBUTING.md