5 ms·

Two vital information on .Net PRNG : - It is not thread-safe (and might start outputting a serie of 0 when called in parallel) - There is a bug (acknowledged

Two vital information on .Net PRNG : - It is not thread-safe (and might start outputting a serie of 0 when called in parallel) - There is a bug (acknowledged by Microsoft but not fixed for backward compatibility reasons) in the implementation meaning that the generator has an abnormally short period and is, overall, less random looking.

adrianN 8y ago
I'm really bummed out over the fact that you can't change the way a random number generator generates numbers because apparently people depend on the exact algorithm.
- OskarS 8y ago
  It does make some sense. Lets say you're making a game with a procedural world (e.g. something like Minecraft) which the player explores and makes changes to. Instead of storing the entire (potentially infinite) world, you just store the world seed and the changes players make. In that case, if the algorithm underlying the PRNG changes, the entire game would break. There's enough scenarios like this that making a change to a PRNG algorithm is a very dangerous and breaking change. People rely on the fact that, given the same seed, you get the same sequence of values.
  - iainmerrick 8y ago
    You should use your own PRNG in that case. I understand not wanting to change the implementation now, but users should never have assumed it would be stable in the first place.
    - OskarS 8y ago
      I mean, yeah. You probably should. But it's entirely reasonable of a game developer to say "I'm not an expert in random numbers, but Microsoft has lots of smart engineers, I'm sure they did their research and provided a good implementation". The actual answer is that you shouldn't just provide a default "Random" class, you should provide a more general class with a pluggable algorithm.
      - whyever 8y ago
        > I'm sure they did their research and provided a good implementation Apparently their implementation has several shortcomings.
      - iainmerrick 8y ago
        No, that’s not reasonable at all. You’d be assuming not only that the implementation is exactly what you want, but also that it will be identical on all platforms and will never change. In practice for .NET it sounds like that’s actually correct -- the bad implementation will never be fixed. That seems like a bad thing.
        setr 8y ago
        Whats the point of providing a seed() function if the algorithm can change from under your feet, for any given implementation? In your scenario the only way to have seed() is through a custom implementation, because any implementation may haves bugs or inconsistencies, that may be fixed at any time. And only your own implementation will stay stable and sane And this is true for all backward-compatibility concerns: you’ll have a bug, or a poor syntax decision, or a crappy api, thats required to be there because of downstream concerns. If you keep breaking people’s programs to improve the language, people will either eventually stop updating, or stop using the language altogether, because it becomes a massive PITA to get any new features; do it enough and people will say fuck it, you cant be trusted to stay stable, I’ll write it myself. And eventually a library will come along that promises stability, and you’ll be back in the same boat. Stability is a feature. And judging from how languages treat stability today, and how one of microsofts major reasons for success was its almost obscene adherence to backwards compatibility, it is an important feature. The cost is of course that these problems persist, and eventually build up untill someone forks, or a major version increments. But theres a reason that perfect is the enemy of good. Breaking programs arbitrarily to fix bugs/issues slaughters downstream productivity.
        iainmerrick 8y ago
        I think that is sometimes right and sometimes wrong. It’s not consistent enough to elevate to a principle. Macs were incredible for backwards-compatibility back in the 80s and 90s, as good as PCs if not better. Games from 1985 would run happily in System 7 and MacOS 8. It didn’t help them win against the PC. Since the return of Steve Jobs, Apple have become increasingly aggressive about killing off old “obsolete” hardware and software features. As a Mac or iOS developer it can be incredibly frustrating, constantly having to jump through new hoops just to be permitted to stay on the platform. But that doesn’t seem to have hurt Apple’s business success in the slightest. To answer your initial question-- Whats the point of providing a seed() function if the algorithm can change from under your feet, for any given implementation? I was imagining that the algorithm would be stable across runs but permitted to change across major library updates, say. But I forgot there are two parts to it. One is seed(), the other is the no-args constructor that uses the system clock but no additional randomness. Can we at least agree that that one should be fixed? It’s hard to see how any users even could have a hard dependency on that specific implementation. Like, code that absolutely requires independent Random objects created in the same millisecond to have the same seed? Do you see a big risk in breaking clients like that, for the benefit of improving randomness for everybody else?
    - dsp1234 8y ago
      users should never have assumed it would be stable in the first place. It's not an assumption. It's directly in the documentation. "If the same seed is used for separate Random objects, they will generate the same series of random numbers."[0] [0] - https://docs.microsoft.com/en-us/dotnet/api/system.random https://docs.microsoft.com/en-us/dotnet/api/system.random
      - iainmerrick 8y ago
        Read just a little further: “However, note that Random objects in processes running under different versions of the .NET Framework may return different series of random numbers even if they're instantiated with identical seed values.”
  - carlmr 8y ago
    Another use case would be you simulating a physical system with random noise. You get an error for a certain noise sequence. You might want to be able to get the same random sequence back.
    - iainmerrick 8y ago
      But does it need to be reproducible for all time, on all platforms?
      - eropple 8y ago
        Basically, yes. If they wanted to incorporate Math.NET Numerics (which is pretty good, I have used it before for a lot of stuff) into the standard library alongside the existing RNG architecture, I'd be down for that, but I expect the same seeds to play for me the same sequences everywhere because if they don't simulations, games, etc. will break. Eventually you can deprecate the existing System.Random and turn its implementation into (using Math.NET Numerics terminology) a separate RandomSource, and eventually remove System.Random, but you can't change the contract of System.Random.
  - adrianN 8y ago
    That actually makes sense and I have used PRNGs in that way myself. I should have thought of that.
whyever 8y ago
I don't understand why the poor implementation of the default constructor (seeding the RNG with the time) cannot be changed. It is not reproduceable anyway, so why not initialize with entropy requested from the OS?
- guhidalg 8y ago
  Who says it’s not reproducible if you’ve chosen to mess with time ;)
