Hi.
> > > 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.
OK, then the pivoting implementation should preferrably be in a class named
"RankRevealingQRDecomposition"?
> 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.
I agree. The question is to identify the "interesting" specifics. In this
case, if "getRank()" is interesting, it should not be the result of an
implementation detail that, if not present, would generate an exception.
> For example, if you say Maps.newHashMap(), do you *really* care which hash
> table implementation you get?
No.
But this case is not the same since the user will choose one or the other
implementation based on his knowledge that he will be able to obtain, or
not, something from "getRank()".
Having
* one class per implementation, or
* 2 implementations in the same class and selecting one or the other by
passing a boolean,
is exactly the same for the user.
For the developer, I contend that it is tidier to separate the algorithms
along class boundaries.
>
> > [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.
I'd be interested by a pointer.
I'm all for CM to be "state-of-the-art" but it should be done in an orderly
fashion lest someone dropping in some months/years from now will not be able
to figure out what were the guiding principles in the design.
If the design is coherent, it will be easier to modify it globally to adopt
a new paradigm. On the other hand, if the library uses mixed coding styles,
it will become extremely difficult to figure out why one style was used here
and another there, and if it was done on purpose or just on a whim of the
programmer.
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
