On 10/23/13 8:03 PM, Ted Dunning wrote:
> On Wed, Oct 23, 2013 at 8:33 PM, Sean Owen <sro...@gmail.com> wrote:
>
>> it feels a little funny just
>> because then we should have similar logic for other decompositions. I
>> think I remember the LU one stops early, always.
>>
> The stopping early is definitely an option with QR.  With LU, it isn't so
> clear.
>

Sorry to be a little late to the party on this.  We should keep in
mind that "singularity threshold" means different things in the
different contexts discussed above (as Ted and others have
mentioned).  It should be provided to constructors that need it and
clearly documented (cf LU).  I like adding a boolean to Eigen so the
user can decide whether or not to stop.  I agree with Thomas that
adding a parameter to getSolver makes sense in cases where there is
no instance field (or even possible where there is, so the solver
can override).   What really needs to be improved is the
documentation on what exactly "threshold" means in each case where
it is used.

So basically, I am saying

0) get rid of constructor argument (i.e. depecate) where it is only
used by getSolver (QR), adding it there.  Look at all of them to see
if it makes sense to provide this parameter.
1) work around the overloading issue in EigenDecomposiiton by adding
the boolean flag (which is useful anyway)
2) crisp up doco throughout to make it clear exactly what thresholds
mean

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to