Open curiousleo opened 4 years ago
I opened an issue on splitmix about it: https://github.com/phadej/splitmix/issues/34 I don't see a good reason to inline the splitmix
code into random
, except only to break the cycle, so in the end it will be @phadej decision on which way the dependency arrow points.
Great, Oleg is ok with dropping dependency on random
, so there is no need to duplicate the full implementation. See comment https://github.com/phadej/splitmix/issues/34#issuecomment-613462577
Context
Currently there is a dependency on the
splitmix
package: https://github.com/idontgetoutmuch/random/blob/a5c70bdbc2ffd1616fef07c43170a9a172f2afac/random.cabal#L38By default,
splitmix
depends onrandom
. This dependency can be severed by setting a flag. That is currently necessary, otherwise cabal and stack fail to buildrandom
due to a dependency circle: https://github.com/idontgetoutmuch/random/blob/a5c70bdbc2ffd1616fef07c43170a9a172f2afac/cabal.project#L2 https://github.com/idontgetoutmuch/random/blob/a5c70bdbc2ffd1616fef07c43170a9a172f2afac/stack.yaml#L42-L44Alternative
The alternative to depending on the
splitmix
package is to inline the SplitMix implementation.Discussion
Pull in
splitmix
dependency pros:splitmix
,random
can easily benefit from them.Pull in
splitmix
dependency cons:random
toFalse
is required; without it there will be a circular dependency. Flags are supported by cabal and stack, but it looks like e.g.cabal2nix
does not support them. Q: would users need to set this flag too in order to userandom
?Copy algorithm pros:
splitmix
and thus no need to set any flags.splitmix
' dependencies are not necessary for our purposes and can be removed from the dependency tree.Copy algorithm cons:
random
does not automatically benefit from updates tosplitmix
. However, note that the algorithm is now stable - the last change to the PRNG itself occurred in May 2018: https://github.com/phadej/splitmix/pull/9.