> Also, I think that further cleanup is possible (cf. "wantu" and "wantv"
> checks that don't seem very useful).
This is residual from the JAMA code and is not required with our current
interface.
I wonder if we could implement something around this. I can conceive of
cases where users may only want singular values and not left or right
singular vectors, or indeed cases where users have no requirement for one of
the left or right singular vectors.
It might be appropriate to calculate only what is required by a user,
selected at construction, to speed up the implementation? I guess that this
would be at the expense of simplicity, since it would add a constructor and
getU() and getV() would only be supported depending on the construction.
Chris
On 12 August 2011 14:39, Greg Sterijevski <gsterijev...@gmail.com> wrote:
> Thanks! There is an additional method I am moving in. Its the inverse of
> the
> condition number.
>
> public double getInverseConditionNumber() {
> return singularValues[FastMath.min(m,n) - 1] / singularValues[0];
> }
>
> This addition stems from an issue (MATH-602) I submitted awhile back.
> Namely, in cases of rank deficiency the regular condition number will
> become
> undefined. This is not a huge issue, but if you are using condition number
> to choose a matrix in some selection routine (say steppwise regression)
> then
> having a somewhat robust criterion might be helpful.
>
> The patch is sitting in the queue.
>
> -Greg
>
> On Fri, Aug 12, 2011 at 8:16 AM, Gilles Sadowski <
> gil...@harfang.homelinux.org> wrote:
>
> > On Thu, Aug 11, 2011 at 04:31:15PM -0500, Greg Sterijevski wrote:
> > > At least three with some code I checked in last night. The point is
> that
> > > there is no reason to replicate the same thing over and over again.
> >
> > I understand the point.
> > I've replaced those 2 occurrences which I detected (revision 1157083).
> > Let me know the location of the third one.
> >
> > Also, I think that further cleanup is possible (cf. "wantu" and "wantv"
> > checks that don't seem very useful).
> >
> >
> > Regards,
> > Gilles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
