[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [statistics] Release v1.0
From:       Alex Herbert <alex.d.herbert () gmail ! com>
Date:       2022-11-30 13:59:21
Message-ID: CAJxH-uqiig-Wdi-aa_aJa-Z433wFnLu489mKBi4=FD2F=zeyKw () mail ! gmail ! com
[Download RAW message or body]

On Wed, 30 Nov 2022 at 13:44, Gilles Sadowski <gilleseran@gmail.com> wrote:
>
> Hello Alex.

<-- cut -->

> >
> > I think that all outstanding Jira tasks in the distribution package
> > have been addressed for Statistics. The remaining Jira tickets are for
> > items that are not required for a first release. There are many left
> > open from Google Summer of Code (2019). These could be resolved or
> > left as markers for the type of work that is yet to be done on the
> > project. I would recommend closing those that contain no useful
> > information on future work:
> >
> > [...]
>
> +1

Done.

>
> >
> > Other pre-release tasks:
> >
> > 1. There is a recent fix for the Pareto distribution sampler that
> > would require RNG 1.6 to be released. However with no other changes in
> > the RNG codebase I do not think this is required. The current
> > Statistics code fixes the bug by wrapping the input RNG.
>
> So this code (in [Statistics]) will be simplified when v1.6 of [RNG]
> is out?

Yes. It would remove the need for the InvertedRNG inner class that
reverses the output from nextDouble. In the createSampler method:

final UniformRandomProvider wrappedRng = shape >= 1 ? new
InvertedRNG(rng) : rng::nextLong;
return InverseTransformParetoSampler.of(wrappedRng, scale, shape)::sample;

Would revert to the standard:

return InverseTransformParetoSampler.of(rng, scale, shape)::sample;

I could have implemented the same method from RNG in the Pareto
distribution. But this requires a method to transform random bits from
a long to a double in (0, 1]. (and not in [0, 1)). This is out of
scope for statistics so I just used 1.0 - rng.nextDouble() (with the
nextDouble ensured to return in [0, 1)).

I think a release of RNG 1.6 would thus remove 4 lines of executable
code, mainly pass through code in the inner class. The way I have done
the fix means that a release of RNG 1.6 would work exactly the same
way with Statistics 1.0 and any later version of Statistics that drops
the internal class. This is because RNG 1.6 switches from using
nextDouble to nextLong as the source of randomness. The Statistics
inner class just passes the nextLong output directly through. It only
modifies nextDouble.

So Statistics 1.0 with RNG 1.6 would naturally pick up the fix and the
improved performance of doing it correctly using bit manipulations to
adjust the double to the range (0, 1].

>
> >
> > 2. Create a release doc (can be based on the numbers/rng/geometry
> > release docs for the similar multi-module structure).
>
> That would be great.

Done.

I have checked all the javadoc and fixed a few inconsistencies. I will
prepare a RC1 for review.

Alex

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

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic