[ 
https://issues.apache.org/jira/browse/RNG-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315341#comment-17315341
 ] 

Alex Herbert commented on RNG-127:
----------------------------------

{quote}wouldn't a "wrapper" approach be more appropriate?
{quote}
A wrapper to bridge between the two jumpable APIs fits with the current support 
for Random. Note that due to the lack of a copy method a wrapper cannot fully 
support the JumpableGenerator interface.

I think that changes should initially be restricted to a module supporting that 
version of the JDK.  So this rules out extending the interfaces. This could be 
a module with adaptors. It could also have service implementations for the 
current algorithms to allow them to be loaded by the service provider API which 
will load the UniformRandomProvider using an appropriate wrapper. This would 
allow use of classic algorithms not provided by the JDK for example the 
MersenneTwister and Well family of generators. This would require a solution to 
the lack of a copy method. It can be done using the save/restore state 
functionality by creating a new generator with a dummy seed then restoring the 
state to make a copy. This would have performance issues over a pure clone for 
some generators that self-seed during construction.


> Assess future compatibility with JEP 356: Enhanced Pseudo-Random Number 
> Generators 
> -----------------------------------------------------------------------------------
>
>                 Key: RNG-127
>                 URL: https://issues.apache.org/jira/browse/RNG-127
>             Project: Commons RNG
>          Issue Type: Task
>          Components: client-api
>    Affects Versions: 1.3
>            Reporter: Alex Herbert
>            Priority: Minor
>
> JEP 356 specifies an enhancement to the random number generators. This is 
> targeted to JDK 17.
> [JEP 356: Enhanced Pseudo-Random Number 
> Generators|https://openjdk.java.net/jeps/356]
> The enhancement will add interfaces to the JDK for random number generation:
>  * SplittableRandomGenerator extends RandomGenerator and also provides
>  methods named split and splits. Splittability allows the user to spawn a new 
> RandomGenerator from an existing RandomGenerator that will generally produce 
> statistically independent results.
>  * JumpableRandomGenerator extends RandomGenerator and also provides
>  methods named jump and jumps. Jumpability allows a user to jump ahead a 
> moderate number of draws.
>  * LeapableRandomGenerator extends RandomGenerator and also provides
>  methods named leap and leaps. Leapability allows a user to jump ahead a 
> large number of draws.
>  * ArbitrarilyJumpableRandomGenerator extends LeapableRandomGenerator and 
> also provides additional variations of jump and jumps that allow an arbitrary 
> jump distance to be specified.
> The specification describes the development of abstract classes that would 
> allow different algorithms to be easily implemented by developers and used 
> with a Java application through a common interface. This would replicate the 
> functionality of the Common RNG API and core modules within the JDK.
> The JDK interfaces should be compared with the current client API in Commons 
> RNG with the aim to assess:
>  # Compatibility
>  # Potential to back-port functionality
> JEP 356 also mentions the implementation of the LXM family of RNGs and a 
> change to the algorithm used by SplittableRandom to address two weaknesses 
> identified in 2016. These could be included in the current codebase pending 
> license compatibility checks.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to