You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@phadej would you be ok removing dependency on random completely? Not right now, of course, but once we get to the final implementation of the new random, which is not far at all on the horizon. Reason why I am asking is because we decided it would be best if we just made the SMGen the default RNG for random, in other words, instead of duplicating splitmix algorithm implementation we went for type StdGen = SMGen. This would, of course, require random to depend on splitmix, not the other way around. We could of course just inline the implementation from your package as mentioned here idontgetoutmuch/random#86, but it really seems like an unnecessary duplication of code.
Yes, that's what we've been using thus far, but if we are to release random on hackage that depends on splitmix the optional flag approach will no work
one can remove random dependency already today by supplying -random flag choice.
Activity
phadej commentedon Apr 14, 2020
Yes, I'm fine with that. I depend on
randomonly to provideRandomGeninstance, so there aren't any technical problems with that.phadej commentedon Apr 14, 2020
as you may noted, one can remove
randomdependency already today by supplying-randomflag choice.lehins commentedon Apr 14, 2020
Awesome, thank you!
Yes, that's what we've been using thus far, but if we are to release
randomon hackage that depends onsplitmixthe optional flag approach will no workUse splitmix-0.0.5 nextInteger, and support splitmix-0.1
Use splitmix-0.0.5 nextInteger, and support splitmix-0.1
phadej commentedon May 29, 2020
Done in
splitmix-0.1Update to splitmix-0.1.0.3
Update to splitmix-0.1.0.3
Update to splitmix-0.1.0.3