Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On 3/21/2010 12:24 AM, Charles R Harris wrote: I really, really want to get rid of the asterisks, they are ugly and distracting (IMHO). I agree, which is why my deflist example did not use asterisks. I consider it readable and only very slightly verbose. (The blank lines are needed by reST, but the whole example is still only 14 lines long.) I also like `if` much better than ``, which I also find visually distracting. fwiw, Alan PS A more compact example: q, r if mode = 'full': - q : ndarray of float or complex, shape (M, K) - r : ndarray of float or complex, shape (K, N) r if mode = 'r': - r : ndarray of float or complex, shape (K, N) a2 if mode = 'economic': - a2 : ndarray of float or complex, shape (M, N) K = min(M, N). The diagonal and the upper triangle of `a2` contains `r`, while the rest of `a2` is undefined. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On 3/21/2010 12:47 AM, josef.p...@gmail.com wrote: dashes would be also ok, but I don't think rst would recognize them. It does. But again, a definition list (using indentation) is also a list structure. It needs no markup besides the indentation. My main problem with rst is that it doesn't allow hard line breaks, which forces some kind of markup to render lists. Not true: you can use preformatted text if you want. But of course the result in not a list environment (e.g., in HTML or LatTeX output). Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed Please define need after seeing the compact example I posted. Personally, I think reST makes the right trade-offs, minimizing markup within the constraint of being unambiguous. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On Sun, Mar 21, 2010 at 9:51 AM, Alan G Isaac ais...@american.edu wrote: On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed Please define need after seeing the compact example I posted. Personally, I think reST makes the right trade-offs, minimizing markup within the constraint of being unambiguous. I tried http://docs.scipy.org/scipy/docs/scipy.signal.signaltools.convolve/diff/4791/5687/ last night, but no version looks really nice. I didn't manage the definition list. The mode parameter description is an example for the most common case when we need to do lists in the Parameters descriptions. But I don't think we have consistent use of markup for this case until now One alternative is here: http://docs.scipy.org/scipy/docs/scipy.interpolate.rbf.Rbf/ A good example that can be used as pattern and is acceptable would be useful. Josef Alan Isaac ___ 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] Help!!! Docstrings overrun by markup crap.
On Sun, Mar 21, 2010 at 9:51 PM, Alan G Isaac ais...@american.edu wrote: On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed Please define need after seeing the compact example I posted. You need 4 blank lines in your example. Now I tried adding a description for the first argument (q) like this: q, r if mode = 'full' : - q : ndarray of float or complex, shape (M, K) Description of `q`. - r : ndarray of float or complex, shape (K, N) That doesn't work, you need yet more blank lines (try this in the wiki editor). I just changed the docstring to the following, looks much better in both plain text and html imho: q : ndarray of float or complex, optional The orthonormal matrix, of shape (M, K). Only returned if ``mode='full'``. r : ndarray of float or complex, optional The upper-triangular matrix, of shape (K, N) with K = min(M, N). Only returned when ``mode='full'`` or ``mode='r'``. a2 : ndarray of float or complex, optional Array of shape (M, N), only returned when ``mode='economic``'. The diagonal and the upper triangle of `a2` contains `r`, while the rest of the matrix is undefined. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On Sun, Mar 21, 2010 at 9:58 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Sun, Mar 21, 2010 at 9:51 PM, Alan G Isaac ais...@american.edu wrote: On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed Please define need after seeing the compact example I posted. You need 4 blank lines in your example. Now I tried adding a description for the first argument (q) like this: q, r if mode = 'full' : - q : ndarray of float or complex, shape (M, K) Description of `q`. - r : ndarray of float or complex, shape (K, N) That doesn't work, you need yet more blank lines (try this in the wiki editor). I just changed the docstring to the following, looks much better in both plain text and html imho: q : ndarray of float or complex, optional The orthonormal matrix, of shape (M, K). Only returned if ``mode='full'``. r : ndarray of float or complex, optional The upper-triangular matrix, of shape (K, N) with K = min(M, N). Only returned when ``mode='full'`` or ``mode='r'``. a2 : ndarray of float or complex, optional Array of shape (M, N), only returned when ``mode='economic``'. The diagonal and the upper triangle of `a2` contains `r`, while the rest of the matrix is undefined. This line in the code is fairly amusing by the way: # economic mode. Isn't actually economic. Economic mode is very similar to 'r' mode anyway, what's the point? Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On Sun, Mar 21, 2010 at 9:57 PM, josef.p...@gmail.com wrote: On Sun, Mar 21, 2010 at 9:51 AM, Alan G Isaac ais...@american.edu wrote: On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed Please define need after seeing the compact example I posted. Personally, I think reST makes the right trade-offs, minimizing markup within the constraint of being unambiguous. I tried http://docs.scipy.org/scipy/docs/scipy.signal.signaltools.convolve/diff/4791/5687/ last night, but no version looks really nice. I didn't manage the definition list. The mode parameter description is an example for the most common case when we need to do lists in the Parameters descriptions. But I don't think we have consistent use of markup for this case until now One alternative is here: http://docs.scipy.org/scipy/docs/scipy.interpolate.rbf.Rbf/ A good example that can be used as pattern and is acceptable would be useful. Both look sort of okay, but are abusing the syntax. What do you think about the following: 1. Do not use lists with multiple indentation levels, it just doesn't look good and should not be necessary. 2. Use dashes for simple lists. 3. List with multi-line items are broken only inside the Parameters/Returns sections. This is a bug and simply needs to be fixed. (this would fix both of your examples) Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On Sun, Mar 21, 2010 at 8:01 AM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Sun, Mar 21, 2010 at 9:58 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Mar 21, 2010 at 9:51 PM, Alan G Isaac ais...@american.eduwrote: On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed Please define need after seeing the compact example I posted. You need 4 blank lines in your example. Now I tried adding a description for the first argument (q) like this: q, r if mode = 'full' : - q : ndarray of float or complex, shape (M, K) Description of `q`. - r : ndarray of float or complex, shape (K, N) That doesn't work, you need yet more blank lines (try this in the wiki editor). I just changed the docstring to the following, looks much better in both plain text and html imho: q : ndarray of float or complex, optional The orthonormal matrix, of shape (M, K). Only returned if ``mode='full'``. r : ndarray of float or complex, optional The upper-triangular matrix, of shape (K, N) with K = min(M, N). Only returned when ``mode='full'`` or ``mode='r'``. a2 : ndarray of float or complex, optional Array of shape (M, N), only returned when ``mode='economic``'. The diagonal and the upper triangle of `a2` contains `r`, while the rest of the matrix is undefined. This line in the code is fairly amusing by the way: # economic mode. Isn't actually economic. Economic mode is very similar to 'r' mode anyway, what's the point? Economic mode is what the low level algorithm likely returns, it contains the info needed to contruct q if needed, or to efficiently apply q to different vectors without constructing q; constructing q adds to the computational and memory costs, as does pulling r out of the economic return. The situation is analogous to the LU decomposition where the natural form is to store both L and U in the original matrix. Other algorithms can then use that compact form to solve equations with different right hand sides. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On Sun, Mar 21, 2010 at 10:16 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Mar 21, 2010 at 9:57 PM, josef.p...@gmail.com wrote: On Sun, Mar 21, 2010 at 9:51 AM, Alan G Isaac ais...@american.edu wrote: On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed Please define need after seeing the compact example I posted. Personally, I think reST makes the right trade-offs, minimizing markup within the constraint of being unambiguous. I tried http://docs.scipy.org/scipy/docs/scipy.signal.signaltools.convolve/diff/4791/5687/ last night, but no version looks really nice. I didn't manage the definition list. The mode parameter description is an example for the most common case when we need to do lists in the Parameters descriptions. But I don't think we have consistent use of markup for this case until now One alternative is here: http://docs.scipy.org/scipy/docs/scipy.interpolate.rbf.Rbf/ A good example that can be used as pattern and is acceptable would be useful. Both look sort of okay, but are abusing the syntax. What do you think about the following: 1. Do not use lists with multiple indentation levels, it just doesn't look good and should not be necessary. 2. Use dashes for simple lists. both fine with me, we can convert asterisks to dashes 3. List with multi-line items are broken only inside the Parameters/Returns sections. This is a bug and simply needs to be fixed. (this would fix both of your examples) Does this mean if this bug gets fixed, then we wouldn't need the extra empty lines between list items? Currently, the rendering in the doc editor view for item lists has also wrong indentation http://docs.scipy.org/numpy/docs/numpy.ndarray.transpose/ but the html looks ok http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.transpose.html (correctly rendered definition lists might be nicer than bullet lists in html) Josef Cheers, Ralf ___ 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] Help!!! Docstrings overrun by markup crap.
On Sun, Mar 21, 2010 at 10:41 PM, josef.p...@gmail.com wrote: On Sun, Mar 21, 2010 at 10:16 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: Both look sort of okay, but are abusing the syntax. What do you think about the following: 1. Do not use lists with multiple indentation levels, it just doesn't look good and should not be necessary. 2. Use dashes for simple lists. both fine with me, we can convert asterisks to dashes 3. List with multi-line items are broken only inside the Parameters/Returns sections. This is a bug and simply needs to be fixed. (this would fix both of your examples) Does this mean if this bug gets fixed, then we wouldn't need the extra empty lines between list items? Yes. The following works in the Notes section, but not in Parameters: - item one - item two this is a multi-line item - item 3 Currently, the rendering in the doc editor view for item lists has also wrong indentation http://docs.scipy.org/numpy/docs/numpy.ndarray.transpose/ but the html looks ok http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.transpose.html Html looks fine indeed. It should still look like that once that bug is fixed. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed On Sun, Mar 21, 2010 at 9:51 PM, Alan G Isaac ais...@american.edu mailto:ais...@american.edu wrote: Please define need after seeing the compact example I posted. On 3/21/2010 9:58 AM, Ralf Gommers wrote: You need 4 blank lines in your example. Now I tried adding a description Here is the compact example I posted. q, r if mode = 'full': - q : ndarray of float or complex, shape (M, K) - r : ndarray of float or complex, shape (K, N) r if mode = 'r': - r : ndarray of float or complex, shape (K, N) a2 if mode = 'economic': - a2 : ndarray of float or complex, shape (M, N) K = min(M, N). The diagonal and the upper triangle of `a2` contains `r`, while the rest of `a2` is undefined. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [OT] Starving CPUs article featured in IEEE's ComputingNow portal
On Fri, Mar 19, 2010 at 11:18 PM, David Warde-Farley d...@cs.toronto.edu wrote: On 19-Mar-10, at 1:13 PM, Anne Archibald wrote: I'm not knocking numpy; it does (almost) the best it can. (I'm not sure of the optimality of the order in which ufuncs are executed; I think some optimizations there are possible.) But a language designed from scratch for vector calculations could certainly compile expressions into a form that would save a lot of memory accesses, particularly if an optimizer combined many lines of code. I've actually thought about whether such a thing could be done in python; I think the way to do it would be to build expression objects from variable objects, then have a single apply function that fed values in to all the variables. Hey Anne, Some folks across town from you at U de M have built just such at thing. :) http://deeplearning.net/software/theano/ It does all that, plus automatic differentiation, detection and correction of numerical instabilities, etc. Probably the most amazing thing about it is that with recent versions, you basically flip a switch and it will instead use an available CUDA- capable Nvidia GPU instead of the CPU. I'll admit, when James Bergstra initially told me about this plan to make it possible to transparently switch to running stuff on the GPU, I thought it was so ambitious that it would never happen. Then it did... The progress Theano is making is promising. I had several times a look at theano and I like the idea of code generation, especially the numpy support. I hope it may be useful for one of my projects in the future. What I couldn't figure out from the documentation is the actual performance and ease of use. Am I right with the assumption that you are not a Theano dev? Have you used Theano in a project? What are you experiences? Do you happen to know how big the computational graphs can be? Is there the possibility to have loops and if then else statements? Sorry for being a little offtopic here. Sebastian David ___ 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] Array bug with character (regression from 1.4.0)
Ryan May wrote:
The following code, which works with numpy 1.4.0, results in an error:
Python 2.6, I presume?
In [1]: import numpy as np
In [2]: v = 'm'
In [3]: dt = np.dtype('c')
In [4]: a = np.asarray(v, dt)
On SVN trunk:
ValueError: assignment to 0-d array
In [5]: np.__version__
Out[5]: '2.0.0.dev8297'
Thoughts?
Nope, but it's likely my bad. Smells a bit like the dtype 'c' has size 0 that
doesn't get automatically adjusted in the array constructor, so you end up
assigning size-1 string to size-0 array element... Which is strange sice I
don't think this particular code path has been changed at all.
One would have to follow the C execution path with gdb to find out what goes
wrong.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Array bug with character (regression from 1.4.0)
On Sun, Mar 21, 2010 at 4:08 PM, Pauli Virtanen p...@iki.fi wrote:
Ryan May wrote:
The following code, which works with numpy 1.4.0, results in an error:
Python 2.6, I presume?
In [1]: import numpy as np
In [2]: v = 'm'
In [3]: dt = np.dtype('c')
In [4]: a = np.asarray(v, dt)
On SVN trunk:
ValueError: assignment to 0-d array
In [5]: np.__version__
Out[5]: '2.0.0.dev8297'
Thoughts?
Nope, but it's likely my bad. Smells a bit like the dtype 'c' has size 0
that doesn't get automatically adjusted in the array constructor, so you end
up assigning size-1 string to size-0 array element... Which is strange sice
I don't think this particular code path has been changed at all.
One would have to follow the C execution path with gdb to find out what
goes wrong.
I was wondering if this was related to Michael's fixes for character arrays?
A little bisection might help localize the problem.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Array bug with character (regression from 1.4.0)
su, 2010-03-21 kello 16:13 -0600, Charles R Harris kirjoitti: I was wondering if this was related to Michael's fixes for character arrays? A little bisection might help localize the problem. It's a bug I introduced in r8144... I forgot one *can* assign strings to 0-d arrays, and strings are indeed one sequence type. I'm going to back that changeset out, since it was only a cosmetic fix. That particular part of code needs some cleanup (it's a bit too hairy if things like this can slip), but I don't have the time at the moment to come up with a more complete fix. Cheers, Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Array bug with character (regression from 1.4.0)
On Sun, Mar 21, 2010 at 4:29 PM, Pauli Virtanen p...@iki.fi wrote: su, 2010-03-21 kello 16:13 -0600, Charles R Harris kirjoitti: I was wondering if this was related to Michael's fixes for character arrays? A little bisection might help localize the problem. It's a bug I introduced in r8144... I forgot one *can* assign strings to 0-d arrays, and strings are indeed one sequence type. I'm going to back that changeset out, since it was only a cosmetic fix. That particular part of code needs some cleanup (it's a bit too hairy if things like this can slip), but I don't have the time at the moment to come up with a more complete fix. Lots of the code needs some cleanup ;) The first step was to reformat it -- still ongoing, I've got changes on hold for after the release -- and break it up into smaller files with some similarity of function. At some point the code needs to be documented and some macros relaced with inline functions. All macros that implement jumps should be removed and replaced by something more transparent. I'd also like to see some of the policy type stuff move up to cython, which should be easier to document and understand, not to mention making for a cleaner interface to Python. So on and so on... We could use a few more developers, especially with David getting a real job. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Array bug with character (regression from 1.4.0)
On Sun, Mar 21, 2010 at 5:29 PM, Pauli Virtanen p...@iki.fi wrote: su, 2010-03-21 kello 16:13 -0600, Charles R Harris kirjoitti: I was wondering if this was related to Michael's fixes for character arrays? A little bisection might help localize the problem. It's a bug I introduced in r8144... I forgot one *can* assign strings to 0-d arrays, and strings are indeed one sequence type. I'm going to back that changeset out, since it was only a cosmetic fix. That particular part of code needs some cleanup (it's a bit too hairy if things like this can slip), but I don't have the time at the moment to come up with a more complete fix. That fixed it for me, thanks for getting done quickly. What's amusing is that I found it because pupynere was failing to write files where a variable had an attribute that consisted of a single letter. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On Sun, Mar 21, 2010 at 8:53 AM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Sun, Mar 21, 2010 at 10:41 PM, josef.p...@gmail.com wrote: On Sun, Mar 21, 2010 at 10:16 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: Both look sort of okay, but are abusing the syntax. What do you think about the following: 1. Do not use lists with multiple indentation levels, it just doesn't look good and should not be necessary. 2. Use dashes for simple lists. both fine with me, we can convert asterisks to dashes 3. List with multi-line items are broken only inside the Parameters/Returns sections. This is a bug and simply needs to be fixed. (this would fix both of your examples) Does this mean if this bug gets fixed, then we wouldn't need the extra empty lines between list items? Yes. The following works in the Notes section, but not in Parameters: - item one - item two this is a multi-line item - item 3 Currently, the rendering in the doc editor view for item lists has also wrong indentation http://docs.scipy.org/numpy/docs/numpy.ndarray.transpose/ but the html looks ok http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.transpose.html Html looks fine indeed. It should still look like that once that bug is fixed. Could you open a ticket for this? We need to track it somewhere. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help!!! Docstrings overrun by markup crap.
On Mon, Mar 22, 2010 at 12:27 AM, Alan G Isaac ais...@american.edu wrote: On 3/21/2010 12:54 AM, Ralf Gommers wrote: too many blank lines are needed On Sun, Mar 21, 2010 at 9:51 PM, Alan G Isaac ais...@american.edu mailto:ais...@american.edu wrote: Please define need after seeing the compact example I posted. On 3/21/2010 9:58 AM, Ralf Gommers wrote: You need 4 blank lines in your example. Now I tried adding a description Here is the compact example I posted. q, r if mode = 'full': - q : ndarray of float or complex, shape (M, K) - r : ndarray of float or complex, shape (K, N) r if mode = 'r': - r : ndarray of float or complex, shape (K, N) a2 if mode = 'economic': - a2 : ndarray of float or complex, shape (M, N) K = min(M, N). The diagonal and the upper triangle of `a2` contains `r`, while the rest of `a2` is undefined. Looked at the wrong thing, apologies. I'll play with your example tonight. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.trapz() doesn't respect subclass
Hi, I found that trapz() doesn't work with subclasses: http://projects.scipy.org/numpy/ticket/1438 A simple patch (attached) to change asarray() to asanyarray() fixes the problem fine. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma fix_trapz_subclass.diff Description: Binary data ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.trapz() doesn't respect subclass
On Mon, Mar 22, 2010 at 12:49 AM, Ryan May rma...@gmail.com wrote: Hi, I found that trapz() doesn't work with subclasses: http://projects.scipy.org/numpy/ticket/1438 A simple patch (attached) to change asarray() to asanyarray() fixes the problem fine. Are you sure this function works with matrices and other subclasses? Looking only very briefly at it: the multiplication might be a problem. Josef Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ 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
