commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [MATH] Re: Pivoting QR Decomposition: Take Two!
Date Thu, 06 Oct 2011 10:21:39 GMT

> >>
> >>What is the group's feeling on factory classes? +1 from me (obviously)
> >>
> >+1 for me, I like factories.
> -0. We used factories and removed most of them. In fact, what we
> removed was when factories are used to hide implementation and only
> an interface and a factory are available to users. This is a
> different cases.
> There are other places too where we still have some factories, even
> in new code (an example would be Region in the geometry package if I
> remember well).

-1 for a factory.
[Note that I haven't thought at all about use-cases (and thus at how a
factory would be best to answer those unspecified needs). Please give
some examples.]

We indeed removed several factories that IMO were an hindrance because they
were hiding important specifics of algorithms. [E.g. there was a root
solvers factory that would return one of the solvers which CM provides. How
is it the role of a library to decide which solver is good for a given
Factories are undisputably good when they generate the *one* correct
implementation (cf. the well-known example of GUI widgets that must
correspond to the chosen "theme" or the current low-level graphics

In CM, there is a factory that creates one or another kind of matrix,
depending on the number of entries. [This seems reasonable but, the
threshold being somewhat arbitrary, I would be interested to know how
many applications rely on this automatic choice of implementation.]

However, in this case, what would a factory bring?
When the user knows what he wants, I much prefer explicit instantiation
because the code clearly shows what class is being used (obviously):
  PivotingQRDecomposition qr = new PivotingQRDecomposition(m);
  QRDecomposition qr = QRDecompositionFactory.create(true);
or (even worse IMHO)
  QRDecomposition = DecompositionFactory.createQRDecomposition(true);
where the boolean parameter is assumed to select whether the "pivoting"
feature is enabled or not. 
IIUC, there are things you can query from a "PivotingQRDecomposition" that
you cannot from the "FastQRDecomposition", then when you get the interface
"QRDecomposition", you've lost these additional features. And if you impose
that the interface contains them, then if you request the "fast"
implementation, and then query the "pivoting" features, what happens?

Also, since each decomposition (LU, SVD, ...) provides different methods
(except the common "getSolver"; see my previous post), it is fairly clear
that a generic "Decomposition" interface would not be useful at all.

I argue again that, at the CM level, there isn't enough context to make a
uniformly right decision.
Applications that would benefit from a factory can of course create them at
their level.

Best regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message