Dominic, if you want to remove yourself from maintainer hood that's cool. I'm keen on finishing up my random v2 release which is a much improved breaking Change. I spent part of my holiday this year working on it. Dominic: I'm confused and surprised by your email after we had a one hour phone chat about this topic last week. I'm disappointed you are still raising concerns I addressed and explained to you last week. Random v2 is in flight. You are welcome to stop being involved. On Tue, Jan 24, 2017 at 10:19 AM Adam Bergmark wrote:

On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz wrote:

I wanted to give an update on the status of random numbers in Haskell.

1. It is well known that the random number generator package

https://hackage.haskell.org/package/random gives unexpected

results.

2. Most people do *not* use it. I believe

https://hackage.haskell.org/package/mwc-random is a popular choice

but developers are free to use e.g. Mersenne Twister, PCG

(Permuted Congruential Generator), TF (ThreeFish) and many others.

3. Approximately 2 years, I made a proposal to replace the algorithm

within random (https://hackage.haskell.org/package/random) with

that used by tf-random

(https://hackage.haskell.org/package/tf-random) which is used by

QuickCheck. In summary, the response to this was that someone

should do more research with the result that nothing happened.

4. In the meantime, random

(https://hackage.haskell.org/package/random) is *no longer* a core

library. It's just a library with the same status as

e.g. mwc-random. However, it has one difference: it uses the name

for its module: "System.Random". Other RNGs use

"System.Random.MWC", "System.Random.PCG", "System.Random.Mersenne"

etc.

As a maintainer of random

(https://hackage.haskell.org/package/random), my proposal now is to

deprecate all of it.

I am not clear what the policy is on namespace usage. Could every RNG

use the module name "System.Random"? Or is this somehow reserved? If

the latter then I propose that *nothing* uses this name and that all

RNGs should add a suffix indicating which algorithm they use.

They *could* use the same namespace but I don't recommend it. If someone depends on two of these packages they would have to use PackageImports. Tools such as doctest break if a package db has module conflicts, even if only one of the packages is listed as a dependency.

Cheers, Adam

I note that the Haskell Platform contains tf-random so users of this

will still be able to generate (better) random numbers.

If someone comes along in the future, as I hope they do, and

implements e.g. Guy Steele's splitmix algorithm then this can occupy

the name "System.Random.Splitmix" and have the package name

"random-splitmix".

The advantages of doing this are:

1. Neophyte (and experienced) Haskellers do not accidentally use an

RNG which gives unexpected results.

2. No-one will any longer be able to write blogs or papers about this

embarrassing aspect of Haskell.

I believe the co-maintainer of random

(https://hackage.haskell.org/package/random), Carter Schonwald, has a

different view on this matter but it is best he speaks for himself

rather than me imperfectly trying to reflect his thinking.

Dominic Steinitz

dominic@steinitz.org

http://idontgetoutmuch.wordpress.com

_______________________________________________

Libraries mailing list

Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________

Libraries mailing list

Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Carter, I obviously didn’t explain myself very well. We can decouple removing the “bad” RNG from the replacement of it with a “good” RNG. As I thought I said, any new RNG should have the same status as every other RNG and then people can choose; there is no “blessed” RNG. It seems simple (to me at any rate) to decouple these. More power to your elbow on creating an RNG but I don’t think there should be anything “official” about it. I’ll say it again: I don’t think there should be a random v2 but a random-foobar where foobar is your algorithm. What do you see sub-optimal about deprecating something that is clearly broken? I believe I have done my bit for the Haskell Community in trying to resolve what is a tedious situation. I suggest we await the view of the Core Libraries Committee assuming they still see this as part of their scope and take it from there. Dominic.

On 24 Jan 2017, at 15:33, Carter Schonwald wrote:

Dominic, if you want to remove yourself from maintainer hood that's cool.

I'm keen on finishing up my random v2 release which is a much improved breaking Change.

I spent part of my holiday this year working on it.

Dominic: I'm confused and surprised by your email after we had a one hour phone chat about this topic last week.

I'm disappointed you are still raising concerns I addressed and explained to you last week.

Random v2 is in flight. You are welcome to stop being involved.

On Tue, Jan 24, 2017 at 10:19 AM Adam Bergmark mailto:adam@bergmark.nl> wrote: On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz mailto:dominic@steinitz.org> wrote: I wanted to give an update on the status of random numbers in Haskell.

1. It is well known that the random number generator package

https://hackage.haskell.org/package/random https://hackage.haskell.org/package/random gives unexpected

results.

2. Most people do *not* use it. I believe

https://hackage.haskell.org/package/mwc-random https://hackage.haskell.org/package/mwc-random is a popular choice

but developers are free to use e.g. Mersenne Twister, PCG

(Permuted Congruential Generator), TF (ThreeFish) and many others.

3. Approximately 2 years, I made a proposal to replace the algorithm

within random (https://hackage.haskell.org/package/random https://hackage.haskell.org/package/random) with

that used by tf-random

(https://hackage.haskell.org/package/tf-random https://hackage.haskell.org/package/tf-random) which is used by

QuickCheck. In summary, the response to this was that someone

should do more research with the result that nothing happened.

4. In the meantime, random

(https://hackage.haskell.org/package/random https://hackage.haskell.org/package/random) is *no longer* a core

library. It's just a library with the same status as

e.g. mwc-random. However, it has one difference: it uses the name

for its module: "System.Random". Other RNGs use

"System.Random.MWC", "System.Random.PCG", "System.Random.Mersenne"

etc.

As a maintainer of random

(https://hackage.haskell.org/package/random https://hackage.haskell.org/package/random), my proposal now is to

deprecate all of it.

I am not clear what the policy is on namespace usage. Could every RNG

use the module name "System.Random"? Or is this somehow reserved? If

the latter then I propose that *nothing* uses this name and that all

RNGs should add a suffix indicating which algorithm they use.

They *could* use the same namespace but I don't recommend it. If someone depends on two of these packages they would have to use PackageImports. Tools such as doctest break if a package db has module conflicts, even if only one of the packages is listed as a dependency.

Cheers, Adam

I note that the Haskell Platform contains tf-random so users of this

will still be able to generate (better) random numbers.

If someone comes along in the future, as I hope they do, and

implements e.g. Guy Steele's splitmix algorithm then this can occupy

the name "System.Random.Splitmix" and have the package name

"random-splitmix".

The advantages of doing this are:

1. Neophyte (and experienced) Haskellers do not accidentally use an

RNG which gives unexpected results.

2. No-one will any longer be able to write blogs or papers about this

embarrassing aspect of Haskell.

I believe the co-maintainer of random

(https://hackage.haskell.org/package/random https://hackage.haskell.org/package/random), Carter Schonwald, has a

different view on this matter but it is best he speaks for himself

rather than me imperfectly trying to reflect his thinking.

Dominic Steinitz

dominic@steinitz.org mailto:dominic@steinitz.org

http://idontgetoutmuch.wordpress.com http://idontgetoutmuch.wordpress.com/

_______________________________________________

Libraries mailing list

Libraries@haskell.org mailto:Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________

Libraries mailing list

Libraries@haskell.org mailto:Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Dominic Steinitz dominic@steinitz.org http://idontgetoutmuch.wordpress.com

Carter, can you outline how random v2 compares to v1? Thanks, Tom

El 24 ene 2017, a las 10:05, Carter Schonwald escribió:

This is not a core library or blessed libraries issue. This is a communication issue. You don't want to be involved in the v2 work. That's fine.

...

On Tue, Jan 24, 2017 at 10:55 AM wrote: Carter,

I obviously didn’t explain myself very well. We can decouple removing the “bad” RNG from the replacement of it with a “good” RNG. As I thought I said, any new RNG should have the same status as every other RNG and then people can choose; there is no “blessed” RNG. It seems simple (to me at any rate) to decouple these.

More power to your elbow on creating an RNG but I don’t think there should be anything “official” about it. I’ll say it again: I don’t think there should be a random v2 but a random-foobar where foobar is your algorithm.

What do you see sub-optimal about deprecating something that is clearly broken?

I believe I have done my bit for the Haskell Community in trying to resolve what is a tedious situation. I suggest we await the view of the Core Libraries Committee assuming they still see this as part of their scope and take it from there.

Dominic.

...

On 24 Jan 2017, at 15:33, Carter Schonwald wrote:

Dominic, if you want to remove yourself from maintainer hood that's cool.

I'm keen on finishing up my random v2 release which is a much improved breaking Change.

I spent part of my holiday this year working on it.

Dominic: I'm confused and surprised by your email after we had a one hour phone chat about this topic last week.

I'm disappointed you are still raising concerns I addressed and explained to you last week.

Random v2 is in flight. You are welcome to stop being involved.

On Tue, Jan 24, 2017 at 10:19 AM Adam Bergmark wrote: On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz wrote: I wanted to give an update on the status of random numbers in Haskell.

1. It is well known that the random number generator package

https://hackage.haskell.org/package/random gives unexpected

results.

2. Most people do *not* use it. I believe

https://hackage.haskell.org/package/mwc-random is a popular choice

but developers are free to use e.g. Mersenne Twister, PCG

(Permuted Congruential Generator), TF (ThreeFish) and many others.

3. Approximately 2 years, I made a proposal to replace the algorithm

within random (https://hackage.haskell.org/package/random) with

that used by tf-random

(https://hackage.haskell.org/package/tf-random) which is used by

QuickCheck. In summary, the response to this was that someone

should do more research with the result that nothing happened.

4. In the meantime, random

(https://hackage.haskell.org/package/random) is *no longer* a core

library. It's just a library with the same status as

e.g. mwc-random. However, it has one difference: it uses the name

for its module: "System.Random". Other RNGs use

"System.Random.MWC", "System.Random.PCG", "System.Random.Mersenne"

etc.

As a maintainer of random

(https://hackage.haskell.org/package/random), my proposal now is to

deprecate all of it.

I am not clear what the policy is on namespace usage. Could every RNG

use the module name "System.Random"? Or is this somehow reserved? If

the latter then I propose that *nothing* uses this name and that all

RNGs should add a suffix indicating which algorithm they use.

They *could* use the same namespace but I don't recommend it. If someone depends on two of these packages they would have to use PackageImports. Tools such as doctest break if a package db has module conflicts, even if only one of the packages is listed as a dependency.

Cheers, Adam

I note that the Haskell Platform contains tf-random so users of this

will still be able to generate (better) random numbers.

If someone comes along in the future, as I hope they do, and

implements e.g. Guy Steele's splitmix algorithm then this can occupy

the name "System.Random.Splitmix" and have the package name

"random-splitmix".

The advantages of doing this are:

1. Neophyte (and experienced) Haskellers do not accidentally use an

RNG which gives unexpected results.

2. No-one will any longer be able to write blogs or papers about this

embarrassing aspect of Haskell.

I believe the co-maintainer of random

(https://hackage.haskell.org/package/random), Carter Schonwald, has a

different view on this matter but it is best he speaks for himself

rather than me imperfectly trying to reflect his thinking.

Dominic Steinitz

dominic@steinitz.org

http://idontgetoutmuch.wordpress.com

_______________________________________________

Libraries mailing list

Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________

Libraries mailing list

Libraries@haskell.org

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Dominic Steinitz dominic@steinitz.org http://idontgetoutmuch.wordpress.com

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Hi, On 01/24/2017 07:45 PM, Sven Panne wrote:

Whatever will be done, I think it would be good to keep the 'random' package alive, probably just by re-exporting one of the better RNGs, perhaps with a thin shim to keep the API identical. Yes, this would somehow "bless" one of the RNGs, but this is not important: The important thing is avoiding breakage in the ecosystem, keeping tutorials, books etc. valid. People who know what they are doing can easily pick the right RNG for their needs and/or quickly adapt their code, but I guess for lots of stuff having just *some* RNG under the traditional package name/module name is more than enough.

I couldn't agree more. Good (pseudo) random number generators are very important, and the effort people like Dominic and Carter have put in is deeply appreciated. Thanks! However, a simplistic generator is much better than code breakage and no generator. Users who don't pose the question about what generator is used under the hood are unlikely to be bitten very hard by a simplistic one. But they would be bitten hard if there isn't any or if the API changes. I've used the present one for games and the like, and they work OK for that. I've also used them in an implementation of Metropolis-Hastings (for Bayesian inference) (albeit not that much) and I at least broadly got the results I expected. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

On Wed, 25 Jan 2017, Andreas Abel wrote:

...

I got used to some randomized synthesized sounds and randomized melodies such that I already noticed changes in the random generator implementation.

Can't be very random, if you can get used to it, no? :) [Couldn't resist].

I used a constant random seed. That is, I did not really wanted random music, but in a way arbitrary music.