Dependency on random
#34
Comments
|
Yes, I'm fine with that. I depend on |
|
as you may noted, one can remove
|
|
Awesome, thank you! Yes, that's what we've been using thus far, but if we are to release
|
phadej
added a commit
to phadej/quickcheck
that referenced
this issue
May 28, 2020
splitmix-0.1 dropped dependency on random. But that's a non-issue, as QuickCheck doesn't use any `random` instances of `SMGen`, we only need to implement `RandomGen QCGen` in terms of splitmix combinators Related: haskellari/splitmix#34
vdukhovni
pushed a commit
to vdukhovni/quickcheck
that referenced
this issue
May 29, 2020
splitmix-0.1 dropped dependency on random. But that's a non-issue, as QuickCheck doesn't use any `random` instances of `SMGen`, we only need to implement `RandomGen QCGen` in terms of splitmix combinators Related: haskellari/splitmix#34
|
Done in |
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this issue
Apr 23, 2021
0.1.0.3
* Fix oops bugs in 0.1.0.2
- It's lowercase windows.h. I blame Microsoft docs for using capital
case Windows.h in the
docs. https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocessid
- accidental shiftL vs shiftR mixup for 32-bit generator
initialization. Doesn't affect Linux.
0.1.0.2
* Drop time dependency in favour of handcoded initialization
- On Unix platforms we use /dev/urandom if it exists, otherwise use
gettimeofday, clock and getpid.
- On Windows we use GetCurrentProcessID, GetCurrentThreadId(),
GetTickCount, GetSystemTime and QueryPerformanceCounter.
- On GHCJS use Math.random()
- Using time is a fallback option (e.g. for Hugs).
0.1.0.1
* Add INLINEABLE pragmas to bitmaskWithRejection* functions
* Support GHC-9.0
0.1
* Drop random dependency
unconditionally. haskellari/splitmix#34
0.0.5
* Add nextInteger
* Use smaller range in bitmaskWithRejection32 and 64, when upper bound
is 2^n - 1. This changes generated values when they were on the
boundary.
0.0.4
* Add bitmaskWithRejection32' and bitmaskWithRejection64' which
generate numbers in closed range [0, n]. Unticked variants generate
in closed-open range [0, n).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@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 theSMGenthe default RNG forrandom, in other words, instead of duplicating splitmix algorithm implementation we went fortype StdGen = SMGen. This would, of course, requirerandomto depend onsplitmix, 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.The text was updated successfully, but these errors were encountered: