[math] slight refactoring of test framework for discrete ("integer") distributions

[Phil Steitz <ph...@gmail.com>]

I have started improving precision in the reference values used in
discrete distribution tests to address MATH-1037.  It occurred to me
as I was doing this that for most of the Integer distributions, the
following two conditions hold:

0) The cumulative distribution test points are the same as the
density test points.
1) For each test point x_i among the test points x_0, ..., x_n,
every point with non-zero mass below x_i occurs among x_0, ..., x_i-1.

>From 1) it follows that the distribution value (cumulative
probability) at x_i can be obtained by just summing the densities of
the points up to and including it.  So, makeCumulativeTestValues can
just default to an appropriately defined sum over the
makeDensityTestValues array.  To reduce code duplication and reduce
the need to separately compute and maintain distribution reference
values, I think it might therefore be better to

a) Push the following up to IntegerDistributionAbstractTest, so the
method is no longer abstract and has this default impl
public int[] makeCumulativeTestPoints() {
        return makeDensityTestPoints();
 }

b) Also provide a default impl in IntegerDistributionAbstratTest for
makeCumulativeTestValues that computes the sum above.

There are a couple of downsides to this, so I want to get some
feedback before making the change.

* Loss of significance errors could in theory impact the precision
of the sum (I have not played with this, but I suspect it is not an
issue for the data we have now)
* It is a little awkward to state the invariant above that the
default impl depends on.  I guess it would go in the javadoc for the
default impl. 

Over the years people have been able to figure out fairly
successfully how to use the distribution test framework, but it does
require a little thought and I don't want to make it any more arcane
/ hard to figure out than it is already, so I would appreciate some
feedback on this.  Maybe the right solution is to go ahead with this
but add some separate documentation somewhere (either class javadoc
or the Programmer's Guide) on how the framework works.

Phil




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