Skip to content
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

Open
oscbyspro opened this issue Oct 28, 2024 · 3 comments
Open

Randomness/next(upTo:) vs next(through:) for UXL #122

oscbyspro opened this issue Oct 28, 2024 · 3 comments
Labels
brrr such code, much wow maybe to do, or not to do?

Comments

@oscbyspro
Copy link
Owner

oscbyspro commented Oct 28, 2024

There's a cute Randomness/next(upTo:) versus next(through:) -> T invariant when T: SystemsInteger. If we have two deterministic and identical sources of randomness, then these operations return identical results given equivalent Range<T> and ClosedRange<T> arguments. It would be nice if this invariant also held for arbitrary unsigned integers.

@oscbyspro oscbyspro added the brrr such code, much wow label Oct 28, 2024
@oscbyspro oscbyspro changed the title Randomness/next(upTo:) vs next(through:) for UXL Randomness/next(upTo:) vs next(through:) for UXL Oct 28, 2024
@oscbyspro
Copy link
Owner Author

oscbyspro commented Oct 28, 2024

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.

@oscbyspro oscbyspro added the maybe to do, or not to do? label Oct 28, 2024
@oscbyspro
Copy link
Owner Author

oscbyspro commented Oct 28, 2024

I wouldn't call this invariant important. Random is random, but it would be cute.

@oscbyspro
Copy link
Owner Author

oscbyspro commented Oct 29, 2024

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 BinaryInteger.random(...) instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
brrr such code, much wow maybe to do, or not to do?
Projects
None yet
Development

No branches or pull requests

1 participant