commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [Math] How fast is fast enough?
Date Sun, 07 Feb 2016 00:52:06 GMT
On 2/6/16 4:34 PM, Benson Margulies wrote:
> 1. I don't understand the source of urgency here. If someone has a new
> algorithm they want to release to the general public, they can put it
> on github. It does not matter very much if a method is sitting in
> Apache (commons) Math on any particular schedule. It's not like adding
> a feature to some platform that has to be integrated to be useful.

It would be great if what we were arguing about was actually
*adding* a *new algorithm* - I would be big +1 to more PRNGs. 
Unfortunately, "the movement" here is about refactoring the
framework that provides the implementations of the algorithms we
already have.  No practical use case or new, better algorithm has
been presented to justify this "movement."  The sad thing is we have
a nice, pluggable framework for PRNGs everywhere in [math} which is
simple and performant.  What really would be an advance is
implementation of new algorithms, which could sit nicely beside the
others that already exist and users could choose to use or not use
them.  Something demonstrably better than the Well generators that
we plug in as defaults in various places could be really useful.  We
could make that change transparently and lots of users would
benefit.  Unfortunately, we are not talking about that.  This is why
I am leaving.  We started [math] 13 years ago aiming to provide
high-quality, well-documented, well-tested implementations of
commonly used standard algorithms.  I am proud of what we have
done.  Now, however, the loudest, most persistent voices are more
interested in fiddling with the APIs rather than researching and
implementing new algorithms or improving the ones we have.  That's
fine; just not interesting to me nor in my opinion in the best
interest of the users.  What they end up with is incompatible change
without material improvement in functionality.  It is natural, I
guess, for components and communities to evolve and that is fine.  I
am sure others will step up to maintain and develop this code.
>  Of
> course, the 'Apache (commons) Math mark of quality' won't mean
> anything if there is a sudden shift to 'movement' as a guiding
> principle, so ironically the victory would be Pyrrhic.
>
> 2. JMH is the current gold standard of microbenchmark measurement. It
> gives meaningful results. If someone wants to claim that they have new
> code that has some particular performance on a micro scale, they
> should be eager to contribute a JMH benchmark; it's not much work.

Big +1 there.  And jmh uses [math]'s stat package.
>
> 3. Apache Math can only come into existence if the board is convinced
> that there is a community prepared to operated according to ASF
> principles. That means finding some way to collegially resolve
> disputes. There's always a trip to the incubator available.

Oh wouldn't that be lovely!

Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message