commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [MATH] Re: Pivoting QR Decomposition: Take Two!
Date Thu, 06 Oct 2011 22:12:05 GMT
On Thu, Oct 6, 2011 at 1:56 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:

> On Thu, Oct 06, 2011 at 02:56:28PM -0500, Greg Sterijevski wrote:
> > Yes, this application would be similar to the ones you nixed. It would be
> a
> > factory returning an abstract class, with the appropriate methods
> throwing
> > exceptions (like getRank for the non-pivoting version-as Ted mentions in
> a
> > later entry in this blog).
> >
> > As Ted asks, what is the issue with this?
>
> What I'm asking is: What is the issue with 2 concrete classes (and possibly
> an abstract base class, if there is some code to share)?
>

The issue is that the different classes are really an implementation detail
from the user's point of view.  What they care about is rank-revealing or
not.  They don't really care about pivoting except insofar as they know that
is how rank revealing QR is done.

It can be done with multiple classes, but just as java collections and now
guava provide constructors that hide implementation details but expose user
details, I think that this is good practice elsewhere as well.

For example, if you say Maps.newHashMap(), do you *really* care which hash
table implementation you get?


> [As Ted pointed out, the CM design is not based around factories (which is
> fine IMO until proven otherwise); changing that would require a strong
> argument and should lead to a complete revision of the basic layout of the
> library, in order to be consistent.  Maybe for 4.0 :-).]
>

Sure.  Whatever. (checking out)

To stretch the argument, why not create a "UniversalDecomposition" class
> with all the methods in it:
>

Because that is just a straw man argument that isn't directed toward making
things better.  Just because an extreme form isn't right doesn't mean that
moving that direction isn't a good idea.

To paraphrase, I would like to find a minimum of (x-1)^2.  Starting at 0, I
could say that moving to 0.5 is good.  You could say that the value is much
larger at 20 and therefore moving to 0.5 is a bad idea.


>  getCholeskyL()
>  getLuL()
>  getLuU()
>  getLuP()
>  getQrQ()
>  getQrR()
>  getQrH()
>  getSvdU()
>  getSvdS()
>  getSvdV()
>  ...
> and throw "UnsupportedOperationException" as necessary?
>
>
Most of the Java world got past this many years ago.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message