Quantcast

Random Number Update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Random Number Update

Dominic Steinitz-2
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.

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
[hidden email]
http://idontgetoutmuch.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Oleg Grenrus
`random` package provides `RandomGen` (used by tf-random, MonadRandom)
and `Random` (instances of which are in some of [1] for sure) classes.

(tf-random defines own version of those /also/)

Where they should live? I'd propose having module
`System.Random.Classes` in `random` (maybe more like ones in
`tf-random`, though I don't like RandomGen of either one) even we
deprecate the generator itself.

- Oleg

On 24.01.2017 15:35, 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.
>
> 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
> [hidden email]
> http://idontgetoutmuch.wordpress.com
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Adam Bergmark-2
In reply to this post by Dominic Steinitz-2


On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz <[hidden email]> 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
[hidden email]
http://idontgetoutmuch.wordpress.com

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Carter Schonwald
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 <[hidden email]> wrote:
On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz <[hidden email]> 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


[hidden email]


http://idontgetoutmuch.wordpress.com





_______________________________________________


Libraries mailing list


[hidden email]


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




_______________________________________________

Libraries mailing list

[hidden email]

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


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Carter Schonwald
Point being: you are welcome to remove yourself from the maintainers set for random. 


On Tue, Jan 24, 2017 at 10:33 AM Carter Schonwald <[hidden email]> 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 <[hidden email]> wrote:
On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz <[hidden email]> 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


[hidden email]


http://idontgetoutmuch.wordpress.com





_______________________________________________


Libraries mailing list


[hidden email]


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




_______________________________________________

Libraries mailing list

[hidden email]

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


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Dominic Steinitz-2
In reply to this post by Carter Schonwald
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 <[hidden email]> 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 <[hidden email]> wrote:
On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz <[hidden email]> 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


[hidden email]


http://idontgetoutmuch.wordpress.com





_______________________________________________


Libraries mailing list


[hidden email]


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




_______________________________________________

Libraries mailing list

[hidden email]

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




_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Carter Schonwald
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz <[hidden email]> 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


[hidden email]


http://idontgetoutmuch.wordpress.com





_______________________________________________


Libraries mailing list


[hidden email]


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




_______________________________________________

Libraries mailing list

[hidden email]

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








_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

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

Thanks,
Tom


El 24 ene 2017, a las 10:05, Carter Schonwald <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz <[hidden email]> 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


[hidden email]


http://idontgetoutmuch.wordpress.com





_______________________________________________


Libraries mailing list


[hidden email]


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




_______________________________________________

Libraries mailing list

[hidden email]

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







_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Sven Panne-2
2017-01-24 18:33 GMT+01:00 <[hidden email]>:
Carter, can you outline how random v2 compares to v1?

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.

Just my usual backwards-compatibility-rant... ;-)

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Henning Thielemann
In reply to this post by Dominic Steinitz-2

On Tue, 24 Jan 2017, Dominic Steinitz wrote:

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

I have used the plain old System.Random exclusively for years now and did
not encounter any problems, but I also did not watch for them. I used
System.Random for Markov chains, audio noise generation, randomized
algorithmic music, board game computer opponents etc. I'd like to keep a
default random generator for the many cases where I don't care about the
precise algorithm. That said, I got used to some randomized synthesized
sounds and randomized melodies such that I already noticed changes in the
random generator implementation.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Andreas Abel-2
 > 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].

On 24.01.2017 21:53, Henning Thielemann wrote:

>
> On Tue, 24 Jan 2017, Dominic Steinitz wrote:
>
>> 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.
>
> I have used the plain old System.Random exclusively for years now and
> did not encounter any problems, but I also did not watch for them. I
> used System.Random for Markov chains, audio noise generation, randomized
> algorithmic music, board game computer opponents etc. I'd like to keep a
> default random generator for the many cases where I don't care about the
> precise algorithm. That said, I got used to some randomized synthesized
> sounds and randomized melodies such that I already noticed changes in
> the random generator implementation.
--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www.cse.chalmers.se/~abela/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Henrik Nilsson-2
In reply to this post by Sven Panne-2
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.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Henning Thielemann
In reply to this post by Andreas Abel-2

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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Dominic Steinitz-2
In reply to this post by Dominic Steinitz-2
I’ll try and address the points.

