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).
> > >
On Thu, Oct 06, 2011 at 07:52:55PM -0500, Greg Sterijevski wrote:
> If you really think about, all of the decomposition classes should be
> handled by factories. The decompositions all seem to occur in the
> constructor. Everything else is derived from those results, so one could
> argue that the a
On Thu, Oct 6, 2011 at 9:13 PM, Phil Steitz wrote:
> Lets a) stop top-posting (Gilles has asked politely a couple of times now)
> and b) stay focused on solving the problems we actually have. We could
> endlessly debate refactoring approaches.
Sorry about the top posting, I am big culprit here
Lets a) stop top-posting (Gilles has asked politely a couple of times now) and
b) stay focused on solving the problems we actually have. We could endlessly
debate refactoring approaches. Or we could fix the stuff blocking 3.0 and get
a release out. Let's do that.
Phil
On Oct 6, 2011, at 6
Yeah... but this is a rough neighborhood for folk like you and me.
On Thu, Oct 6, 2011 at 5:52 PM, Greg Sterijevski wrote:
> If you really think about, all of the decomposition classes should be
> handled by factories. The decompositions all seem to occur in the
> constructor. Everything else is
If you really think about, all of the decomposition classes should be
handled by factories. The decompositions all seem to occur in the
constructor. Everything else is derived from those results, so one could
argue that the actual decomposition code could be written very procedurally
and put into t
On Thu, Oct 6, 2011 at 1:56 PM, Gilles Sadowski <
gil...@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
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
>
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?
On
Actually, you can easily get all the information at least in degenerate
form.
The two cases are:
- getPivot() ... the identity permutation can be returned
- getRank() ... it is reasonable to throw an exception stating that rank
is not available (UnsupportedOperationException, in particul
Why were these removed? Was it because the alternative implementations
weren't different enough?
On Thu, Oct 6, 2011 at 12:47 AM, Luc Maisonobe wrote:
> Le 06/10/2011 04:04, Sébastien Brisard a écrit :
>
>>
>>> What is the group's feeling on factory classes? +1 from me (obviously)
>>>
>>> +1 fo
Hello.
> >>
> >>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 a
Le 06/10/2011 04:04, Sébastien Brisard a écrit :
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 interf
>
> What is the group's feeling on factory classes? +1 from me (obviously)
>
+1 for me, I like factories.
Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apa
+1 from me as well. They are a lot of what makes guava so nice to use.
On Wed, Oct 5, 2011 at 5:24 PM, Greg Sterijevski wrote:
> What is the group's feeling on factory classes? +1 from me (obviously)
>
> On Wed, Oct 5, 2011 at 7:14 PM, Ted Dunning wrote:
>
> > I think that a factory style is fi
What is the group's feeling on factory classes? +1 from me (obviously)
On Wed, Oct 5, 2011 at 7:14 PM, Ted Dunning wrote:
> I think that a factory style is fine. Sadly, CM uses constructor style a
> lot and it may be hard to change that expectation. I suppose that the QRD
> constructor can cal
I think that a factory style is fine. Sadly, CM uses constructor style a
lot and it may be hard to change that expectation. I suppose that the QRD
constructor can call some other factory and just delegate to the results.
Looks ugly but keeps the constructor style. If losing the constructor
styl
I am sympathetic to this point of view [one class two algorithms-Ted's
point], but it seems like a step into the C world. Could we not accomplish
the same through some factory method? We can have two classes, but the user
might only get a reference to the abstract base. The other reason is that
the
Actually, I think it really would be nicer for the user to have one class
that internally decides which implementation to use. The user doesn't see
this as two classes. They see it as a single operation (QR decomposition)
that might have a little different behavior (default slow and featureful,
o
Hi.
> Sounds like it would be nice to have both implementations in the same class
> with a "usePivoting(boolean)" method to select which is used. I would
> recommend pivoting as the default since it gives fewer surprises and more
> diagnostic information to the naive user.
>
> Except for the ext
Sounds like it would be nice to have both implementations in the same class
with a "usePivoting(boolean)" method to select which is used. I would
recommend pivoting as the default since it gives fewer surprises and more
diagnostic information to the naive user.
Except for the extra indexing costs
Le 05/10/2011 18:02, Gilles Sadowski a écrit :
On Wed, Oct 05, 2011 at 10:18:19AM -0500, Greg Sterijevski wrote:
Hi Gilles,
There are currently [at least] two qr decompositions in existence in cm.
There is QRDecomposition in package linear and there is embedded in
LevenbergMarquardtOptimizer th
On Wed, Oct 05, 2011 at 10:18:19AM -0500, Greg Sterijevski wrote:
> Hi Gilles,
>
> There are currently [at least] two qr decompositions in existence in cm.
> There is QRDecomposition in package linear and there is embedded in
> LevenbergMarquardtOptimizer the guts of a pivoting QR decomposition. S
Hi Gilles,
There are currently [at least] two qr decompositions in existence in cm.
There is QRDecomposition in package linear and there is embedded in
LevenbergMarquardtOptimizer the guts of a pivoting QR decomposition. So
adding a PivotingQRDecomposition class in linear would initially push that
On Wed, Oct 05, 2011 at 08:46:55AM -0500, Greg Sterijevski wrote:
> Hi Gilles,
>
> The class passes all current tests for QRDecomposition. Are you suggesting I
> rip out the QRDecomposition from OLSMultipleRegression...etc and then make
> sure there are no test failures? Or are you suggestion a ne
Chris,
I hope that this isn't stepping on your toes. I was a bit concerned about
that.
-Greg
On Wed, Oct 5, 2011 at 2:34 AM, Chris Nix wrote:
> Greg,
>
> Apologies that I've not had more time on this, I started a new job that
> doesn't afford it at the moment, :(.
>
> I would say that a single
Yes, in the interest of brevity I left out the fact that rank is calculated
as well. This is exactly Luc's implementation from Marquardt-Levenberg.
Is this what you are talking about with the cryptic 'all'?
On Wed, Oct 5, 2011 at 7:20 AM, Ted Dunning wrote:
> All.
>
> On Wed, Oct 5, 2011 at 12:
Hi Gilles,
The class passes all current tests for QRDecomposition. Are you suggesting I
rip out the QRDecomposition from OLSMultipleRegression...etc and then make
sure there are no test failures? Or are you suggestion a new set of tests?
-Greg
On Wed, Oct 5, 2011 at 5:16 AM, Gilles Sadowski <
gi
All.
On Wed, Oct 5, 2011 at 12:34 AM, Chris Nix wrote:
> Additionally, any pivoting QRDecomposition class should also have a
> getRank() method since it is after all 'rank-revealing' and in most (or
> all?) cases it would be more efficient than
> SingularValueDecomposition.getRank().
>
Hi.
> > A while back I was interested in being able to do pivoting qr
> > decomposition. I noticed that Chris Nix submitted a patch, but he indicated
> > that he had more work to do (testing and filling in functionality). In the
> > discussion around this, Luc suggested that I look at the QR decom
Greg,
Apologies that I've not had more time on this, I started a new job that
doesn't afford it at the moment, :(.
I would say that a single implementation, with or without pivoting, makes
sense to save confusion. Your clearer code would be a good choice for
maintainability.
One possible word o
My apologies! Forgot to tag the subject line.
On Tue, Oct 4, 2011 at 8:35 PM, Greg Sterijevski wrote:
> Hello all,
>
> A while back I was interested in being able to do pivoting qr
> decomposition. I noticed that Chris Nix submitted a patch, but he indicated
> that he had more work to do (testing
Hello all,
A while back I was interested in being able to do pivoting qr decomposition.
I noticed that Chris Nix submitted a patch, but he indicated that he had
more work to do (testing and filling in functionality). In the discussion
around this, Luc suggested that I look at the QR decomposition
33 matches
Mail list logo
