On Wed, 20 Aug 2014, Marc Glisse wrote:
On Wed, 20 Aug 2014, Christoph Hertzberg wrote:
On 19.08.2014 15:53, Christoph Hertzberg wrote:
On 17.08.2014 19:34, Marc Glisse wrote:
Any comment on this patch?
http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2014/06/msg00012.html
Hi Marc,
sorry I forgot about this thread, so thanks for the reminder.
As no further objections arose to your patch, I'll commit it soon.
One thing that is missing is that only LU decompositions are considered by
your patch.
Actually, a clean solution should somehow share the pivoting code for all
pivoting decompositions. At least for QR and LU the code is very similar
at the moment. Any thoughts?
The codes are similar, but not the same. QR has even more threshold,
precision, isMuchSmallerThan and stuff. Merging those codes requires a
better global understanding of what they do than I have (finding the line
that says "max" and replacing it with "best" is about as far as I looked at
the pivoting code...).
Introducing the score in QR shouldn't be much harder than in the full LU,
as long as we basically ignore the effect on biggest_pivot, the case of
non-zero epsilon, etc.
Maybe I should mention in the doc that when we specialize scores, non-zero
values of epsilon are not supported and biggest_pivot -type functions may
give unexpected results. It may be possible to define a sensible
interaction between scores and non-0 thresholds, but that requires a lot
more thought.
So no, I don't particularly have any idea.
(and I am currently only using LU, somehow every time I tried to use
something else it failed because it required sqrt or some other thing not
available for rationals)
I think adding some documentation somewhere here would be nice:
http://eigen.tuxfamily.org/dox-devel/TopicCustomizingEigen.html#CustomScalarType
I'll write something as soon as the patch is in, so I know what to
document. An example with rationals (minimize the complexity of the pivot)
seems easier than intervals.
I added an example to #CustomScalarType and used the score in
FullPivHouseholderQR. I feel that doing more requires someone who actually
has an idea what the code is supposed to be doing. Refactoring pivots is
almost orthogonal to what I am doing...
Is the attached pair of patches ok?