[RNG] Testing RNG (Was: ... packaging)

[Gilles <gi...@harfang.homelinux.org>]

On Fri, 20 Jul 2018 09:29:50 -0600, Gary Gregory wrote:
> TL;DR: -1
>
> I do not normally validate an RC one module at a time. Why would you 
> do
> that?

Who asks?

> Also 'install' already does 'package', otherwise, there would be 
> nothing to
> install, unless you do weird stuff in a POM.

Normally (at least for me), it used to work (i.e. compile, test,
generate all reports) with
  $ mvn -Pcommons-rng-examples site site:stage

I added "package install" in case (?) the new CP and build/release
plugins do "weird stuff" (no idea what that means!). :-)

> Running 'mvn clean install' on Java 8 gives me:
>
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR]   ContinuousSamplerParametricTest.testSampling:53->check:127
> Ahrens-Dieter Exponential deviate
> [rng=org.apache.commons.rng.core.source32.MersenneTwister]: Too many
> failures for sample size = 20000 (3 out of 50 tests failed, 
> chi2=[33.911,
> 21.682999999999996, 23.565]
> [ERROR]   ContinuousSamplerParametricTest.testSampling:53->check:127
> Uniform deviate
> [rng=org.apache.commons.rng.core.source64.MersenneTwister64]: Too 
> many
> failures for sample size = 20000 (3 out of 50 tests failed, 
> chi2=[22.896,
> 22.143, 30.629000000000005]
> [INFO]
> [ERROR] Tests run: 77, Failures: 2, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
> 
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Commons RNG 1.1 ............................. SUCCESS [
> 12.216 s]
> [INFO] Apache Commons RNG Client API ...................... SUCCESS [
> 4.348 s]
> [INFO] Apache Commons RNG Core ............................ SUCCESS [
> 18.538 s]
> [INFO] Apache Commons RNG Simple .......................... SUCCESS [
> 12.227 s]
> [INFO] Apache Commons RNG Sampling ........................ FAILURE 
> [01:24
> min]
> [INFO] Apache Commons RNG (full distribution) 1.1 ......... SKIPPED
> [INFO]
> 
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> 
> ------------------------------------------------------------------------
> [INFO] Total time: 02:12 min
> [INFO] Finished at: 2018-07-20T09:28:10-06:00
> [INFO]
> 
> ------------------------------------------------------------------------
>
> We need a better way to test :-(

As mentioned previously, you'd just need to recall the command
until those unit tests eventually pass.
That they sometimes fail is inherent to the functionality.
But it *may* be that they fail too often, if the unit test
is not tolerant enough (cf. "3 out of 50 tests failed" in
the output). Currently we are on the safe side: being too
lax might hide a fault in the underlying generator.

> -1 anyway, because the src zip contains the site-contents folder:
>
> commons-rng-1.1-src/commons-rng-examples/examples-jmh/site-content/ 
> and
> other site-content folders.
>
> There is no need to bloat the mirrors.
>
> Is this really a Java 6 component, did I see that right?

Yes.

> Wow! ;-) We should
> move this up to Java 8 after 1.1

There is nothing needed from JDK 7+ in order to add RNG
implementations (only basic operations are used, and the
best implementations are currently less than a dozen lines).
[For 1.0, there was a discussion to bump to Java 7, in order
to use the "multiple exceptions catch" syntax, and it was not
deemed a sufficient reason.]

> to make it at least semi-attractive to new
> devs.

As opposed to more extent components, AFAICT there is
nothing syntax-wise to be gained from JDK 8+.
Only JPMS (thus JDK 9+) could be a good reason (thus for
application developers, not developers of the component
itself).

Perhaps: if there is the willingness to add a stream API.
[I'd recall that, at the time, the argument was to stay
close to the "java.util.Random" API and not loose a single
percent of speed!]
Even so, streams could easily come as wrappers, defined in
another module targetted to a more recent JDK, without
touching the core implementations.

Gilles

> Gary
>
>>> [...]


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