This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Better random number generator
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: christian.heimes, jcea, pitrou, rhettinger, vstinner
Priority: low Keywords:

Created on 2013-07-06 17:20 by James.Lu, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg192469 - (view) Author: James Lu (James.Lu) * Date: 2013-07-06 17:20
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html#dSFMT
You might want to use a better algorithm
msg192502 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-07-07 00:09
Do you want to provide a patch for Python's random module?

PS: Please do not upload files that can easily be downloaded from a 3rd party site. It just fills disk space on our server and doesn't provide a benefit for us.
msg192511 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2013-07-07 03:26
The bar is rather high for changing the current algorithm which is well studied, has a long period, and is reasonably fast.  I do not recommend jumping straight into making a patch before we get agreement that we really want another PRNG when the current one is stable, well-studied, performant, and has been working well for its intended purpose.

Note, we guarantee that the current method will always be available, so this would be just another option.

If we were to add another generator, I prefer that we add one with some completely different characteristics (such as being cryptographically strong).  I don't want to take the default generator and periodically switch it out with the "flavor of the month" (people are always coming up with more PRNGs that make various trade-offs between speed, size of stored state, period, etc).
msg192539 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-07-07 11:15
> If we were to add another generator, I prefer that we add one with
> some completely different characteristics (such as being
> cryptographically strong).  I don't want to take the default generator 
> and periodically switch it out with the "flavor of the month" (people 
> are always coming up with more PRNGs that make various trade-offs
> between speed, size of stored state, period, etc).

Agreed with Raymond.
History
Date User Action Args
2022-04-11 14:57:47adminsetgithub: 62586
2013-07-11 07:24:49rhettingersetstatus: open -> closed
resolution: rejected
2013-07-07 11:15:08pitrousetnosy: + pitrou
messages: + msg192539
2013-07-07 03:26:12rhettingersetpriority: normal -> low

nosy: + rhettinger
messages: + msg192511

assignee: rhettinger
2013-07-07 01:02:25jceasetnosy: + jcea
2013-07-07 00:09:43vstinnersetnosy: + vstinner
2013-07-07 00:09:11christian.heimessetnosy: + christian.heimes

messages: + msg192502
versions: + Python 3.4, - Python 3.3
2013-07-07 00:07:08christian.heimessetfiles: - dSFMT-src-2.2.1.zip
2013-07-06 17:21:27James.Lusetnosy: - James.Lu
type: enhancement
-> (no value)
2013-07-06 17:20:12James.Lucreate