1. I proposed a low cost solution as advocated by Sven and Henrik about 2 years ago, that of using tf-random. This was rejected because apparently better RNGs might exist. Now as we all know there is no such thing as the best RNG. My reasoning for tf-random was that if it were good enough for QuickCheck then it would certainly be good enough for naive users. A case of the best driving out the good? Not that best exists in this case.

2. QuickCheck were bitten very hard!

3. 
Prelude> import System.Random
Prelude System.Random> let dieRoll = fst . randomR (1,6) . mkStdGen :: Int -> Int
Prelude System.Random> map dieRoll [1..20]
[6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6]

4. In addition to the problems adumbrated above, random also has a range
Prelude System.Random> newStdGen >>= return . genRange
(1,2147483562)

which makes it fail even testu01’s SmallCrush if used naively.

random *may* work in certain cases but I would strongly advise against using it when there are so many other packages without the above problems. I would also add that for e.g. MCMC it is often very hard to see if something is working or not working because of the Monte Carlo noise; something apparently working does not necessarily validate a particular RNG.

I can’t say I agree with the reasoning that it is better to carry on using something that could be giving incorrect results silently rather than breaking things so that people can take action.

Anyhow as I have already said I feel I have done my bit for the Haskell Community. I agree with Carter that this is out of scope for the Core Libraries Committee. I wish you all luck and will step down from being maintainer.

On 25 Jan 2017, at 11:26, [hidden email] wrote:

