On 9/9/11 7:31 AM, Gilles Sadowski wrote:
> Hi.
>
>>> On Thu, Sep 08, 2011 at 10:27:00AM -0500, Greg Sterijevski wrote:
>>>> Could you be contaminating the cross product matrix when you do your
>>>> accumulation? I noticed one of the utility classes has methods for doing
>>>> safe accumulations. I know that this was part of the problem when I was
>>>> trying to estimate the Wampler data with the MillerRegression. Just a
>>>> thought...
>>> To make sure, I've tried replacing the "sum" calculation in "getCovariances"
>>> with one using "linearCombination for "MathUtils" but it still fails, so it
>>> seems that the (default) threshold is too small, and I need to be able to
>>> change it.
>> Could be the best thing to do here is to make the
>> DecompositionSolver pluggable
> That's what I tried to do a couple of hours ago ;-)
> I.e. I thought that we could have
>
> public double[][] getCovariances(DecompositionSolver solver) {
> // ...
> }
>
> But that won't work with the current design because the solver is an inner
> class of the various "...Decomposition" classes. And not a static one
> because it needs to access the results of the decomposition stored in the
> enclosing class. [Or did I miss something?]
Yeah, sorry, you are right this does not quite work. Another
logical possibility is to define an interface to be implemented by
the decomposition impls to support making the decomposition
algorithm pluggable in situations like this where you really just
want a solver factory. This interface could consist of the static
fectory method:
static DecompositionSolver getSolver(RealMatrix, singularityThreshold)
Note that for this to work, we would have to agree to add a
singularityThreshold constructor parameter for each of the
decomposition impls. The problem with that is that, as discussed on
other threads, the thresholds mean different things for different
decomposition algorithms.
I guess the simplest, for the present problem, is just to leave it
hard-coded to LU, but add a version of getCovariances that takes a
threshold argument.
>
>> (maybe just for the LMOptimizer, but
>> with hooks in the base class)?
> A more flexible "getCovariances" should not be restricted to a single
> optimizer. In fact, currently, I extend "AbstractLeastSquaresOptimizer"
> directly, just to retrieve the covariance matrix; the optimum is not
> computed by a subclass of it. [In the unit test which started this thread,
> the optimum is known (thus: no optimization at all); the next step will be
> to compute an optimum with an optimizer that does not use derivatives (e.g.
> "SimplexOptimizer") but the covariance matrix must still be computed at the
> solution found by that optimizer.]
Yes, that would be the most flexible.
Phil
>
>> That way you could provide an LU
>> solver with whatever threshold you want or choose among the others.
>> Do you know if the jTj matrix you end up trying to invert is
>> analytically singular (like the one in the testNonInvertible test
>> case for LMOptimizer)?
> No, I don't know. But if it is, then there must be a bug somewhere, I think
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
