aboutsummaryrefslogtreecommitdiffhomepage
path: root/Eigen/src
Commit message (Collapse)AuthorAge
* bring the modern comfort also to ColPivotingHouseholderQRGravatar Benoit Jacob2009-08-24
| | | | + some fixes in FullPivotingHouseholderQR
* finally, the correct way of dealing with zero matrices in solve()Gravatar Benoit Jacob2009-08-24
|
* add logAbsDeterminant()Gravatar Benoit Jacob2009-08-24
| | | | | move log and exp functors from Array to Core update documentation
* give FullPivotingHouseholderQR all the modern comfortGravatar Benoit Jacob2009-08-24
|
* clarifications in LU::solve() and in LU documentationGravatar Benoit Jacob2009-08-24
|
* fix bug: with complex matrices, the condition (ei_imag(c0)==RealScalar(0)) ↵Gravatar Benoit Jacob2009-08-24
| | | | | | | | being wrong could bypass the other condition in the &&. at least that's my explanation why the test_lu was often failing on complex matrices (it uses that via createRandomMatrixOfRank) and why that's fixed by this diff. also gcc 4.4 gave a warning about tailSqNorm potentially uninitialized
* mergeGravatar Benoit Jacob2009-08-23
|\
* | add ColPivotingHouseholderQRGravatar Benoit Jacob2009-08-23
| | | | | | | | rename RRQR to fullPivotingHouseholderQR
| * hm, forgot to conjugate the arguments in applyJacobiOnTheLeftGravatar Gael Guennebaud2009-08-24
| |
| * fix apply Jacobi for complexes and add documentation for some *Jacobi* functionsGravatar Gael Guennebaud2009-08-23
|/
* add initial, rough, full-pivoting RRQR decompositionGravatar Benoit Jacob2009-08-22
| | | | | lots of room for improvement! and add Gael a (c) line in Householder.h
* work around internal compiler error with gcc 4.1 and 4.2, reported on the forumGravatar Benoit Jacob2009-08-20
|
* * make HessenbergDecomposition uses the Householder moduleGravatar Gael Guennebaud2009-08-17
| | | | * bugfix in ei_blas_traits for .conjugate().conjugate()
* change the make householder algorithm so that the remaining coefficientGravatar Gael Guennebaud2009-08-17
| | | | is real, and make Tridiagonalization use it
* add EIGEN_TRANSFORM_PLUGINGravatar Gael Guennebaud2009-08-17
|
* make HouseholderQR uses the Householder moduleGravatar Gael Guennebaud2009-08-16
|
* bugfix in compute_matrix_flags, optimization in LU,Gravatar Gael Guennebaud2009-08-16
| | | | | improve doc, and workaround aliasing detection in MatrixBase_eval snippet (not very nice but I don't know how to do it in a better way)
* in all decs, make the compute() methods return *thisGravatar Benoit Jacob2009-08-15
| | | | (implements feature request #18)
* rename back MayAliasBit to EvalBeforeAssigningBitGravatar Gael Guennebaud2009-08-16
|
* make SVD reuses applyJacobiGravatar Gael Guennebaud2009-08-16
|
* revert previous change in Quaternion::setFromTwoVectorsGravatar Gael Guennebaud2009-08-15
|
* svd: sort in decreasing order, remove unused codeGravatar Benoit Jacob2009-08-15
|
* add overloads of lazyAssign to detect common aliasing issue withGravatar Gael Guennebaud2009-08-15
| | | | transpose and adjoint
* fix and improve docsGravatar Benoit Jacob2009-08-15
|
* As proposed on the list:Gravatar Gael Guennebaud2009-08-15
| | | | | | | | | - rename EvalBeforeAssignBit to MayAliasBit - make .lazy() remove the MayAliasBit only, and mark it as deprecated - add a NoAlias pseudo expression, and MatrixBase::noalias() function Todo: - we have to decide whether += and -= assume no aliasing by default ? - once we agree on the API: update the Sparse module and the unit tests respectively.
* bugfix in inner-product specialization,Gravatar Gael Guennebaud2009-08-15
| | | | | compilation fix in stable norm, optimize apply householder
* my previous fix was not very goodGravatar Gael Guennebaud2009-08-15
|
* bugfix and compilation fix in ProductBaseGravatar Gael Guennebaud2009-08-15
|
* fix setFromTwoVectors because of the change in sorting of the the singular ↵Gravatar Gael Guennebaud2009-08-15
| | | | values
* fix a couple of warningsGravatar Gael Guennebaud2009-08-15
|
* fix warningGravatar Benoit Jacob2009-08-14
|
* forgot to update thisGravatar Benoit Jacob2009-08-14
|
* as discussed on list: default to align cols, reorganize parameters ↵Gravatar Benoit Jacob2009-08-14
| | | | | | accordingly so that the default corresponds to 0 flag, and implement FullPrecision output (non-default).
* try to support 16 bit platforms... optimistic, but can't hurtGravatar Benoit Jacob2009-08-14
|
* machine_epsilon -> epsilon as wrapper around numeric_traitsGravatar Benoit Jacob2009-08-14
|
* oops bis, I forgot that SelfAdjointEigneSolver directly called the selector...Gravatar Gael Guennebaud2009-08-14
|
* optimize "apply Jacobi" for small sizes, and move it to Jacobi.hGravatar Gael Guennebaud2009-08-14
|
* * remove EIGEN_DONT_INLINE that harm performance for small sizesGravatar Benoit Jacob2009-08-13
| | | | | | | * normalize left Jacobi rotations to avoid having to swap rows * set precision to 2*machine_epsilon instead of machine_epsilon, we lose 1 bit of precision but gain between 10% and 100% speed, plus reduce the risk that some day we hit a bad matrix where it's impossible to approach machine precision
* oops, don't set the precision to -1 !!Gravatar Benoit Jacob2009-08-13
|
* apply Koldo's workaround for MSVC bugGravatar Benoit Jacob2009-08-13
|
* add an optimized "apply in place a rotation in the plane",Gravatar Gael Guennebaud2009-08-13
| | | | | and make Jacobi and SelfAdjointEigenSolver use it => ~ x1.75 speedup for JacobiSVD and x2 for SelfAdjointEigenSolver
* apply change discussed on the list :Gravatar Benoit Jacob2009-08-13
| | | | | * new default precision "-1" means use the current stream precision * otherwise, save and restore the stream precision
* do without an empirical homemade formula that i wasn't comfortable about...Gravatar Benoit Jacob2009-08-12
| | | | turns out it's not needed anymore and removing it seems to only increase the precision
* make jacobi SVD more robust after experimenting with very nasty matrices...Gravatar Benoit Jacob2009-08-12
| | | | | | | it turns out to be better to repeat the jacobi steps on a given (p,q) pair until it is diagonal to machine precision, before going to the next (p,q) pair. it's also an optimization as experiments show that in a majority of cases this allows to find out that the (p,q) pair is already diagonal to machine precision.
* add parentheses; hopefully this solves Koldos MSVC compilation issue...Gravatar Benoit Jacob2009-08-12
|
* finally, the good approach was two-sided Jacobi. Indeed, it allowsGravatar Benoit Jacob2009-08-12
| | | | | | | | | | to guarantee the precision of the output, which is very valuable. Here, we guarantee that the diagonal matrix returned by the SVD is actually diagonal, to machine precision. Performance isn't bad at all at 50% of the current householder SVD performance for a 200x200 matrix (no vectorization) and we have lots of room for improvement.
* add EIGEN_DEBUG_VARGravatar Benoit Jacob2009-08-11
|
* overload operartor* with a ProductBase such that "scalar * (mat * mat)" is ↵Gravatar Gael Guennebaud2009-08-11
| | | | | | optimized as one could naturally expect
* fix issue #36 (missing return *this in Rotation2DGravatar Gael Guennebaud2009-08-11
|
* remove #include Bidiagonalization, and add missing ";"Gravatar Gael Guennebaud2009-08-11
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 04:12:01 +0000