piceas 8y ago
also - An instantiated identical seed can return different sequences on different framework versions [0]. (Also discussed in the article) Once upon a time that was inconvenient for me. I found Math.NET Numerics to be a good replacement. Also check out threadlocal for thread-safety. [0] https://docs.microsoft.com/en-us/dotnet/api/system.random https://docs.microsoft.com/en-us/dotnet/api/system.random https://stackoverflow.com/questions/19270507/correct-way-to-use-random-in-multithread-application https://stackoverflow.com/questions/19270507/correct-way-to-... https://numerics.mathdotnet.com/ https://numerics.mathdotnet.com/
dmarlow 8y ago
Why not do PRGN2 or PRNGEx, like they've done with other functions? Maybe they have and I'm just blowing hot air.

adrianN 8y ago

I'm really bummed out over the fact that you can't change the way a random number generator generates numbers because apparently people depend on the exact algorithm.

OskarS 8y ago
It does make some sense. Lets say you're making a game with a procedural world (e.g. something like Minecraft) which the player explores and makes changes to. Instead of storing the entire (potentially infinite) world, you just store the world seed and the changes players make. In that case, if the algorithm underlying the PRNG changes, the entire game would break. There's enough scenarios like this that making a change to a PRNG algorithm is a very dangerous and breaking change. People rely on the fact that, given the same seed, you get the same sequence of values.
- iainmerrick 8y ago
  You should use your own PRNG in that case. I understand not wanting to change the implementation now, but users should never have assumed it would be stable in the first place.
  - OskarS 8y ago
    I mean, yeah. You probably should. But it's entirely reasonable of a game developer to say "I'm not an expert in random numbers, but Microsoft has lots of smart engineers, I'm sure they did their research and provided a good implementation". The actual answer is that you shouldn't just provide a default "Random" class, you should provide a more general class with a pluggable algorithm.
    - whyever 8y ago
      > I'm sure they did their research and provided a good implementation Apparently their implementation has several shortcomings.
    - iainmerrick 8y ago
      No, that’s not reasonable at all. You’d be assuming not only that the implementation is exactly what you want, but also that it will be identical on all platforms and will never change. In practice for .NET it sounds like that’s actually correct -- the bad implementation will never be fixed. That seems like a bad thing.
      - setr 8y ago
        Whats the point of providing a seed() function if the algorithm can change from under your feet, for any given implementation? In your scenario the only way to have seed() is through a custom implementation, because any implementation may haves bugs or inconsistencies, that may be fixed at any time. And only your own implementation will stay stable and sane And this is true for all backward-compatibility concerns: you’ll have a bug, or a poor syntax decision, or a crappy api, thats required to be there because of downstream concerns. If you keep breaking people’s programs to improve the language, people will either eventually stop updating, or stop using the language altogether, because it becomes a massive PITA to get any new features; do it enough and people will say fuck it, you cant be trusted to stay stable, I’ll write it myself. And eventually a library will come along that promises stability, and you’ll be back in the same boat. Stability is a feature. And judging from how languages treat stability today, and how one of microsofts major reasons for success was its almost obscene adherence to backwards compatibility, it is an important feature. The cost is of course that these problems persist, and eventually build up untill someone forks, or a major version increments. But theres a reason that perfect is the enemy of good. Breaking programs arbitrarily to fix bugs/issues slaughters downstream productivity.
        iainmerrick 8y ago
        I think that is sometimes right and sometimes wrong. It’s not consistent enough to elevate to a principle. Macs were incredible for backwards-compatibility back in the 80s and 90s, as good as PCs if not better. Games from 1985 would run happily in System 7 and MacOS 8. It didn’t help them win against the PC. Since the return of Steve Jobs, Apple have become increasingly aggressive about killing off old “obsolete” hardware and software features. As a Mac or iOS developer it can be incredibly frustrating, constantly having to jump through new hoops just to be permitted to stay on the platform. But that doesn’t seem to have hurt Apple’s business success in the slightest. To answer your initial question-- Whats the point of providing a seed() function if the algorithm can change from under your feet, for any given implementation? I was imagining that the algorithm would be stable across runs but permitted to change across major library updates, say. But I forgot there are two parts to it. One is seed(), the other is the no-args constructor that uses the system clock but no additional randomness. Can we at least agree that that one should be fixed? It’s hard to see how any users even could have a hard dependency on that specific implementation. Like, code that absolutely requires independent Random objects created in the same millisecond to have the same seed? Do you see a big risk in breaking clients like that, for the benefit of improving randomness for everybody else?
  - dsp1234 8y ago
    users should never have assumed it would be stable in the first place. It's not an assumption. It's directly in the documentation. "If the same seed is used for separate Random objects, they will generate the same series of random numbers."[0] [0] - https://docs.microsoft.com/en-us/dotnet/api/system.random https://docs.microsoft.com/en-us/dotnet/api/system.random
    - iainmerrick 8y ago
      Read just a little further: “However, note that Random objects in processes running under different versions of the .NET Framework may return different series of random numbers even if they're instantiated with identical seed values.”
- carlmr 8y ago
  Another use case would be you simulating a physical system with random noise. You get an error for a certain noise sequence. You might want to be able to get the same random sequence back.
  - iainmerrick 8y ago
    But does it need to be reproducible for all time, on all platforms?
    - eropple 8y ago
      Basically, yes. If they wanted to incorporate Math.NET Numerics (which is pretty good, I have used it before for a lot of stuff) into the standard library alongside the existing RNG architecture, I'd be down for that, but I expect the same seeds to play for me the same sequences everywhere because if they don't simulations, games, etc. will break. Eventually you can deprecate the existing System.Random and turn its implementation into (using Math.NET Numerics terminology) a separate RandomSource, and eventually remove System.Random, but you can't change the contract of System.Random.
- adrianN 8y ago
  That actually makes sense and I have used PRNGs in that way myself. I should have thought of that.

whyever 8y ago

I don't understand why the poor implementation of the default constructor (seeding the RNG with the time) cannot be changed. It is not reproduceable anyway, so why not initialize with entropy requested from the OS?

guhidalg 8y ago
Who says it’s not reproducible if you’ve chosen to mess with time ;)

piceas 8y ago

also - An instantiated identical seed can return different sequences on different framework versions [0]. (Also discussed in the article) Once upon a time that was inconvenient for me. I found Math.NET Numerics to be a good replacement. Also check out threadlocal for thread-safety. [0] https://docs.microsoft.com/en-us/dotnet/api/system.random https://docs.microsoft.com/en-us/dotnet/api/system.random https://stackoverflow.com/questions/19270507/correct-way-to-use-random-in-multithread-application https://stackoverflow.com/questions/19270507/correct-way-to-... https://numerics.mathdotnet.com/ https://numerics.mathdotnet.com/

dmarlow 8y ago

Why not do PRGN2 or PRNGEx, like they've done with other functions? Maybe they have and I'm just blowing hot air.