Earlier quoted context omitted.
Better title? Over 95% of GitHub repos using NumPy and PyTorch aren't getting the random numbers they think they are.
Probably over the HN Title character limit.
A common mistake when NumPy’s RNG with PyTorch
31–40 of 54 posts
Re: A common mistake when NumPy’s RNG with PyTorch
#32This is probably because I never read these kinds of blogposts but this is one of the most flagrantly clickbait titles I've ever seen. Like the article doesn't even suggest ditching numpy in favor of jax or some kind of other hot take (which would at least warrant such a bombastic title) it literally just presents one instance in which you might be making a mistake when using numpy's rng (not even something more uniq…
Maybe the intent is for it to be read as "If you're using pytorch and numpy, it's _very_ likely you're making this mistake", but the effect is still that the headline is clickbait
Re: A common mistake when NumPy’s RNG with PyTorch
#33Earlier quoted context omitted.
The solution you suggest is irrelevant to the issue mentioned in the article. Even if you use np.random.RandomState, or any other "explicit RNG state", that state will still be copied in the fork() call. The post just stresses that one should be careful when using random states and multiprocessing, so you should either reseed after forking or using multiprocess/multithread-aware RNG API.
I believe the point is that the error will be more obvious if the state is passed around explicitly.
Fundamentally, there two problems: fork() is a performance trick to try to do setup only once and seeding an RNG is a type of setup which isn’t intuitively obvious can’t be optimized that way; and if most people learn from a tutorial or quick start this is exactly the kind of important but non core issue people omit or ignore in that context.
Re: A common mistake when NumPy’s RNG with PyTorch
#34Re: A common mistake when NumPy’s RNG with PyTorch
#35Re: A common mistake when NumPy’s RNG with PyTorch
#36I notice that the web page of this article is beautifully justified to two sides instead of left alignment, and there is hyphen in breaking lines. Does anyone know how to achieve this in web page? text-align: justify seems to produce inferior results than this page, e.g. rivers in text.
Re: A common mistake when NumPy’s RNG with PyTorch
#37I notice that the web page of this article is beautifully justified to two sides instead of left alignment, and there is hyphen in breaking lines. Does anyone know how to achieve this in web page? text-align: justify seems to produce inferior results than this page, e.g. rivers in text.
`hypens: auto` is probably it. It allows words to be split with a hypen at the browser's discretion.
Re: A common mistake when NumPy’s RNG with PyTorch
#38A bit like Stockholm syndrome - "Python doesn't do threading" is so ingrained in its users (and I'm a user) minds that it's not even questioned as a potential source of problems.
(Noone said it's easy to do. That's why language developers and implementers are a special breed even today.)
Re: A common mistake when NumPy’s RNG with PyTorch
#39Re: A common mistake when NumPy’s RNG with PyTorch
#40Earlier quoted context omitted.
It’s even slightly more subtle than that. Python multiprocessing doesn’t use fork on Windows. It starts a new process and so shouldn’t be affected by this. So to trigger this you need to have num_processes != 0 on your DataLoader and be running on a non-Windows platform.
I get the desire to be pedantic, but does anyone at all train DL models on Windows? (barring toy projects for fun and perhaps debugging) The same can be said about num_workers > 0. You _have to_ fork worker threads unless you train something super tiny like MNIST and you load the whole dataset on GPU.
Yes. My last job was at a financial shop that was all Windows. They were doing ML with Python on Windows. Azure has boxes available for this.