Send Libraries mailing list submissions to
[hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
or, via email, send a message with subject or body 'help' to
[hidden email]

You can reach the person managing the list at
[hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Libraries digest..."


Today's Topics:

 1. Re: Selection Monad (Jakub Daniel)
 2. Add Zero and One to Data.Functor (mirroring V1, U1)
    (Baldur Blöndal)
 3. Re: Random Number Update (Sven Panne)
 4. Re: Random Number Update (Henning Thielemann)
 5. Re: Random Number Update (Andreas Abel)
 6. Re: Random Number Update (Henrik Nilsson)


----------------------------------------------------------------------

Message: 1
Date: Tue, 24 Jan 2017 17:23:58 +0000
From: Jakub Daniel <[hidden email]>
To: Eric Mertens <[hidden email]>
Cc: [hidden email]
Subject: Re: Selection Monad
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi Eric,

Just to clarify, my question was not about endorsing another library but
rather extending the ones currently maintained by the committee with
definition of a notion closely related to what is already contained in the
libraries. It just so happens that Edward Kmett implemented the notion in a
standalone library. However to me it does not make much sense to include
ContT but not SelT (currently under the name Search) in the core libraries,
despite their connection. I understand if this does not change the answer
though.

Best Regards,
Jakub Daniel



On Tue, 24 Jan 2017 at 17:39 Eric Mertens <[hidden email]> wrote:

Hi Jakub,

The core libraries committee helps maintain libraries that are already
critical to the Haskell ecosystem. It doesn’t select new libraries to be
recommended to users. It’s possible that the search package is a hidden gem
that more people need to know about. To accomplish that people will need to
write software using it, market it with blog posts, and bring it up in
discussions.

Best Regards,
Eric Mertens

On Jan 24, 2017, at 5:57 AM, Jakub Daniel <[hidden email]> wrote:

Hello,

I apologize in case this is not the right place to bring this
question/proposal up. Some time ago I stumbled upon the Selection Monad [1]
(also referred to as Search from the search package on hackage). Its
relation to the Continuation Monad and the usefulness demonstrated in [1]
made me wonder whether it would be nice to include Selection Monad in the
core libraries along the Continuation Monad (in mtl and transformers) with
all the business of selections attaining continuations. I can imagine the
pattern to be too little recognised to justify such an addition, yet the
theoretical connection to the Continuation Monad seems to be an interesting
one and worth being addressed.

Best,

Jakub Daniel

[1] Jules Hedges. *Monad transformers for backtracking search*. In *Proceedings
of MSFP 2014. *https://arxiv.org/abs/1406.2058

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170124/630bc9cc/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 24 Jan 2017 19:17:31 +0000
From: Baldur Blöndal <[hidden email]>
To: Haskell Libraries <[hidden email]>
Subject: Add Zero and One to Data.Functor (mirroring V1, U1)
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Deadline of 2 weeks.

Original discussion: ⁽¹⁾

data Zero a
data One  a = One

Same definitions as in ‘trivia’ package,⁽²⁾
if a consensus is reached we can update
the documentation for Free:⁽³⁾

“Free Zero” is isomorphic to Identity.
“Free One” is isomorphic to Maybe.

⁽¹⁾ https://ghc.haskell.org/trac/ghc/ticket/13177
⁽²⁾ https://hackage.haskell.org/package/trivia
⁽³⁾
https://hackage.haskell.org/package/free-4.12.4/docs/Control-Monad-Free.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170124/3945e7ae/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 24 Jan 2017 20:45:04 +0100
From: Sven Panne <[hidden email]>
To: Thomas Murphy <[hidden email]>
Cc: libraries <[hidden email]>, [hidden email]
Subject: Re: Random Number Update
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

2017-01-24 18:33 GMT+01:00 <[hidden email]>:

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


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.

Just my usual backwards-compatibility-rant... ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170124/e0d26476/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 24 Jan 2017 21:53:48 +0100 (CET)
From: Henning Thielemann <[hidden email]>
To: Dominic Steinitz <[hidden email]>
Cc: libraries <[hidden email]>
Subject: Re: Random Number Update
Message-ID: <alpine.DEB.2.02.1701242144080.7413@sputnik>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed


On Tue, 24 Jan 2017, Dominic Steinitz wrote:

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.

I have used the plain old System.Random exclusively for years now and did 
not encounter any problems, but I also did not watch for them. I used 
System.Random for Markov chains, audio noise generation, randomized 
algorithmic music, board game computer opponents etc. I'd like to keep a 
default random generator for the many cases where I don't care about the 
precise algorithm. That said, I got used to some randomized synthesized 
sounds and randomized melodies such that I already noticed changes in the 
random generator implementation.


------------------------------

Message: 5
Date: Wed, 25 Jan 2017 11:43:29 +0100
From: Andreas Abel <[hidden email]>
To: Henning Thielemann <[hidden email]>, Haskell
Libraries <[hidden email]>
Subject: Re: Random Number Update
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"; format=flowed

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

On 24.01.2017 21:53, Henning Thielemann wrote:

On Tue, 24 Jan 2017, Dominic Steinitz wrote:

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.

I have used the plain old System.Random exclusively for years now and
did not encounter any problems, but I also did not watch for them. I
used System.Random for Markov chains, audio noise generation, randomized
algorithmic music, board game computer opponents etc. I'd like to keep a
default random generator for the many cases where I don't care about the
precise algorithm. That said, I got used to some randomized synthesized
sounds and randomized melodies such that I already noticed changes in
the random generator implementation.
-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www.cse.chalmers.se/~abela/


------------------------------

Message: 6
Date: Wed, 25 Jan 2017 11:44:49 +0000
From: Henrik Nilsson <[hidden email]>
To: [hidden email]
Subject: Re: Random Number Update
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=UTF-8; format=flowed

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.



------------------------------

Subject: Digest Footer

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


------------------------------

End of Libraries Digest, Vol 161, Issue 36
******************************************


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Sven Panne-2
2017-01-25 13:47 GMT+01:00 Dominic Steinitz <[hidden email]>:
[...] I can’t say I agree with the reasoning that it is better to carry on using something that could be giving incorrect results silently rather than breaking things so that people can take action. [...]

This is not what I have proposed: My proposal was: Add any number of RNGs in one or more packages, but keep the current API of System.Random in package "random". It should probably use (= re-export, perhaps with a shim) one of the other, better RNGs to address the problems you've mentioned.

Breaking/removing fundamental packages should not be done light-heartedly, it wreaks havoc in the ecosystem. Look e.g. at the reverse dependencies of "random" (http://packdeps.haskellers.com/reverse/random): There are 845 packages affected, and I'm not even sure if that page takes transitive dependencies into account. Assuming that hundreds of package maintainer will happily update their packages in a short time frame just to use something "better" (where "better" is probably very dependent on one's POV) is overly optimistic. And in addition, doing such breaking changes obsoletes documentation, tutorials etc. out there. Yes, I'm repeating myself, but this is a point which seems to be forgotten quite often.

Is there something in System.Random's API which is fundamentally broken? I'm not sure, and I'm by no means an expert in RNGs. If yes, we should nevertheless keep it for now, probably deprecating the broken parts and phase them out slowly. Processes like this are quite slow (measured in years), and there are many good reasons for this. Looking e.g. at Java's java.lang.Thread.stop() one can see that it is still in the latest JDK, although it has been deprecated for almost 2 decades now. Another example is C++'s horrible pre-exception I/O standard library, something which everybody hates, but it is still there, after an even longer time.

Cheers,
   S.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Carter Schonwald
the fuzzy and slightly out of date task list in 
sketches out some of the basic stuff (though theres more confusion than clarity in the discussion thread on that ticket)

for my own peace i'm doing most of the v2 work over at https://github.com/cartazio/random, and i've been focusing on internals before sussing 

the API will have a breaking change even if we were types compatible because the meaning of the seed stats will no long provide the same computations

the v2 series will provide splitmix and pcg RNGs, a MonadRandom class that doesn't require a PrimMonad constraint for pure generators. 

per commit CI will end up running small crush and determinism checking tests once its at a stable/more mature point, and per RELEASE CI will do a big crush run or several on various permutations of the tools

thats ignoring having good benchmarks for how well different RNGS and implementation strategies thereof

I've also had some productive chats with tomdb of Galois about what the end state should be. 

I think for all practical purposes this thread is a waste of time. 

On Wed, Jan 25, 2017 at 2:55 PM, Sven Panne <[hidden email]> wrote:
2017-01-25 13:47 GMT+01:00 Dominic Steinitz <[hidden email]>:
[...] I can’t say I agree with the reasoning that it is better to carry on using something that could be giving incorrect results silently rather than breaking things so that people can take action. [...]

This is not what I have proposed: My proposal was: Add any number of RNGs in one or more packages, but keep the current API of System.Random in package "random". It should probably use (= re-export, perhaps with a shim) one of the other, better RNGs to address the problems you've mentioned.

Breaking/removing fundamental packages should not be done light-heartedly, it wreaks havoc in the ecosystem. Look e.g. at the reverse dependencies of "random" (http://packdeps.haskellers.com/reverse/random): There are 845 packages affected, and I'm not even sure if that page takes transitive dependencies into account. Assuming that hundreds of package maintainer will happily update their packages in a short time frame just to use something "better" (where "better" is probably very dependent on one's POV) is overly optimistic. And in addition, doing such breaking changes obsoletes documentation, tutorials etc. out there. Yes, I'm repeating myself, but this is a point which seems to be forgotten quite often.

Is there something in System.Random's API which is fundamentally broken? I'm not sure, and I'm by no means an expert in RNGs. If yes, we should nevertheless keep it for now, probably deprecating the broken parts and phase them out slowly. Processes like this are quite slow (measured in years), and there are many good reasons for this. Looking e.g. at Java's java.lang.Thread.stop() one can see that it is still in the latest JDK, although it has been deprecated for almost 2 decades now. Another example is C++'s horrible pre-exception I/O standard library, something which everybody hates, but it is still there, after an even longer time.

Cheers,
   S.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Random Number Update

Niklas Hambüchen
In reply to this post by Sven Panne-2
I'm a bit late to the party.

Deprecating random, or functions/generators within it, does not conflict
with backwards compatibility in my opinion.

If there's something that doesn't quite work as we'd like it, we can
still keep it forever with a DEPRECATE pragma, and better functions get
new names. Java has been doing that successfully for a long time, with
some functions being deprecated and still working for 20 years.

You just get that very useful warning when you use them.

In fact, I believe that deprecation is the only correct way to bring in
new generators into any random package, because you cannot replace a
pure RNG by a better RNG without breaking lots of people's code.
When you use a pure RGN, you rely on it giving the same output given the
same seed, to be referentially transparent, without exception, forever
in the future, also across library version upgrades.
If a random gen was replaced under my feet, lots of my tests would break
that way.

I thus find Dominic's proposal to deprecate what doesn't work as
supposed the right thing. If this happens by deprecating the package, or
by deprecating functions from that package, is a technicality to me, and
I would prefer whatever gives better warnings (I believe this is
currently deprecating functions as that gives GHC warnings, while as to
my knowledge no tooling warns you if you use a deprecated package).

Niklas

On 24/01/17 20:45, Sven Panne wrote:

> 2017-01-24 18:33 GMT+01:00 <[hidden email] <mailto:[hidden email]>>:
>
>     Carter, can you outline how random v2 compares to v1?
>
>
> 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.
>
> Just my usual backwards-compatibility-rant... ;-)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...