[issue16659] Pure Python implementation of random

Alex Gaynor added the comment: Looking at the patch (haven't actually benchmarked it), I have two concerns with respect to performance: a) The need for locking, this doesn't exist in the C or RPython versions because of the GIL. That locking is going to be distinctly un-free. b) The need for m

[issue16659] Pure Python implementation of random

Brett Cannon added the comment: I was talking with Alex Gaynor about the Python implementation of operator (http://bugs.python.org/issue16694) and asked about this bug since Raymond said the fact PyPy had an RPython implementation was a knock against bothering with this. Alex said if performan

[issue16659] Pure Python implementation of random

Raymond Hettinger added the comment: [Serhiy Storchaka] > I don't want to make a decision on the inclusion of this code. It was a tough call, but I don't want to add this code. You've a great job with it, but I don't think it is a worthwhile endeavor. * The algorithm was designed with C lev

[issue16659] Pure Python implementation of random

Raymond Hettinger added the comment: Okay thanks. I'll look over the patch in detail over the next few days. FYI, I'm the maintainer of this module (and was the one to add the original Mersenne Twister code). -- assignee: serhiy.storchaka -> rhettinger _

[issue16659] Pure Python implementation of random

Serhiy Storchaka added the comment: I don't want to make a decision on the inclusion of this code. However, I will undertake to maintain it. I'm going to fix one algorithmic bug in current implementation and add C implementations for some methods which significantly slowed in Python implementa

[issue16659] Pure Python implementation of random

Brett Cannon added the comment: In response to Raymond: First, Serhiy is a core developer now, so if he wants to commit this code and maintain it I have no objections as it doesn't detract from anything and the maintenance burden is his if he wants it. Whether any of us view it as the best us

[issue16659] Pure Python implementation of random

Stefan Behnel added the comment: FWIW, PyPy has an (R)Python implementation already: https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/rrandom.py -- nosy: +scoder ___ Python tracker ___

[issue16659] Pure Python implementation of random

Raymond Hettinger added the comment: Brett, if all the other Python implementations already have a working implementation of random, what purpose is served by adding a pure python version of the Mersenne Twister than won't be run by anyone? -- ___ P

[issue16659] Pure Python implementation of random

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16659] Pure Python implementation of random

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue16659] Pure Python implementation of random

Serhiy Storchaka added the comment: Patch updated. One bug fixed. Also I made some benchmarks. The pure Python random() about 100 times slower and getrandbits(32) about 13 times slower than the C implementation. -- Added file: http://bugs.python.org/file28303/random_pure_python_5.patch

[issue16659] Pure Python implementation of random

Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28296/random_pure_python_4.patch ___ Python tracker ___ ___ Python-bugs

[issue16659] Pure Python implementation of random

Serhiy Storchaka added the comment: Patch updated. Comments and docstrings a little enhanced. Thanks Brett for review. Also Python implementation of core generator now is threadsafe (in particular random() and getrandbits() methods) as its C implementation and its private members now are more

[issue16659] Pure Python implementation of random

Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28279/random_pure_python_2.patch ___ Python tracker ___ ___ Python-bugs

[issue16659] Pure Python implementation of random

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file28283/random_pure_python_3.patch ___ Python tracker ___ ___ Python-bugs-l

[issue16659] Pure Python implementation of random

Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file28278/random_pure_python.patch ___ Python tracker ___ ___ Python-bugs-l

[issue16659] Pure Python implementation of random

Serhiy Storchaka added the comment: Yes, I used test_heapq and test_decimal as an example. -- ___ Python tracker ___ ___ Python-bugs-l

[issue16659] Pure Python implementation of random

Brett Cannon added the comment: To see how to write tests that exercise both the C and Python versions look at test_heapq and test_warnings as examples. It will require some refactoring, but it's easy to do. -- ___ Python tracker

[issue16659] Pure Python implementation of random

Serhiy Storchaka added the comment: > I wonder whether it would make sense to use an array to hold the MT state, > for a closer match with the C code. I don't think it makes sense. The algorithm is same and list is more natural for Python. Also arrays a little slower than lists, but it doesn't

[issue16659] Pure Python implementation of random

Serhiy Storchaka added the comment: Patch updated. Tests now test both implementation. Thank Ezio for tip. -- Added file: http://bugs.python.org/file28279/random_pure_python_2.patch ___ Python tracker _

[issue16659] Pure Python implementation of random

Mark Dickinson added the comment: I wonder whether it would make sense to use an array to hold the MT state, for a closer match with the C code. (Not sure whether this would have a noticeable effect on performance.) -- ___ Python tracker

[issue16659] Pure Python implementation of random

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue16659] Pure Python implementation of random

New submission from Serhiy Storchaka: C implemented part of random module does not depend on any specific C level abilities. Here is a patch which implements this part on pure Python. May be this is not a best implementation. And I don't know how write tests for both implementations.