Re: [eigen] Machine precision<> too coarse

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2009/2/3 Keir Mierle <mierle@xxxxxxxxx>:
> If coarser comparisons are needed, then they should be available as
> different names. Machine precision should indeed be e for which 1 + e = 1.
[....]
> Certainly. But then there should be a different function available for
> machine epsilon.

My point was that, unless we want to enter in very precise precision
analysis of each operation, the machine epsilon is not useful for us,
hence there is no need to reserve a name for it.

> The precision suggested here is machine eps * size * max matrix element. In
> this case that roughly matches the full pivoting precision ( 1000 * 2e-16 *
> ~1.0 = 2e-13).

There are many factors that will make any such formula work only for a
specific kind of operation. So if we start relying on such formulas,
we have to make a different analysis for every different operation. We
can then no longer rely on a single isApprox() method with default
precision, we must compute the correct precision everytime. I think
that's a lot of trouble and personnally I don't really feel that I
have the expertise to do that quickly (since it's not worth becoming a
major time consumer IMO).

The current solution consists in saying that instead of doing a
separate analysis for every different situation, we take always the
same precision, that's rough enough for the worst cases.

A good hint that our precision works well, is that the LU exact rank
computation works even for large matrices. If our precision was too
coarse, the rank() method would return a too low number (because
numbers would too quickly be declared diagonal). If our precision was
too tight, similarly, rank() would return a too high number.

So the precision can sure be tweaked (i can believe that the current
values can be made a bit smaller), but just make sure that the unit
tests still work. In that respect I need to make test_lu test once a
really large matrix.

Cheers,
Benoit