[math] Re: SingularValueDecompositionImpl

[Phil Steitz <ph...@gmail.com>]

On 8/10/11 3:51 PM, Greg Sterijevski wrote:
> Hello All,
>
> In the SVD class I notice:
>
> FastMath.max(m, n)
>
> all over the place. Since these values are known when the constructor is
> called and are final, would anyone object to making the result a private
> instance variable?

+1

(note change in subject line :)

Phil
> -Greg
>


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

Re: [math] Re: SingularValueDecompositionImpl

[Gilles Sadowski <gi...@harfang.homelinux.org>]

Hi.

> > 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 removed them in r1157281.

> 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.

Then such cases should be the object of a new feature request.
Implementation can be postponed to 3.1.

> 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.

One should be sure that the speed-up is worth it.
Another option would be to compute the requested data at first access, like
what is done for "getUT()" and "getVT()".

Can you test?


Best,
Gilles

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

Re: [math] Re: SingularValueDecompositionImpl

[Chris Nix <ch...@gmail.com>]

> 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 <gs...@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 <
> gilles@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Re: [math] Re: SingularValueDecompositionImpl

[Greg Sterijevski <gs...@gmail.com>]

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 <
gilles@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [math] Re: SingularValueDecompositionImpl

[Gilles Sadowski <gi...@harfang.homelinux.org>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [math] Re: SingularValueDecompositionImpl

[Greg Sterijevski <gs...@gmail.com>]

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.

-Greg

On Thu, Aug 11, 2011 at 6:33 AM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:

> > > In the SVD class I notice:
> > >
> > > FastMath.max(m, n)
> > >
> > > all over the place. Since these values are known when the constructor
> is
> > > called and are final, would anyone object to making the result a
> private
> > > instance variable?
>
> I see only 2 places: lines 557 and 569.
> [In one of them it is "Math.max(m, n)".]
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [math] Re: SingularValueDecompositionImpl

[Gilles Sadowski <gi...@harfang.homelinux.org>]

> > In the SVD class I notice:
> >
> > FastMath.max(m, n)
> >
> > all over the place. Since these values are known when the constructor is
> > called and are final, would anyone object to making the result a private
> > instance variable?

I see only 2 places: lines 557 and 569.
[In one of them it is "Math.max(m, n)".]


Gilles

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