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
