* old bug: in CwiseBinaryOp: only set the LinearAccessBit if both sides have the same storage order.
* new bug: in Assign.h, only consider linear traversal if both sides have the same storage order.
Actually I don't think it's buggy. But it probably triggers existing bugs, I suspect that
some xprs have LinearAccessBit and shouldn't have it.
Also this fixes the "bugs" with JacobiSVD ---> now it works again
* replace implicit constructor AngleAxis(QuaternionBase&) by an explicit one, it seems ambiguous for the compiler
* remove explicit constructor with conversion type quaternion(Quaternion&): conflict between constructor.
* modify EIGEN_INHERIT_ASSIGNEMENT_OPERATORS to suit Quaternion class
* renaming, e.g. LU ---> FullPivLU
* split tests framework: more robust, e.g. dont generate empty tests if a number is skipped
* make all remaining tests use that splitting, as needed.
* Fix 4x4 inversion (see stable branch)
* Transform::inverse() and geo_transform test : adapt to new inverse() API, it was also trying to instantiate inverse() for 3x4 matrices.
* CMakeLists: more robust regexp to parse the version number
* misc fixes in unit tests
is aligned or not. This is done using the Aligned constant:
Map<MatrixType,Aligned>::Map(data);
* rename ForceAligned to EnforceAlignedAccess, and update its doc,
and emphasize this is mainly an internal stuff.
* support resize() to same size (nop). The case of FFT was another case where that make one's life far easier.
hope that's ok with you Gael. but indeed, i don't use it in the ReturnByValue stuff.
FFT:
* Support MatrixBase (well, in the case with direct memory access such as Map)
* adapt unit test
* continue the decomposition until a pivot is exactly zero;
don't try to compute the rank in the decomposition itself.
* Instead, methods such as rank() use a new internal parameter
called 'threshold' to determine which pivots are to be
considered nonzero.
* The threshold is by default determined by defaultThreshold()
but the user can override that by calling useThreshold(value).
* In solve/kernel/image, don't assume that the diagonal of U
is sorted in decreasing order, because that's only approximately
true. Additional work was needed to extract the right pivots.
construction of generic expressions working
for both dense and sparse matrix. A nicer solution
would be to use CwiseBinaryOp for any kind of matrix.
To this end we either need to change the overall design
so that the base class(es) depends on the kind of matrix,
or we could add a template parameter to each expression
type (e.g., int Kind = ei_traits<MatrixType>::Kind)
allowing to specialize each expression for each kind of matrix.
* Extend AutoDiffScalar to work with sparse vector expression
for the derivatives.
