[Numpy-discussion] Status of NumPy and Python 3.3
Hey all, I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode handling was significantly improved in Python 3.3 and the array-scalar code (which assumed a certain structure for UnicodeObjects) is not working now. It would be nice to get 1.7.0 working with Python 3.3 if possible before the release. Anyone interested in tackling that little challenge? If someone has already tried it would be nice to hear your experience. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy.mean() revisited
On Thu, 2012-07-26 at 22:15 -0600, Charles R Harris wrote: I would support accumulating in 64 bits but, IIRC, the function will need to be rewritten so that it works by adding 32 bit floats to the accumulator to save space. There are also more stable methods that could also be investigated. There is a nice little project there for someone to cut their teeth on. So a (very) quick read around suggests that using an interim mean gives a more robust algorithm. The problem being, that these techniques are either multi-pass, or inherently slower (due to say a division in the loop). Higher precision would not suffer the same potential slow down and would solve most cases of this problem. Henry ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status of NumPy and Python 3.3
On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode handling was significantly improved in Python 3.3 and the array-scalar code (which assumed a certain structure for UnicodeObjects) is not working now. It would be nice to get 1.7.0 working with Python 3.3 if possible before the release. Anyone interested in tackling that little challenge? If someone has already tried it would be nice to hear your experience. Given that we're late with 1.7, I would suggest passing this to the next release, unless the fix is simple (just a change of API). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status of NumPy and Python 3.3
On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau courn...@gmail.com wrote: On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode handling was significantly improved in Python 3.3 and the array-scalar code (which assumed a certain structure for UnicodeObjects) is not working now. It would be nice to get 1.7.0 working with Python 3.3 if possible before the release. Anyone interested in tackling that little challenge? If someone has already tried it would be nice to hear your experience. Given that we're late with 1.7, I would suggest passing this to the next release, unless the fix is simple (just a change of API). I took a brief look at it, and from the errors I have seen, one is cosmetic, the other one is a bit more involved (rewriting PyArray_Scalar unicode support). While it is not difficult in nature, the current code has multiple #ifdef of Py_UNICODE_WIDE, meaning it would require multiple configurations on multiple python versions to be tested. I don't think python 3.3 support is critical - people who want to play with bet interpreters can build numpy by themselves from master, so I am -1 on integrating this into 1.7. I may have a fix within tonight for it, though, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status of NumPy and Python 3.3
On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau courn...@gmail.com wrote: On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode handling was significantly improved in Python 3.3 and the array-scalar code (which assumed a certain structure for UnicodeObjects) is not working now. It would be nice to get 1.7.0 working with Python 3.3 if possible before the release. Anyone interested in tackling that little challenge? If someone has already tried it would be nice to hear your experience. Given that we're late with 1.7, I would suggest passing this to the next release, unless the fix is simple (just a change of API). IMO, it's not a regression so it's not a release blocker. Of course we should release the fix whenever it's ready (in 1.7 if it's ready by then, else in 1.7.1), but we shouldn't hold up the release for it. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in numpy.mean() revisited
On Fri, Jul 27, 2012 at 5:15 AM, Charles R Harris charlesr.har...@gmail.com wrote: I would support accumulating in 64 bits but, IIRC, the function will need to be rewritten so that it works by adding 32 bit floats to the accumulator to save space. There are also more stable methods that could also be investigated. There is a nice little project there for someone to cut their teeth on. So the obvious solution here would be to make the ufunc reduce loop smart enough that x = np.zeros(2 ** 30, dtype=float32) np.sum(x, dtype=float64) does not upcast 'x' to float64's as a whole. This shouldn't be too terrible to implement -- iterate over the float32 array, and only upcast each inner-loop buffer as you go, instead of upcasting the whole thing. In fact, nditer might do this already? Then using a wide accumulator by default would just take a few lines of code in numpy.core._methods._mean to select the proper dtype and downcast the result. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.dot: why second-to-last index
Dear numpy historians, When multiplying two arrays with numpy.dot, the summation is made over the last index of the first argument, and over the *second-to-last* index of the second argument. I wonder why the convention has been chosen like this? The only reason I can think of is that this allows to use GEMM as a building block also for the 2d case. Is this the motivation? However, the actual implementation of numpy.dot uses GEMM only in the 2d x 2d case... Summation over the last index of the first argument and the first index of the second would seem a more obvious choice. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Synonym standards
On Thu, Jul 26, 2012 at 7:12 PM, Robert Kern robert.k...@gmail.com wrote: On Fri, Jul 27, 2012 at 12:05 AM, Colin J. Williams cjwilliam...@gmail.com wrote: On 26/07/2012 4:57 PM, Benjamin Root wrote: On Thu, Jul 26, 2012 at 4:45 PM, Colin J. Williams fn...@ncf.ca wrote: It seems that these standards have been adopted, which is good: The following import conventions are used throughout the NumPy source and documentation: import numpy as np import matplotlib as mpl import matplotlib.pyplot as plt Source: https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt Is there some similar standard for PyLab? Thanks, Colin W. Colin, Typically, with pylab mode of matplotlib, you do: from pylab import * This is essentially equivalent to: from numpy import * from matplotlib.pyplot import * Note that the pylab module is actually a part of matplotlib and is a shortcut to provide an environment that is very familiar to Matlab users. Converts are then encouraged to use the imports you mentioned in order to properly utilize python namespaces. I hope that helps! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Thanks Ben, I would prefer not to use: from xxx import *, because of the name pollution. The name convention that I copied above facilitates avoiding the pollution. In the same spirit, I've used: import pylab as plb But in that same spirit, using np and plt separately is preferred. Namespaces are one honking great idea -- let's do more of those! from http://www.python.org/dev/peps/pep-0020/ Absolutely correct. The namespace pollution is exactly why we encourage converts to move over from the pylab mode to separating out the numpy and pyplot namespaces. There are very subtle issues that arise when doing from pylab import * such as overriding the built-in any and all. The only real advantage of the pylab mode over separating out numpy and pyplot is conciseness, which many matlab users expect at first. Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status of NumPy and Python 3.3
On Fri, Jul 27, 2012 at 10:43 AM, David Cournapeau courn...@gmail.comwrote: On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau courn...@gmail.com wrote: On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode handling was significantly improved in Python 3.3 and the array-scalar code (which assumed a certain structure for UnicodeObjects) is not working now. It would be nice to get 1.7.0 working with Python 3.3 if possible before the release. Anyone interested in tackling that little challenge? If someone has already tried it would be nice to hear your experience. Given that we're late with 1.7, I would suggest passing this to the next release, unless the fix is simple (just a change of API). I took a brief look at it, and from the errors I have seen, one is cosmetic, the other one is a bit more involved (rewriting PyArray_Scalar unicode support). While it is not difficult in nature, the current code has multiple #ifdef of Py_UNICODE_WIDE, meaning it would require multiple configurations on multiple python versions to be tested. I don't think python 3.3 support is critical - people who want to play with bet interpreters can build numpy by themselves from master, so I am -1 on integrating this into 1.7. I may have a fix within tonight for it, though, There are 2 tickets about this: http://projects.scipy.org/numpy/ticket/2145 http://projects.scipy.org/numpy/ticket/1471 Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Synonym standards
On 27.07.2012, at 3:27PM, Benjamin Root wrote: I would prefer not to use: from xxx import *, because of the name pollution. The name convention that I copied above facilitates avoiding the pollution. In the same spirit, I've used: import pylab as plb But in that same spirit, using np and plt separately is preferred. Namespaces are one honking great idea -- let's do more of those! from http://www.python.org/dev/peps/pep-0020/ Absolutely correct. The namespace pollution is exactly why we encourage converts to move over from the pylab mode to separating out the numpy and pyplot namespaces. There are very subtle issues that arise when doing from pylab import * such as overriding the built-in any and all. The only real advantage of the pylab mode over separating out numpy and pyplot is conciseness, which many matlab users expect at first. It unfortunately also comes with the convenience of using the ipython --pylab mode - does anyone know how to turn the import * part of, or how to create a similar working environment with ipython that does keep namespaces clean? Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Synonym standards
On Fri, Jul 27, 2012 at 11:39 AM, Derek Homeier de...@astro.physik.uni-goettingen.de wrote: On 27.07.2012, at 3:27PM, Benjamin Root wrote: I would prefer not to use: from xxx import *, because of the name pollution. The name convention that I copied above facilitates avoiding the pollution. In the same spirit, I've used: import pylab as plb But in that same spirit, using np and plt separately is preferred. Namespaces are one honking great idea -- let's do more of those! from http://www.python.org/dev/peps/pep-0020/ Absolutely correct. The namespace pollution is exactly why we encourage converts to move over from the pylab mode to separating out the numpy and pyplot namespaces. There are very subtle issues that arise when doing from pylab import * such as overriding the built-in any and all. The only real advantage of the pylab mode over separating out numpy and pyplot is conciseness, which many matlab users expect at first. It unfortunately also comes with the convenience of using the ipython --pylab mode - does anyone know how to turn the import * part of, or how to create a similar working environment with ipython that does keep namespaces clean? Cheers, Derek There's a config flag that you can add to your ipython profile: c.TerminalIPythonApp.pylab_import_all = False For example, my profile is in ~/.ipython/profile_default/ipython_config.py Cheers, -Tony ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Synonym standards
On 27 Jul 2012, at 17:58, Tony Yu wrote: On Fri, Jul 27, 2012 at 11:39 AM, Derek Homeier de...@astro.physik.uni-goettingen.de wrote: On 27.07.2012, at 3:27PM, Benjamin Root wrote: I would prefer not to use: from xxx import *, because of the name pollution. The name convention that I copied above facilitates avoiding the pollution. In the same spirit, I've used: import pylab as plb But in that same spirit, using np and plt separately is preferred. Namespaces are one honking great idea -- let's do more of those! from http://www.python.org/dev/peps/pep-0020/ Absolutely correct. The namespace pollution is exactly why we encourage converts to move over from the pylab mode to separating out the numpy and pyplot namespaces. There are very subtle issues that arise when doing from pylab import * such as overriding the built-in any and all. The only real advantage of the pylab mode over separating out numpy and pyplot is conciseness, which many matlab users expect at first. It unfortunately also comes with the convenience of using the ipython --pylab mode - does anyone know how to turn the import * part of, or how to create a similar working environment with ipython that does keep namespaces clean? Cheers, Derek There's a config flag that you can add to your ipython profile: c.TerminalIPythonApp.pylab_import_all = False For example, my profile is in ~/.ipython/profile_default/ipython_config.py thanks, that was exactly what I was looking for - together with c.TerminalIPythonApp.exec_lines = ['import sys', 'import numpy as np', 'import matplotlib as mpl', 'import matplotlib.pyplot as plt'] etc. to have the shortcuts. Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.where?
On Thu, Jul 26, 2012 at 2:33 PM, Phil Hodge ho...@stsci.edu wrote: On a Linux machine: uname -srvop Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64 GNU/Linux this example shows an apparent problem with the where function: Python 2.7.1 (r271:86832, Dec 21 2010, 11:19:43) [GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2 Type help, copyright, credits or license for more information. import numpy as np print np.__version__ 1.5.1 net = np.zeros(3, dtype='f4') net[1] = 0.00458849 net[2] = 0.605202 max_net = net.max() test = np.where(net = 0., max_net, net) print test [ -2.23910537e-35 4.58848989e-03 6.05202019e-01] When I specified the dtype for net as 'f8', test[0] was 3.46244974e+68. It worked as expected (i.e. test[0] should be 0.605202) when I specified float(max_net) as the second argument to np.where. Phil Confirmed with version 1.7.0.dev-470c857 on a CentOS6 64-bit machine. Strange indeed. Breaking it down further: res = (net = 0.) print res [ True False False] np.where(res, max_net, net) array([ -2.23910537e-35, 4.58848989e-03, 6.05202019e-01], dtype=float32) Very Strange... Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.where?
On Fri, Jul 27, 2012 at 2:01 PM, Benjamin Root ben.r...@ou.edu wrote: On Thu, Jul 26, 2012 at 2:33 PM, Phil Hodge ho...@stsci.edu wrote: On a Linux machine: uname -srvop Linux 2.6.18-308.8.2.el5 #1 SMP Tue May 29 11:54:17 EDT 2012 x86_64 GNU/Linux this example shows an apparent problem with the where function: Python 2.7.1 (r271:86832, Dec 21 2010, 11:19:43) [GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2 Type help, copyright, credits or license for more information. import numpy as np print np.__version__ 1.5.1 net = np.zeros(3, dtype='f4') net[1] = 0.00458849 net[2] = 0.605202 max_net = net.max() test = np.where(net = 0., max_net, net) print test [ -2.23910537e-35 4.58848989e-03 6.05202019e-01] When I specified the dtype for net as 'f8', test[0] was 3.46244974e+68. It worked as expected (i.e. test[0] should be 0.605202) when I specified float(max_net) as the second argument to np.where. Phil Confirmed with version 1.7.0.dev-470c857 on a CentOS6 64-bit machine. Strange indeed. Breaking it down further: res = (net = 0.) print res [ True False False] np.where(res, max_net, net) array([ -2.23910537e-35, 4.58848989e-03, 6.05202019e-01], dtype=float32) Very Strange... Ben Root What if find really interesting is that -2.23910537e-35 is the byte swapped version of 6.05202019e-01. Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Synonym standards
On Fri, Jul 27, 2012 at 9:43 AM, Derek Homeier de...@astro.physik.uni-goettingen.de wrote: thanks, that was exactly what I was looking for - together with c.TerminalIPythonApp.exec_lines = ['import sys', 'import numpy as np', 'import matplotlib as mpl', 'import matplotlib.pyplot as plt'] Note that if you do this only and don't use %pylab interactively or the --pylab flag, then you will *not* get the proper non-blocking control of the matplotlib event loop integrated with the terminal or qtconsole. In summary, following Tony's suggestion is enough to give you: - event loop integration when you do --pylab at the prompt or %pylab in ipython. - the np, mpl and plt shortcuts - no 'import *' at all. So that should be sufficient, but you should still use --pylab or %pylab to indicate to IPython that you want the mpl event loops to work in conjunction with the shell. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Synonym standards
On 27.07.2012, at 8:30PM, Fernando Perez fperez@gmail.com wrote: On Fri, Jul 27, 2012 at 9:43 AM, Derek Homeier de...@astro.physik.uni-goettingen.de wrote: thanks, that was exactly what I was looking for - together with c.TerminalIPythonApp.exec_lines = ['import sys', 'import numpy as np', 'import matplotlib as mpl', 'import matplotlib.pyplot as plt'] Note that if you do this only and don't use %pylab interactively or the --pylab flag, then you will *not* get the proper non-blocking control of the matplotlib event loop integrated with the terminal or qtconsole. In summary, following Tony's suggestion is enough to give you: - event loop integration when you do --pylab at the prompt or %pylab in ipython. - the np, mpl and plt shortcuts - no 'import *' at all. So that should be sufficient, but you should still use --pylab or %pylab to indicate to IPython that you want the mpl event loops to work in conjunction with the shell. Yes, I was aware of that, without the pylab option at least with the macosx backend windows either would not draw and refresh properly, or block the shell after a draw() or show(); that's why I was asking how to avoid the 'import *' with it. I have not used the %pylab builtin before, though. Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.where?
Hi Everybody. The bug is that no error is raised, right? The docs say where(condition, [x, y]) x, y : array_like, optional Values from which to choose. `x` and `y` need to have the same shape as `condition` In the example you gave, x was a scalar. Cheers, Andy ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.where?
On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller amuel...@ais.uni-bonn.dewrote: Hi Everybody. The bug is that no error is raised, right? The docs say where(condition, [x, y]) x, y : array_like, optional Values from which to choose. `x` and `y` need to have the same shape as `condition` In the example you gave, x was a scalar. Cheers, Andy Hmm, that is incorrect, I believe. I have used a scalar before. Maybe it works because a scalar is broadcastable to the same shape as any other N-dim array? If so, then the wording of that docstring needs to be fixed. No, I think Christopher hit it on the head. For whatever reason, the endian-ness somewhere is not being respected and causes a byte-swapped version to show up. How that happens, though, is beyond me. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.where?
On 07/27/2012 09:10 PM, Benjamin Root wrote: On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller amuel...@ais.uni-bonn.de mailto:amuel...@ais.uni-bonn.de wrote: Hi Everybody. The bug is that no error is raised, right? The docs say where(condition, [x, y]) x, y : array_like, optional Values from which to choose. `x` and `y` need to have the same shape as `condition` In the example you gave, x was a scalar. Cheers, Andy Hmm, that is incorrect, I believe. I have used a scalar before. Maybe it works because a scalar is broadcastable to the same shape as any other N-dim array? If so, then the wording of that docstring needs to be fixed. No, I think Christopher hit it on the head. For whatever reason, the endian-ness somewhere is not being respected and causes a byte-swapped version to show up. How that happens, though, is beyond me. Well, if you use np.repeat(max_net, 3) instead of max_net, it works as expected. So if you use the function as documented, it does the right thing. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in numpy.where?
On Fri, Jul 27, 2012 at 4:10 PM, Benjamin Root ben.r...@ou.edu wrote: On Fri, Jul 27, 2012 at 3:58 PM, Andreas Mueller amuel...@ais.uni-bonn.de wrote: Hi Everybody. The bug is that no error is raised, right? The docs say where(condition, [x, y]) x, y : array_like, optional Values from which to choose. `x` and `y` need to have the same shape as `condition` In the example you gave, x was a scalar. Cheers, Andy Hmm, that is incorrect, I believe. I have used a scalar before. Maybe it works because a scalar is broadcastable to the same shape as any other N-dim array? If so, then the wording of that docstring needs to be fixed. No, I think Christopher hit it on the head. For whatever reason, the endian-ness somewhere is not being respected and causes a byte-swapped version to show up. How that happens, though, is beyond me. Ben Root It may have something to do with the dtype size as well. The problem seen with, net = np.zeros(3, dtype='f4') Disappears for net = np.zeros(3, dtype='f8') and above. Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Status of NumPy and Python 3.3
On Fri, Jul 27, 2012 at 6:47 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Jul 27, 2012 at 10:43 AM, David Cournapeau courn...@gmail.com wrote: On Fri, Jul 27, 2012 at 9:28 AM, David Cournapeau courn...@gmail.com wrote: On Fri, Jul 27, 2012 at 7:30 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, I'm wondering who has tried to make NumPy work with Python 3.3. The Unicode handling was significantly improved in Python 3.3 and the array-scalar code (which assumed a certain structure for UnicodeObjects) is not working now. It would be nice to get 1.7.0 working with Python 3.3 if possible before the release. Anyone interested in tackling that little challenge? If someone has already tried it would be nice to hear your experience. Given that we're late with 1.7, I would suggest passing this to the next release, unless the fix is simple (just a change of API). I took a brief look at it, and from the errors I have seen, one is cosmetic, the other one is a bit more involved (rewriting PyArray_Scalar unicode support). While it is not difficult in nature, the current code has multiple #ifdef of Py_UNICODE_WIDE, meaning it would require multiple configurations on multiple python versions to be tested. I don't think python 3.3 support is critical - people who want to play with bet interpreters can build numpy by themselves from master, so I am -1 on integrating this into 1.7. I may have a fix within tonight for it, though, There are 2 tickets about this: http://projects.scipy.org/numpy/ticket/2145 http://projects.scipy.org/numpy/ticket/1471 I am currently working on a PR trying to fix the unicode failures: https://github.com/numpy/numpy/pull/366 It's a work in progress, I am still have some little issues, see the PR for up-to-date details. Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
