[
https://issues.apache.org/jira/browse/RNG-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107063#comment-18107063
]
Alex Herbert commented on RNG-200:
----------------------------------
Full support for serializing any Object arguments is not required in
JDKRandomBridge. Only the TWO_CMRES_SELECT source has additional arguments and
they are integers. If the TwoCmres generator is updated to include the
identifier of each sub-cycle generator within the saved state then the
JDKRandomBridge can be customised to detect if the source is TWO_CMRES_SELECT
and have a custom construction routine for that generator that reads the
sub-cycle identifiers from the saved state and uses these for the overloaded
constructor. This is strong coupling between the code in the simple package and
core package.
A decoupled solution would require that the RandomSource has more information
that indicates what parameters are required to construct it using the
overloaded factory constructor, e.g. a method to supply a list of constructor
class types:
{code:java}
/**
* Gets the parameter types of the data needed to build the generator using
* {@link #create(Object, Object...)}, or {@code null} if no parameters are
required.
*
* @return the parameter types
*/
public Class<?>[] getArgs(); {code}
The JDKRandomBridge can then convert the initial bytes of the saved state to
the correct argument type and call the overloaded constructor. This conversion
can have a small set of supported types (e.g. initially only int.class). This
will support any future RandomSource that requires constructor arguments. It is
over-engineered for the current codebase which has not added any such
RandomSource in the 10 years since project inception.
> TWO_CMRES_SELECT cannot be serialized within JDKRandomBridge
> ------------------------------------------------------------
>
> Key: RNG-200
> URL: https://issues.apache.org/jira/browse/RNG-200
> Project: Commons RNG
> Issue Type: Bug
> Components: core, simple
> Affects Versions: 1.7
> Reporter: Alex Herbert
> Priority: Minor
>
> The TWO_CMRES_SELECT random source is constructed using a seed and two chosen
> sub-cycle generators. The state of the RNG can be saved and restored using
> the methods of RestorableUniformRandomProvider. This state *does not* include
> the identifiers of the sub-cycle generators. Thus the state can be restored
> to the *same instance* of the RNG where the sub-cycle generators are known.
> It cannot be used to create a new instance of the generator when
> deserializing the state in the JDKRandomBridge.
> The JDKRandomBridge creates a new instance of the random source using:
> {code:java}
> delegate = source.create(); {code}
> This is the no argument factory method of RandomSource:
> {code:java}
> public RestorableUniformRandomProvider create() {code}
> The TWO_CMRES_SELECT generator requires the two sub cycle generators to be
> specified in the overloaded factory method:
> {code:java}
> public RestorableUniformRandomProvider create(Object seed,
> Object... data) {code}
> For example:
> {code:java}
> long seed = 1;
> int subCycle1 = 3;
> int subCycle2 = 8;
> delegate = source.create(seed, subCycle1, subCycle2); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
