-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Randomness/next(upTo:) vs next(through:) for UXL #122
Comments
Randomness/next(upTo:)
vs next(through:)
for UXL
The current arbitrary integer algorithm borrows the limit; it does not modify the limit like the systems integer algorithms does. Modifying the limit is more expensive in the arbitrary case, so I don't want to do that. Instead, it might be possible to alter the accept-reject loop condition and conditionally modify the result. |
I wouldn't call this invariant important. Random is random, but it would be cute. |
Hm. So I have a solution for this. I just don't think it's very elegant. I like how simple the current algorithm is and I don't think this invariant is important enough to change that. Alternatively, I could consider settling on only one of these methods and modifying the limit before passing it to the chosen method. In that case, the invariant would be with respect to |
There's a cute
Randomness/next(upTo:)
versusnext(through:) -> T
invariant whenT: SystemsInteger
. If we have two deterministic and identical sources of randomness, then these operations return identical results given equivalentRange<T>
andClosedRange<T>
arguments. It would be nice if this invariant also held for arbitrary unsigned integers.The text was updated successfully, but these errors were encountered: