[Numpy-discussion] unclear output format for numpy.argmax()
Hello, There are some doubts that i have regarding the argmax() method of numpy.As described in reference doc's of numpy,argmax(axis=None,out=None) returns the indices of the maximum value along the given axis(In this case 0 is default). So, i tried to implement the method to a 2d array with elements say,[[1,2,3],[4,5,6]] along the axis 1.The output to this code is [2,2] and when i implement it along the axis 0,it outputs [1,1,1].I dont see the connection to this output with the scope of argmax method. I would appreciate a detailed insight to the argmax method. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Vectorize and ufunc attribute
Prior to 1.7, I had working compatibility code such as the following: if has_good_functions: # http://projects.scipy.org/numpy/ticket/1096 from numpy import logaddexp, logaddexp2 else: logaddexp = vectorize(_logaddexp, otypes=[numpy.float64]) logaddexp2 = vectorize(_logaddexp2, otypes=[numpy.float64]) # Run these at least once so that .ufunc.reduce exists logaddexp([1.,2.,3.],[1.,2.,3.]) logaddexp2([1.,2.,3.],[1.,2.,3.]) # And then make reduce available at the top level logaddexp.reduce = logaddexp.ufunc.reduce logaddexp2.reduce = logaddexp2.ufunc.reduce The point was that I wanted to treat the output of vectorize as a hacky drop-in replacement for a ufunc. In 1.7, I discovered that vectorize had changed (https://github.com/numpy/numpy/pull/290), and now there is no longer a ufunc attribute at all. Should this be added back in? Besides hackish drop-in replacements, I see value in to being able to call reduce, accumulate, etc (when possible) on the output of vectorize(). ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] unclear output format for numpy.argmax()
On Tue, Mar 12, 2013 at 8:20 AM, soumen ganguly soumendotgang...@gmail.comwrote: Hello, There are some doubts that i have regarding the argmax() method of numpy.As described in reference doc's of numpy,argmax(axis=None,out=None) returns the indices of the maximum value along the given axis(In this case 0 is default). So, i tried to implement the method to a 2d array with elements say,[[1,2,3],[4,5,6]] along the axis 1.The output to this code is [2,2] and when i implement it along the axis 0,it outputs [1,1,1].I dont see the connection to this output with the scope of argmax method. I would appreciate a detailed insight to the argmax method. I am not sure I understand the question. For axis 0 (the outer dimension in the way it is printed) the things being compared are argmax([1, 4]), argmax(([2, 5]), and argmax([3, 6]).. Amongst those, the second (index 1) is higher in each case, so it returns [1, 1, 1]. With axis 1 (the inner dimension in the way it is printed) , the things being compared are argmax([1, 2, 3]) and argmax([4, 5, 6]). In both case the third (index 2) is the highest, so it returns [2, 2]. What is unexpected about this? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Yes, this one again ImportError: No module named multiarray
I've been using Numpy/Scipy for 5 years so know a little on how to get around them. Recently, I've needed to either freeze or create executables with tools such as PyInstaller, Cython, Py2exe and others on both Windows (XP 32-bit, 7 64-bit) and Ubuntu (12.04) Linux (64-bit). The test program (which runs perfectly with the Python interpreter) is very simple: import numpy def main(): print numpy.array([12, 23, 34, 45, 56, 67, 78, 89, 90]) return if __name__ == '__main__': main() The software versions are Python 2.7.3, Numpy 1.7.0, and Scipy 0.11. The import numpy causes an ImportError: No module named multiarray. After endless Googling, I am none the wiser about what (really) causes the ImportError let alone what the solution is. The Traceback, similar to others found on the web, is: Traceback (most recent call last): File test.py, ... File C:\Python27\lib\site-packages\numpy\__init__.py, line 154, in module import add_newdocs File C:\Python27\lib\site-packages\numpy\add_newdocs.py, line 9, in module from numpy.lib import add_newdoc File C:\Python27\lib\site-packages\numpy\lib\__init__.py, line 4, in module from type_check import * File C:\Python27\lib\site-packages\numpy\lib\type_check.py, line 8, in module import numpy.core.numeric as _nx File C:\Python27\lib\site-packages\numpy\core\__init__.py, line 5, in module import multiarray ImportError: No module named multiarray. Could someone shed some light on this - please? Thx. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Yes, this one again ImportError: No module named multiarray
multiarray is an extension module that lives within numpy/core, that is, when, import multiarray is called, (and it's the first imported extension module in numpy), multiarray.ext (ext being dll on Windows I guess), gets dynamically loaded. No module named multiarray is indicating problems with your freeze setup. Most of these tools don't support locally imported extension modules. Does this help you get oriented on your problem? A On Tue, Mar 12, 2013 at 1:01 PM, Dinesh B Vadhia dineshbvad...@hotmail.comwrote: ** I've been using Numpy/Scipy for 5 years so know a little on how to get around them. Recently, I've needed to either freeze or create executables with tools such as PyInstaller, Cython, Py2exe and others on both Windows (XP 32-bit, 7 64-bit) and Ubuntu (12.04) Linux (64-bit). The test program (which runs perfectly with the Python interpreter) is very simple: import numpy def main(): print numpy.array([12, 23, 34, 45, 56, 67, 78, 89, 90]) return if __name__ == '__main__': main() The software versions are Python 2.7.3, Numpy 1.7.0, and Scipy 0.11. The import numpy causes an ImportError: No module named multiarray. After endless Googling, I am none the wiser about what (really) causes the ImportError let alone what the solution is. The Traceback, similar to others found on the web, is: Traceback (most recent call last): File test.py, ... File C:\Python27\lib\site-packages\numpy\__init__.py, line 154, in module import add_newdocs File C:\Python27\lib\site-packages\numpy\add_newdocs.py, line 9, in module from numpy.lib import add_newdoc File C:\Python27\lib\site-packages\numpy\lib\__init__.py, line 4, in module from type_check import * File C:\Python27\lib\site-packages\numpy\lib\type_check.py, line 8, in module import numpy.core.numeric as _nx File C:\Python27\lib\site-packages\numpy\core\__init__.py, line 5, in module import multiarray ImportError: No module named multiarray. Could someone shed some light on this - please? Thx. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Yes, this one again ImportError: No module named multiarray
Does that mean numpy won't work with freeze/create_executable type of tools or is there a workaround? From: Aron Ahmadia Sent: Tuesday, March 12, 2013 6:17 AM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] Yes,this one again ImportError: No module named multiarray multiarray is an extension module that lives within numpy/core, that is, when, import multiarray is called, (and it's the first imported extension module in numpy), multiarray.ext (ext being dll on Windows I guess), gets dynamically loaded. No module named multiarray is indicating problems with your freeze setup. Most of these tools don't support locally imported extension modules. Does this help you get oriented on your problem? A On Tue, Mar 12, 2013 at 1:01 PM, Dinesh B Vadhia dineshbvad...@hotmail.com wrote: I've been using Numpy/Scipy for 5 years so know a little on how to get around them. Recently, I've needed to either freeze or create executables with tools such as PyInstaller, Cython, Py2exe and others on both Windows (XP 32-bit, 7 64-bit) and Ubuntu (12.04) Linux (64-bit). The test program (which runs perfectly with the Python interpreter) is very simple: import numpy def main(): print numpy.array([12, 23, 34, 45, 56, 67, 78, 89, 90]) return if __name__ == '__main__': main() The software versions are Python 2.7.3, Numpy 1.7.0, and Scipy 0.11. The import numpy causes an ImportError: No module named multiarray. After endless Googling, I am none the wiser about what (really) causes the ImportError let alone what the solution is. The Traceback, similar to others found on the web, is: Traceback (most recent call last): File test.py, ... File C:\Python27\lib\site-packages\numpy\__init__.py, line 154, in module import add_newdocs File C:\Python27\lib\site-packages\numpy\add_newdocs.py, line 9, in module from numpy.lib import add_newdoc File C:\Python27\lib\site-packages\numpy\lib\__init__.py, line 4, in module from type_check import * File C:\Python27\lib\site-packages\numpy\lib\type_check.py, line 8, in module import numpy.core.numeric as _nx File C:\Python27\lib\site-packages\numpy\core\__init__.py, line 5, in module import multiarray ImportError: No module named multiarray. Could someone shed some light on this - please? Thx. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] (@Pat Marion) Re: Yes, this one again ImportError: No module named multiarray
Pat Marion at Kitware did some work on this, I'm pinging him on the thread. A On Tue, Mar 12, 2013 at 2:05 PM, Dinesh B Vadhia dineshbvad...@hotmail.comwrote: ** Does that mean numpy won't work with freeze/create_executable type of tools or is there a workaround? *From:* Aron Ahmadia a...@ahmadia.net *Sent:* Tuesday, March 12, 2013 6:17 AM *To:* Discussion of Numerical Python numpy-discussion@scipy.org *Subject:* Re: [Numpy-discussion] Yes,this one again ImportError: No module named multiarray multiarray is an extension module that lives within numpy/core, that is, when, import multiarray is called, (and it's the first imported extension module in numpy), multiarray.ext (ext being dll on Windows I guess), gets dynamically loaded. No module named multiarray is indicating problems with your freeze setup. Most of these tools don't support locally imported extension modules. Does this help you get oriented on your problem? A On Tue, Mar 12, 2013 at 1:01 PM, Dinesh B Vadhia dineshbvad...@hotmail.com wrote: ** I've been using Numpy/Scipy for 5 years so know a little on how to get around them. Recently, I've needed to either freeze or create executables with tools such as PyInstaller, Cython, Py2exe and others on both Windows (XP 32-bit, 7 64-bit) and Ubuntu (12.04) Linux (64-bit). The test program (which runs perfectly with the Python interpreter) is very simple: import numpy def main(): print numpy.array([12, 23, 34, 45, 56, 67, 78, 89, 90]) return if __name__ == '__main__': main() The software versions are Python 2.7.3, Numpy 1.7.0, and Scipy 0.11. The import numpy causes an ImportError: No module named multiarray. After endless Googling, I am none the wiser about what (really) causes the ImportError let alone what the solution is. The Traceback, similar to others found on the web, is: Traceback (most recent call last): File test.py, ... File C:\Python27\lib\site-packages\numpy\__init__.py, line 154, in module import add_newdocs File C:\Python27\lib\site-packages\numpy\add_newdocs.py, line 9, in module from numpy.lib import add_newdoc File C:\Python27\lib\site-packages\numpy\lib\__init__.py, line 4, in module from type_check import * File C:\Python27\lib\site-packages\numpy\lib\type_check.py, line 8, in module import numpy.core.numeric as _nx File C:\Python27\lib\site-packages\numpy\core\__init__.py, line 5, in module import multiarray ImportError: No module named multiarray. Could someone shed some light on this - please? Thx. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (@Pat Marion) Re: Yes, this one again ImportError: No module named multiarray
Thanks for copying me, Aron. Hi Dinesh, I have a github project which demonstrates how to use numpy with freeze. The project's readme includes more information: https://github.com/patmarion/NumpyBuiltinExample It does require a small patch to CPython's import.c file. I haven't tried posted this patch to the CPython developers, perhaps there'd be interest incorporating it upstream. Pat On Wed, Mar 13, 2013 at 12:08 AM, Aron Ahmadia a...@ahmadia.net wrote: Pat Marion at Kitware did some work on this, I'm pinging him on the thread. A On Tue, Mar 12, 2013 at 2:05 PM, Dinesh B Vadhia dineshbvad...@hotmail.com wrote: ** Does that mean numpy won't work with freeze/create_executable type of tools or is there a workaround? *From:* Aron Ahmadia a...@ahmadia.net *Sent:* Tuesday, March 12, 2013 6:17 AM *To:* Discussion of Numerical Python numpy-discussion@scipy.org *Subject:* Re: [Numpy-discussion] Yes,this one again ImportError: No module named multiarray multiarray is an extension module that lives within numpy/core, that is, when, import multiarray is called, (and it's the first imported extension module in numpy), multiarray.ext (ext being dll on Windows I guess), gets dynamically loaded. No module named multiarray is indicating problems with your freeze setup. Most of these tools don't support locally imported extension modules. Does this help you get oriented on your problem? A On Tue, Mar 12, 2013 at 1:01 PM, Dinesh B Vadhia dineshbvad...@hotmail.com wrote: ** I've been using Numpy/Scipy for 5 years so know a little on how to get around them. Recently, I've needed to either freeze or create executables with tools such as PyInstaller, Cython, Py2exe and others on both Windows (XP 32-bit, 7 64-bit) and Ubuntu (12.04) Linux (64-bit). The test program (which runs perfectly with the Python interpreter) is very simple: import numpy def main(): print numpy.array([12, 23, 34, 45, 56, 67, 78, 89, 90]) return if __name__ == '__main__': main() The software versions are Python 2.7.3, Numpy 1.7.0, and Scipy 0.11. The import numpy causes an ImportError: No module named multiarray. After endless Googling, I am none the wiser about what (really) causes the ImportError let alone what the solution is. The Traceback, similar to others found on the web, is: Traceback (most recent call last): File test.py, ... File C:\Python27\lib\site-packages\numpy\__init__.py, line 154, in module import add_newdocs File C:\Python27\lib\site-packages\numpy\add_newdocs.py, line 9, in module from numpy.lib import add_newdoc File C:\Python27\lib\site-packages\numpy\lib\__init__.py, line 4, in module from type_check import * File C:\Python27\lib\site-packages\numpy\lib\type_check.py, line 8, in module import numpy.core.numeric as _nx File C:\Python27\lib\site-packages\numpy\core\__init__.py, line 5, in module import multiarray ImportError: No module named multiarray. Could someone shed some light on this - please? Thx. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Vectorize and ufunc attribute
T J: You may want to look into `numpy.frompyfunc` ( http://docs.scipy.org/doc/numpy/reference/generated/numpy.frompyfunc.html). -Brad On Tue, Mar 12, 2013 at 12:40 AM, T J tjhn...@gmail.com wrote: Prior to 1.7, I had working compatibility code such as the following: if has_good_functions: # http://projects.scipy.org/numpy/ticket/1096 from numpy import logaddexp, logaddexp2 else: logaddexp = vectorize(_logaddexp, otypes=[numpy.float64]) logaddexp2 = vectorize(_logaddexp2, otypes=[numpy.float64]) # Run these at least once so that .ufunc.reduce exists logaddexp([1.,2.,3.],[1.,2.,3.]) logaddexp2([1.,2.,3.],[1.,2.,3.]) # And then make reduce available at the top level logaddexp.reduce = logaddexp.ufunc.reduce logaddexp2.reduce = logaddexp2.ufunc.reduce The point was that I wanted to treat the output of vectorize as a hacky drop-in replacement for a ufunc. In 1.7, I discovered that vectorize had changed (https://github.com/numpy/numpy/pull/290), and now there is no longer a ufunc attribute at all. Should this be added back in? Besides hackish drop-in replacements, I see value in to being able to call reduce, accumulate, etc (when possible) on the output of vectorize(). ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adopt Mersenne Twister 64bit?
On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern robert.k...@gmail.com wrote: On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam s...@continuum.io wrote: My suggestion to overcome (1) and (2) is to allow the user to select between the two implementations (and possibly different algorithms in the future). If user does not provide a choice, we use the MT19937-32 by default. numpy.random.set_state(MT19937_64, …) # choose the 64-bit implementation Most likely, the different PRNGs should be different subclasses of RandomState. The module-level convenience API should probably be left alone. If you need to control the PRNG that you are using, you really need to be passing around a RandomState instance and not relying on reseeding the shared global instance. +1 Aside: I really wish we hadn't exposed `set_state()` in the module API. It's an attractive nuisance. And our own test suite is a serious offender in this regard, we have tests that fail if you run the test suite in a non-default order... https://github.com/numpy/numpy/issues/347 I wonder if we dare deprecate it? The whole idea of a global random state is just a bad one, like every other sort of global shared state. But it's one that's deeply baked into a lot of scientific programmers expectations about how APIs work... -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adopt Mersenne Twister 64bit?
On Tue, Mar 12, 2013 at 9:25 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern robert.k...@gmail.com wrote: On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam s...@continuum.io wrote: My suggestion to overcome (1) and (2) is to allow the user to select between the two implementations (and possibly different algorithms in the future). If user does not provide a choice, we use the MT19937-32 by default. numpy.random.set_state(MT19937_64, …) # choose the 64-bit implementation Most likely, the different PRNGs should be different subclasses of RandomState. The module-level convenience API should probably be left alone. If you need to control the PRNG that you are using, you really need to be passing around a RandomState instance and not relying on reseeding the shared global instance. +1 Aside: I really wish we hadn't exposed `set_state()` in the module API. It's an attractive nuisance. And our own test suite is a serious offender in this regard, we have tests that fail if you run the test suite in a non-default order... https://github.com/numpy/numpy/issues/347 I wonder if we dare deprecate it? The whole idea of a global random state is just a bad one, like every other sort of global shared state. But it's one that's deeply baked into a lot of scientific programmers expectations about how APIs work... (To be clear, by 'it' here I meant np.random.set_seed(), not the whole np.random API. Probably. And by 'deprecate' I mean 'whine loudly in some fashion when people use it', not 'rip out in a few releases'. I think.) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Yes, this one again ImportError: No module named multiarray
On Tue, Mar 12, 2013 at 7:05 AM, Dinesh B Vadhia dineshbvad...@hotmail.com wrote: Does that mean numpy won't work with freeze/create_executable type of tools or is there a workaround? I've used numpy with py2exe and py2app out of the box with no issues ( actually, there is an issue with too much stuff getting bundled up, but it works) ImportError let alone what the solution is. The Traceback, similar to others found on the web, is: Traceback (most recent call last): File test.py, ... File C:\Python27\lib\site-packages\numpy\__init__.py, line 154, in module This indicates that your code is importing the numpy that's inside the system installation -- it should be using one in your app bundle. What bundling tool are you using? How did you install python/numpy? What does your bundling tol config look like? And, of course, version numbers of everything. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adopt Mersenne Twister 64bit?
On Tue, Mar 12, 2013 at 5:27 PM, Nathaniel Smith n...@pobox.com wrote: On Tue, Mar 12, 2013 at 9:25 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern robert.k...@gmail.com wrote: On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam s...@continuum.io wrote: My suggestion to overcome (1) and (2) is to allow the user to select between the two implementations (and possibly different algorithms in the future). If user does not provide a choice, we use the MT19937-32 by default. numpy.random.set_state(MT19937_64, …) # choose the 64-bit implementation Most likely, the different PRNGs should be different subclasses of RandomState. The module-level convenience API should probably be left alone. If you need to control the PRNG that you are using, you really need to be passing around a RandomState instance and not relying on reseeding the shared global instance. +1 Aside: I really wish we hadn't exposed `set_state()` in the module API. It's an attractive nuisance. Here is a recipe how to use it http://mail.scipy.org/pipermail/numpy-discussion/2010-September/052911.html (I'm just drawing a random number as seed that I can save, instead of the entire state.) Josef And our own test suite is a serious offender in this regard, we have tests that fail if you run the test suite in a non-default order... https://github.com/numpy/numpy/issues/347 I wonder if we dare deprecate it? The whole idea of a global random state is just a bad one, like every other sort of global shared state. But it's one that's deeply baked into a lot of scientific programmers expectations about how APIs work... (To be clear, by 'it' here I meant np.random.set_seed(), not the whole np.random API. Probably. And by 'deprecate' I mean 'whine loudly in some fashion when people use it', not 'rip out in a few releases'. I think.) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adopt Mersenne Twister 64bit?
Nathaniel Smith wrote: On Tue, Mar 12, 2013 at 9:25 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern robert.k...@gmail.com wrote: On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam s...@continuum.io wrote: My suggestion to overcome (1) and (2) is to allow the user to select between the two implementations (and possibly different algorithms in the future). If user does not provide a choice, we use the MT19937-32 by default. numpy.random.set_state(MT19937_64, …) # choose the 64-bit implementation Most likely, the different PRNGs should be different subclasses of RandomState. The module-level convenience API should probably be left alone. If you need to control the PRNG that you are using, you really need to be passing around a RandomState instance and not relying on reseeding the shared global instance. +1 Aside: I really wish we hadn't exposed `set_state()` in the module API. It's an attractive nuisance. And our own test suite is a serious offender in this regard, we have tests that fail if you run the test suite in a non-default order... https://github.com/numpy/numpy/issues/347 I wonder if we dare deprecate it? The whole idea of a global random state is just a bad one, like every other sort of global shared state. But it's one that's deeply baked into a lot of scientific programmers expectations about how APIs work... (To be clear, by 'it' here I meant np.random.set_seed(), not the whole np.random API. Probably. And by 'deprecate' I mean 'whine loudly in some fashion when people use it', not 'rip out in a few releases'. I think.) -n What do you mean that the idea of global shared state is a bad one? How would you prefer the API to look? An alternative is a stateless rng, where you have to pass it it's state on each invocation, which it would update and return. I hope you're not advocating that. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adopt Mersenne Twister 64bit?
On Tue, Mar 12, 2013 at 10:38 PM, Neal Becker ndbeck...@gmail.com wrote: Nathaniel Smith wrote: On Tue, Mar 12, 2013 at 9:25 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern robert.k...@gmail.com wrote: On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam s...@continuum.io wrote: My suggestion to overcome (1) and (2) is to allow the user to select between the two implementations (and possibly different algorithms in the future). If user does not provide a choice, we use the MT19937-32 by default. numpy.random.set_state(MT19937_64, …) # choose the 64-bit implementation Most likely, the different PRNGs should be different subclasses of RandomState. The module-level convenience API should probably be left alone. If you need to control the PRNG that you are using, you really need to be passing around a RandomState instance and not relying on reseeding the shared global instance. +1 Aside: I really wish we hadn't exposed `set_state()` in the module API. It's an attractive nuisance. And our own test suite is a serious offender in this regard, we have tests that fail if you run the test suite in a non-default order... https://github.com/numpy/numpy/issues/347 I wonder if we dare deprecate it? The whole idea of a global random state is just a bad one, like every other sort of global shared state. But it's one that's deeply baked into a lot of scientific programmers expectations about how APIs work... (To be clear, by 'it' here I meant np.random.set_seed(), not the whole np.random API. Probably. And by 'deprecate' I mean 'whine loudly in some fashion when people use it', not 'rip out in a few releases'. I think.) -n What do you mean that the idea of global shared state is a bad one? The words global shared state drives fear into the hearts of experienced programmers everywhere, whatever the context. :-) It's rarely a *good* idea. How would you prefer the API to look? There are two current APIs: 1. Instantiate RandomState and call it's methods 2. Just call the functions in numpy.random The latter has a shared global state. In fact, all of those functions are just references to the methods on a shared global RandomState instance. We advocate using the former API. Note that it already exists. It was the recommended API from day one. No one is recommending adding a new API. An alternative is a stateless rng, where you have to pass it it's state on each invocation, which it would update and return. I hope you're not advocating that. No. This is a place where OOP solved the problem neatly. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adopt Mersenne Twister 64bit?
I guess I talked to you about 100 years ago about sharing state between numpy rng and code I have in c++ that wraps boost::random. So is there a C-api for this RandomState object I could use to call from c++? Maybe I could do something with that. The c++ code could invoke via the python api, but that might be slower. I'm just rambling here, I'd have to see the API to get some ideas. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Vectorize and ufunc attribute
On Tue, Mar 12, 2013 at 9:59 AM, Bradley M. Froehle brad.froe...@gmail.comwrote: T J: You may want to look into `numpy.frompyfunc` ( http://docs.scipy.org/doc/numpy/reference/generated/numpy.frompyfunc.html ). Yeah that's better, but it doesn't respect the output type of the function. Be nice if this supported the otypes keyword. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adopt Mersenne Twister 64bit?
Neal Becker wrote: I guess I talked to you about 100 years ago about sharing state between numpy rng and code I have in c++ that wraps boost::random. So is there a C-api for this RandomState object I could use to call from c++? Maybe I could do something with that. The c++ code could invoke via the python api, but that might be slower. I'm just rambling here, I'd have to see the API to get some ideas. I think if I could just grab a long int from the underlying mersenne twister, through some c api? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adopt Mersenne Twister 64bit?
On Tue, Mar 12, 2013 at 7:10 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:38 PM, Neal Becker ndbeck...@gmail.com wrote: Nathaniel Smith wrote: On Tue, Mar 12, 2013 at 9:25 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Mar 11, 2013 at 9:46 AM, Robert Kern robert.k...@gmail.com wrote: On Sun, Mar 10, 2013 at 6:12 PM, Siu Kwan Lam s...@continuum.io wrote: My suggestion to overcome (1) and (2) is to allow the user to select between the two implementations (and possibly different algorithms in the future). If user does not provide a choice, we use the MT19937-32 by default. numpy.random.set_state(MT19937_64, …) # choose the 64-bit implementation Most likely, the different PRNGs should be different subclasses of RandomState. The module-level convenience API should probably be left alone. If you need to control the PRNG that you are using, you really need to be passing around a RandomState instance and not relying on reseeding the shared global instance. +1 Aside: I really wish we hadn't exposed `set_state()` in the module API. It's an attractive nuisance. And our own test suite is a serious offender in this regard, we have tests that fail if you run the test suite in a non-default order... https://github.com/numpy/numpy/issues/347 I wonder if we dare deprecate it? The whole idea of a global random state is just a bad one, like every other sort of global shared state. But it's one that's deeply baked into a lot of scientific programmers expectations about how APIs work... (To be clear, by 'it' here I meant np.random.set_seed(), not the whole np.random API. Probably. And by 'deprecate' I mean 'whine loudly in some fashion when people use it', not 'rip out in a few releases'. I think.) -n What do you mean that the idea of global shared state is a bad one? The words global shared state drives fear into the hearts of experienced programmers everywhere, whatever the context. :-) It's rarely a *good* idea. How would you prefer the API to look? There are two current APIs: 1. Instantiate RandomState and call it's methods 2. Just call the functions in numpy.random The latter has a shared global state. In fact, all of those functions are just references to the methods on a shared global RandomState instance. We advocate using the former API. Note that it already exists. It was the recommended API from day one. No one is recommending adding a new API. I never saw much advertising for the RandomState api, and until recently wasn't sure why using the global random state function np.random.norm, ... should be a bad idea. Learning by example, and seeing almost all examples using the global state, is not exactly conducive to figuring out that there is an issue. All of scipy.stats.distribution random numbers are using the global random state. (I guess I should open a ticket.) Josef An alternative is a stateless rng, where you have to pass it it's state on each invocation, which it would update and return. I hope you're not advocating that. No. This is a place where OOP solved the problem neatly. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
