Note that I removed several #define whose purpose was to avoid typing "typename
ctraits<t>::…". Even though this tends to complicates the code, this is
probably safer, especially since the #define was capturing a free variable (t).
We now use a initializer list constructor for creating symmetries of the form
$y^n$, $y^n u^m$, $y^nu^m\sigma^k$.
The constructor taking a single integer is used to initialize a symmetry of a
given length.
Similar changes are made to IntSequence.
This behavior is similar to std::vector.
- these classes now encapsulate a std::shared_ptr<{const, }double>, so that
they do not perform memory management, and several {Const,}Vector instances
can transparently share the same underlying data
- make converting constructor from ConstVector to Vector explicit, since that
entails memory allocation (but the reverse conversion is almost costless, so
keep it implicit); do the same for GeneralMatrix/ConstGeneralMatrix,
TwoDMatrix/ConstTwoDMatrix
- remove the constructors that were extracting a row/column from a matrix, and
replace them by getRow() and getCol() methods on {Const,}GeneralMatrix
- rename and change the API of the complex version Vector::add(), so that it is
explicit that it deals with complex numbers
- add constructors that take a MATLAB mxArray
In the case where a 2nd/3rd derivative is symbolically not zero but numerically
zero at the evaluation point, the last lines of the g2/g3 matrices (in
KordpDynare::calcDerivativesAtSteady()) where uninitialized (these matrices
store the sparse hessian/3rd-deriv in coordinate list form, i.e. with 3 columns
and as many rows as non-zero elements). When reconstructing the dense
hessian/3rd-deriv matrix out of g2/g3, this would result in invalid memory
accesses.
- in the 3rd derivatives matrix, among symmetric elements, the first one had
the right values but the following ones were set to zero
- moreover, the k-order DLL was trying to add all the symmetric elements in the
folded tensor, instead of only keeping one value among all the symmetric ones
- hopefully, Ondra's tensor library was (silently) refusing to add symmetric
elements after the first (and right) value had been added
- so the final result was correct