Live data from Hacker News

A common mistake when NumPy’s RNG with PyTorch

tanelp.github.io

31–40 of 54 posts

Re: A common mistake when NumPy’s RNG with PyTorch

#31
post #17

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.

95% of GitHub repos using NumPy/PyTorch don't get the randomness they intended.

Re: A common mistake when NumPy’s RNG with PyTorch

#32

This 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

It's so obviously clickbait that I wonder if it's meant to be tongue-in-cheek.

Re: A common mistake when NumPy’s RNG with PyTorch

#33

Earlier 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.

Possibly but this is the kind of boilerplate which people tend to ignore, especially when a program is non-trivial. It’s really easy to notice if you’re doing something like `seed_rng(); fork();` but once there’s distance and more than one thing being passed around I’d be surprised if you didn’t find the same pattern, perhaps a bit less common.

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

#34
I 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

#36
post #34

I 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

#37
post #34

I 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.

thanks, that seems to be the answer

Re: A common mistake when NumPy’s RNG with PyTorch

#38
A lot of comments are criticising the frameworks or the developers, but suprisingly almost no one is criticising Python, which remains a language of the early 90ies as far as parallelism is concerned.

A 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

#40
post #29
post #18

Earlier 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.

> does anyone at all train DL models on Windows?

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.

Post reply on HN