I published the website: http://commons.apache.org/sandbox/commons-monitoring/
As it's more than a simple commons component, Incubator sounds a good
idea. I can take care of that.
But for personal reasons, I have a bit of traveling (and won't be
connected a lot) this week and next week.
So I
Not sure when we have decided to use fluido skin for our components but
since I've planned work on this, it serves as a nice show case :-)
2013/8/20 Olivier Lamy ol...@apache.org
I published the website:
http://commons.apache.org/sandbox/commons-monitoring/
As it's more than a simple
well to be honest default common theme looks very old and it would be hard
to sell it for something recent ;)
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn:
and usually French folks like to start/do Revolution :-)
On 20 August 2013 20:36, Romain Manni-Bucau rmannibu...@gmail.com wrote:
well to be honest default common theme looks very old and it would be hard
to sell it for something recent ;)
*Romain Manni-Bucau*
*Twitter: @rmannibucau
you forgot to mention for a better world ;)
*Romain Manni-Bucau*
*Twitter: @rmannibucau https://twitter.com/rmannibucau*
*Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
Hi all,
Sorry for the delay. I'll try switching all of the least squares package
to the new/seperable API and post the results to github. From there we
can review, discuss and then decide if it makes sense to switch the rest
of the optimizers.
On 08/15/2013 09:12 AM, Konstantin Berlin wrote:
On Tue, 20 Aug 2013 08:54:59 -0400, Evan Ward wrote:
Hi all,
Sorry for the delay. I'll try switching all of the least squares
package
to the new/seperable API and post the results to github. From there
we
can review, discuss and then decide if it makes sense to switch the
rest
of the
We already discussed that some time ago.
Let's not mix different issues. Removing the handling of weights can dealt
with later.
I disagree, please address my points in regards to this, rather than
saying a generalizing statement.
Having weights be included makes it harder to implement a
On Tue, Aug 20, 2013 at 8:54 AM, Evan Ward evan.w...@nrl.navy.mil wrote:
Hi all,
Sorry for the delay. I'll try switching all of the least squares package
to the new/seperable API and post the results to github. From there we
can review, discuss and then decide if it makes sense to switch the
On Tue, 20 Aug 2013 10:38:02 -0400, Konstantin Berlin wrote:
We already discussed that some time ago.
Let's not mix different issues. Removing the handling of weights can
dealt
with later.
I disagree, please address my points in regards to this, rather than
saying a generalizing statement.
The monte carlo approach I developed for 2-sample Kolmogorov-Smirnov
tests converges too slowly to be practical. I suspect full
enumeration of n - m partitions of n + m will actually be faster for
small m + n. To do this, I need to enumerate combinations. I have
implemented a fast,
My 2c worth. It seems like there is a general bottleneck. A lot of ideas
don't get used because there is a hurdle that people have to make change
that satisfy all code requirements like tests/reuse of blocks etc. This
makes for a larger than necessary hurdle for people to contribute.
Looks like
I think it belongs in stat.inference. That is where all the tests are.
-Ajo
On Tue, Aug 20, 2013 at 8:51 AM, Phil Steitz phil.ste...@gmail.com wrote:
The monte carlo approach I developed for 2-sample Kolmogorov-Smirnov
tests converges too slowly to be practical. I suspect full
enumeration
On 8/20/13 12:09 PM, Ajo Fod wrote:
I think it belongs in stat.inference. That is where all the tests are.
Sorry, I should have been more clear. I intend to put
KolmogorovSmirnovTest in stat.inference. I agree it belongs there.
What I am puzzling over is where to put the combinations
I feel like it belongs in a separate class in utils.
-Ajo
On Tue, Aug 20, 2013 at 12:24 PM, Phil Steitz phil.ste...@gmail.com wrote:
On 8/20/13 12:09 PM, Ajo Fod wrote:
I think it belongs in stat.inference. That is where all the tests are.
Sorry, I should have been more clear. I intend
On the point of tests: Considering tests a hurdle is the wrong way to look
at it. Tests are the foundation I can confidently build on and change code.
Gary
On Tue, Aug 20, 2013 at 3:07 PM, Ajo Fod ajo@gmail.com wrote:
My 2c worth. It seems like there is a general bottleneck. A lot of
There was the java5 hack and the java6 version.
IMO the java5 one should be dropped (if we haven't done so yet) but
IIRC the java6 version is not really finished.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
Hm. Not sure either but I would vote for the update.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 20 August 2013 22:38, Torsten Curdt tcu...@vafer.org wrote:
There was the java5 hack and the java6 version.
IMO the java5 one should be dropped (if we haven't done so yet) but
If it works, why don't we keep it?
IIRC the java6 version is not really finished.
Also, it needs Java 1.6+.
There was the java5 hack and the java6 version.
IMO the java5 one should be dropped (if we haven't done so yet) but
If it works, why don't we keep it?
Well, it uses private API and does not work beyond java5
IIRC the java6 version is not really finished.
Also, it needs Java 1.6+.
Indeed
I agree that in general test are necessary to ensure that something useful
is being accomplished by the submitted code as I'd mentioned in my mail.
I admire the rigour of tests in CM. There was one case where I didn't know
what needs be tested and I didn't see the point in taking it further since
On 20 August 2013 22:52, Torsten Curdt tcu...@vafer.org wrote:
There was the java5 hack and the java6 version.
IMO the java5 one should be dropped (if we haven't done so yet) but
If it works, why don't we keep it?
Well, it uses private API and does not work beyond java5
Ah, OK. It seems to
Continue test if possible; use Java 1.5
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 108
X-Continuum-Project-Name: Apache Commons JCI
Online report :
Well, it would be nice to have the official java compiler API (jsr199)
used and implemented but...
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On Tue, 20 Aug 2013 08:51:30 -0700, Phil Steitz wrote:
The monte carlo approach I developed for 2-sample Kolmogorov-Smirnov
tests converges too slowly to be practical. I suspect full
enumeration of n - m partitions of n + m will actually be faster for
small m + n. To do this, I need to
On Tue, 20 Aug 2013 14:55:51 -0700, Ajo Fod wrote:
I agree that in general test are necessary to ensure that something
useful
is being accomplished by the submitted code as I'd mentioned in my
mail.
I admire the rigour of tests in CM. There was one case where I didn't
know
what needs be
On 8/20/13 6:04 PM, Gilles wrote:
On Tue, 20 Aug 2013 08:51:30 -0700, Phil Steitz wrote:
The monte carlo approach I developed for 2-sample Kolmogorov-Smirnov
tests converges too slowly to be practical. I suspect full
enumeration of n - m partitions of n + m will actually be faster for
small
[...]
ArithmeticUtils seems appropriate.
But what is returned by the iterator is arrays and there is no
arithmetic going on. One thing I did think of was cutting out the
binomial coefficients from ArithmeticUtils and creating a
Combinatorics or CombinatoricsUtils class within utils.
That
28 matches
Mail list logo
