As often I’m impressed by the quality of all of this. The amount of thinking that went into this, this excellent written blog post. I love the Go blog.
Evolving the Go Standard Library with math/rand/v2
31–40 of 45 posts
Re: Evolving the Go Standard Library with math/rand/v2
#32Nice - I wish .NET would be more willing to condemn chunks of the standard library and replace them with something better!
At least .NET is very capable of allowing you to support third party libraries. Heck, even ASP .NET Core isn't built-in anymore, you get it through NuGet. So you're not stuck with the standard libraries.
Re: Evolving the Go Standard Library with math/rand/v2
#33Earlier quoted context omitted.
“Don’t you guys have internet?” What happened to batteries-included support?
ASP isnt included OOTB anymore, so if you want to do web dev in .NET you have to install it, they decoupled a ton of things from the core of the language.
Re: Evolving the Go Standard Library with math/rand/v2
#34Earlier quoted context omitted.
ASP isnt included OOTB anymore, so if you want to do web dev in .NET you have to install it, they decoupled a ton of things from the core of the language.
You don’t get it through NuGet. You get it by specifying the sdk type in the project. https://learn.microsoft.com/en-us/dotnet/core/project-sdk/ov...
https://www.nuget.org/profiles/aspnet
Some projects listed were last updated in 2022.
Re: Evolving the Go Standard Library with math/rand/v2
#35> Ideally, the v2 package should be able to do everything the v1 package could do, and when v2 is released, the v1 package should be rewritten to be a thin wrapper around v2. And even more ideally, as many v1 usages should be automatically fixed as possible by `go fix` or similar tools. Allowing this to all user packages would be a major improvement over the status quo.
We have plans to get there. https://github.com/golang/go/issues/32816
Re: Evolving the Go Standard Library with math/rand/v2
#36As often I’m impressed by the quality of all of this. The amount of thinking that went into this, this excellent written blog post. I love the Go blog.
Agreed. I admire the clarity of Cox's writing, as much as his thoughtful restraint on adding new features to the language.
My favorite is https://research.swtch.com/qart (see also: https://spinroot.com/pico/pjw.html)
Re: Evolving the Go Standard Library with math/rand/v2
#37> In 2018, Daniel Lemire found an algorithm that avoids the divisions nearly all the time (see also his 2019 blog post). In math/rand, adopting Lemire’s algorithm would make Intn(1000) 20-30% faster... I recently found a super simple algorithm that appears to produce a number in the interval [0,N] with a branchless expression with a single multiplication in an extended number size. (Sorry I don't have a reference.) S…
Re: Evolving the Go Standard Library with math/rand/v2
#38> In 2018, Daniel Lemire found an algorithm that avoids the divisions nearly all the time (see also his 2019 blog post). In math/rand, adopting Lemire’s algorithm would make Intn(1000) 20-30% faster... I recently found a super simple algorithm that appears to produce a number in the interval [0,N] with a branchless expression with a single multiplication in an extended number size. (Sorry I don't have a reference.) S…
Re: Evolving the Go Standard Library with math/rand/v2
#39Earlier quoted context omitted.
> (As a simpler example, try converting 4 equally likely values into 3.) No, but you can convert a RNG that emits 4 equally likely values into an RNG that emits 3 equally likely values. Just - anytime the RNG returns 4, try again. Here's a fun puzzle / annoying interview question: You have a biased coin. You can flip it as often as you want, but heads and tails are not equally likely. Without figuring out the bias of…
My guess after a few glasses of wine and thinking on it for a few minutes: Flip twice. If both flips are the same discard the result. Output 0 for TH, 1 for HT.
The followup is this: That approach only uses about 50% of your coin flips. The other 50% are discarded. How would you improve the efficiency?
Re: Evolving the Go Standard Library with math/rand/v2
#40Earlier quoted context omitted.
At least .NET is very capable of allowing you to support third party libraries. Heck, even ASP .NET Core isn't built-in anymore, you get it through NuGet. So you're not stuck with the standard libraries.
But when you're replacing, like, much of the standard library, you have to be a bit sad about all the interop work that falls on the user. It should instead fall on the makers of the bad standard library.
People have no issue using third party libraries in other languages to get more done than the OOTB libraries.