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

Migrate from math/rand to math/rand/v2 #6648

Open
antoninbas opened this issue Aug 30, 2024 · 12 comments
Open

Migrate from math/rand to math/rand/v2 #6648

antoninbas opened this issue Aug 30, 2024 · 12 comments
Labels
good first issue Good for newcomers kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@antoninbas
Copy link
Contributor

Once #6644 is addressed and the repository has migrated to Go 1.23, we should replace all usages of the math/rand package with math/rand/v2.
math/rand/v2 provides a better API and includes various optimizations. AFAIK, there is no downside to migrating to the new version.
See https://tip.golang.org/doc/go1.22#math_rand_v2 and https://go.dev/blog/randv2 for more information.

@antoninbas antoninbas added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. good first issue Good for newcomers priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. labels Aug 30, 2024
@kushal9897
Copy link

I will work on this issue once the repository has migrated to Go 1.23.

@kushal9897
Copy link

Could you please assign this issue to me? I'd love to contribute. Thank you!

@antoninbas
Copy link
Contributor Author

@kushal9897 #6647 has been merged, feel free to work on this

@kushal9897
Copy link

@antoninbas Should 'Math/rand' change everywhere or just in a specific file?

@antoninbas
Copy link
Contributor Author

we should replace all usages of the math/rand package with math/rand/v2

This was referenced Sep 10, 2024
@kushal9897
Copy link

@antoninbas can you please describe more about this issue, please

@antoninbas
Copy link
Contributor Author

@kushal9897 I think the issue is self-explanatory, but I also have provided guidance in your existing PR (#6674), so I am not sure what extra information you require. If you no longer have time to work on this issue, please let me know and I can unassign you.

@kushal9897
Copy link

i am working on it

@kushal9897
Copy link

@antoninbas Sorry, I am unable to make changes in PR #6674. I've submitted a new PR with the required updates. Could you please review and accept the new one? Thank you!

@Insomniac2904
Copy link

Insomniac2904 commented Nov 16, 2024

Hey @antoninbas I am new to open-source and I was working on this issue. Could you tell me what should I change nameRand := rand.New(rand.NewSource(seed)) with? I could not find any solution online. If I do like this : nameRand :=rand.New(rand.NewPCG(seed1,seed2)) what should be the value for seed 2?
Thanks.

@antoninbas
Copy link
Contributor Author

@Insomniac2904 Please read https://go.dev/blog/randv2

Go 1.20 automatically seeded the top-level generator

I believe that for most uses cases, the global generator is sufficient. A local one should only be needed in certain cases, like if repeatability is needed. When you see rand.New(rand.NewSource(time.Now().UnixNano())), repeatability is not needed.

If repeatability is needed, one can use NewPCG(0, 0), or more generally NewPCG(seed, seed). NewPCG(seed1, seed2), with 2 different uint64 values used as a seeds, is also fine. But if this is for tests, probably the simpler the better.

@antoninbas
Copy link
Contributor Author

It seems @ravjot07 is actively working on this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

No branches or pull requests

3 participants