On Tue, Oct 4, 2011 at 8:28 AM, Gary Gregory wrote:
> * LANG-532 -> Should be resolved for 3.0.2; or we should remove the code
> added.
>
> I'm feeling towards -1 for 3.0.2, Adding [collections] code feels of scope
> for a x.x.x maintenance release and needs more debate. I'd prefer to release
> a
>
> 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().
>
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
On Tue, Oct 04, 2011 at 06:05:12PM -0700, Phil Steitz wrote:
> On 10/4/11 4:26 PM, Gilles Sadowski wrote:
> >>> I have been leaving the standard exception advertisements alone as I
> >>> s/MathRuntimeException.createXxException/new MathXxException, but I
> >>> notice others are changing the @throws
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
On 5 October 2011 02:05, Phil Steitz wrote:
> On 10/4/11 4:26 PM, Gilles Sadowski wrote:
I have been leaving the standard exception advertisements alone as I
s/MathRuntimeException.createXxException/new MathXxException, but I
notice others are changing the @throws to declare the
>>>
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
22 matches
Mail list logo
