[Numpy-discussion] Improving Docs on Wiki
Hi, I want to know if creating individual documentation for each numpy routine on the scipy.org wiki would, for some administrative reason (or other) be frowned upon. Here is an example of what I'd like to do for all of numpy's routines. http://www.scipy.org/sort. After each routine is properly documented there, We can have various index, category, and cross references. Oh boy :-) -Dieter ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On Fri, Mar 21, 2008 at 3:55 AM, [EMAIL PROTECTED] wrote: Hi, I want to know if creating individual documentation for each numpy routine on the scipy.org wiki would, for some administrative reason (or other) be frowned upon. Here is an example of what I'd like to do for all of numpy's routines. http://www.scipy.org/sort. Knock yourself out. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy's future (1.1 and beyond): whichdirection(s) ?
I would like to see a unification of matrices and arrays. I often do calculation which involve both array processing and linear algebra, and the current solution of having function like dot and inv is not aesthetic. Switching between array and matrix types (or using .A attribute of a matrix) is not convinient either. Nadav. -הודעה מקורית- מאת: [EMAIL PROTECTED] בשם David Cournapeau נשלח: ו 21-מרץ-08 06:35 אל: Discussion of Numerical Python נושא: [Numpy-discussion] numpy's future (1.1 and beyond): whichdirection(s) ? Hi, numpy 1.0.5 is on the way, and I was wondering about numpy's future. I myself have some ideas about what could be done; has there been any discussion behind what is on 1.1 trac's roadmap ? Some of the things I would like to see myself: - a framework for plug-in architecture, that is the ability for numpy to load/unload some libraries at runtime, plus a common api to access the functions. Example: instead of calling directly atlas/etc..., it would load the dll at runtime, so that other libraries can be loaded instead (numpy itself could load different runtimes depending on the CPU, for example: SSE vs SSE2 vs SSE3, multi-thread vs non multi-thread). That would require the ability to build loadable libraries (numscons, or a new numpy.distutils command). - a pure C core library for some common operations. For example, I myself would really like to be able to use the fft in some C extensions. Numpy has a fft, but I cannot access it from C (well, I could access the python fft from C, but that would be... awkward); same for blas/lapack. I really like the idea of a numpy split into a core C library reusable by many C extensions, and python wrappers (in C, cython, ctypes, whatever). That would be a huge work, of course, but hopefully can be done gradually and smoothly. Only having fft + some basic blas/lapack (dot, inv, det, etc...) and some basic functions (beta, gamma, digamma) would be great, for example. - a highly optimized core library for memory copy, simple addition, etc... basically, everything which can see huge improvements when using MMX/SSE and co. This is somewhat linked to point 1. This would also require more sophisticated memory allocator (aligned, etc...). What do people think about this ? Is that a direction numpy developers are interested in ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy's future (1.1 and beyond): which direction(s) ?
On Thu, Mar 20, 2008 at 9:35 PM, David Cournapeau [EMAIL PROTECTED] wrote: numpy 1.0.5 is on the way, and I was wondering about numpy's future. I myself have some ideas about what could be done; has there been any discussion behind what is on 1.1 trac's roadmap ? Some of the things I would like to see myself: snip What do people think about this ? Is that a direction numpy developers are interested in ? Hey, I don't have time to put much detail up at this point, but I have put some thought into this and will spend sometime discussing this next week--once I get back to the states and catch up on my work. Here are my two top general preferences for a 1.1 release: 1. I would like to get NumPy 1.1 out ASAP. In particular, I want to try very hard to get it released by the end of the summer. This means we will need to be very careful about how many new features we plan to add. I would much rather try to get more frequent stable releases out at this point, rather than delaying longer for more features. The more we add to the next release, the longer it will likely take to really stabilize after we release 1.1.0. If instead we get out 1.1.0 out within a few months, we may be able to start working on 1.2.0 sooner. 2. I want us to switch to using nose tests. We already did this in the SciPy trunk. Also, just a reminder: I **really** need help getting 1.0.5 out. I know that planning new features is much more interesting and fun; but if everyone can help reduce the number of bugs, we will be able to release 1.0.5 much more quickly. Before we starting working or thinking about 1.1, I would much rather see everyone spend some time helping stabilize and test the next (possibly last 1.0.x) release. Then we can start discussing and developing code for 1.1 without having the 1.0.5 release still pending. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy's future (1.1 and beyond): whichdirection(s) ?
Hi, I don't understand why an unification would simplify stuff, it would make everything so much more difficult :| Instead of dot, you would have a mult() function to multiply element by element, the same for inv(), so much less readable when using arrays when arrays are so much more general and generic than matrices. So -1 on this. Matthieu 2008/3/21, Nadav Horesh [EMAIL PROTECTED]: I would like to see a unification of matrices and arrays. I often do calculation which involve both array processing and linear algebra, and the current solution of having function like dot and inv is not aesthetic. Switching between array and matrix types (or using .A attribute of a matrix) is not convinient either. Nadav. -הודעה מקורית- מאת: [EMAIL PROTECTED] בשם David Cournapeau נשלח: ו 21-מרץ-08 06:35 אל: Discussion of Numerical Python נושא: [Numpy-discussion] numpy's future (1.1 and beyond): whichdirection(s) ? Hi, numpy 1.0.5 is on the way, and I was wondering about numpy's future. I myself have some ideas about what could be done; has there been any discussion behind what is on 1.1 trac's roadmap ? Some of the things I would like to see myself: - a framework for plug-in architecture, that is the ability for numpy to load/unload some libraries at runtime, plus a common api to access the functions. Example: instead of calling directly atlas/etc..., it would load the dll at runtime, so that other libraries can be loaded instead (numpy itself could load different runtimes depending on the CPU, for example: SSE vs SSE2 vs SSE3, multi-thread vs non multi-thread). That would require the ability to build loadable libraries (numscons, or a new numpy.distutils command). - a pure C core library for some common operations. For example, I myself would really like to be able to use the fft in some C extensions. Numpy has a fft, but I cannot access it from C (well, I could access the python fft from C, but that would be... awkward); same for blas/lapack. I really like the idea of a numpy split into a core C library reusable by many C extensions, and python wrappers (in C, cython, ctypes, whatever). That would be a huge work, of course, but hopefully can be done gradually and smoothly. Only having fft + some basic blas/lapack (dot, inv, det, etc...) and some basic functions (beta, gamma, digamma) would be great, for example. - a highly optimized core library for memory copy, simple addition, etc... basically, everything which can see huge improvements when using MMX/SSE and co. This is somewhat linked to point 1. This would also require more sophisticated memory allocator (aligned, etc...). What do people think about this ? Is that a direction numpy developers are interested in ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0.5 almost ready
I confirm that the reference count is consistent when trying the exemple given in the first post of the ticket (Ubuntu 7.10, gcc 4.1.3, Python 2.5.1 ). Matthieu 2008/3/21, Jarrod Millman [EMAIL PROTECTED]: On Thu, Mar 20, 2008 at 1:27 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: to, 2008-03-20 kello 21:09 +0100, Matthieu Brucher kirjoitti: Well, it is not completely solved. With the patch, the reference count keeps on raising, but as it is for Python scalars, it is not a problem, but the underlying problem in Py_DECREF will show up eventually and it will need to be solved. But I'm afraid I'm not intimate enough with the mecanisms of Numpys arrays to solve it. I wrote a second patch that I think fixes the problem, and it seems to work at least for the testcases I tried. Excellent! Thanks so much, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
Hi Dieter
On Fri, Mar 21, 2008 at 9:55 AM, [EMAIL PROTECTED] wrote:
I want to know if creating individual documentation for each numpy
routine on the scipy.org wiki would, for some administrative reason
(or other) be frowned upon. Here is an example of what I'd like to do
for all of numpy's routines. http://www.scipy.org/sort.
Thank you very much for contributing to NumPy. Your timing is
perfect, today being our third doc-day -- I hope others join us as
well at #scipy on freenode.net, as we improve the documentation
coverage. In a discussion with Fernando and Gael, we've come up with
some suggestions.
The wiki is a great place for users to add documentation, since it
doesn't require special permissions, but we shall run into naming
conflicts if we create top-level pages for all the numpy functions
(some also exist in scipy, for example). I have created a
NumpyDocstrings category on the wiki, and suggest that we organise the
functions underneath it according to their numpy subpackage, e.g.
scipy.org/NumpyDocstrings/core/sort
If you need to know where a function belongs, use IPython's ? to inspect it:
In [4]: np.core.sort?
[...]
File:
/Users/stefan/lib/python2.5/site-packages/numpy/core/fromnumeric.py
[...]
For these pages to be truly useful, we should re-absorb them into the
NumPy docstrings. This would be difficult to do using Moin markup, so
let's use ReST throughout. The suggested procedure is therefore:
1. Create NumpyDocstrings/subpackage/funcname
2. Start out the page with the following template:
{{{
#!rst
}}}
NumpyDocstrings
3. Copy the current docstring into the page (inside the rst section).
4. Update the docstring, using the format suggested in
http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines
From these pages, we can then automatically generate patches to the
NumPy source.
We also have a NumPy Examples List on the wiki. Many of these should
be incorporated into the docstrings as examples. Using IPython,
switch into doctest_mode:
In [3]: %doctest_mode
*** Pasting of code with or ... has been enabled.
Exception reporting mode: Plain
Doctest mode is: ON
Here you can generate examples for use in the Examples section,
while still having access to the enhanced capabilities of IPython.
These guidelines should provide us with a system which preserves but
enhances the current doctests, with the possibility of re-integrating
community contributions back into the source tree.
Thanks again for your help.
Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0.5 almost ready
Thank you, Pauli. Tested and applied in r4899. Regards Stéfan On Thu, Mar 20, 2008 at 9:27 PM, Pauli Virtanen [EMAIL PROTECTED] wrote: to, 2008-03-20 kello 21:09 +0100, Matthieu Brucher kirjoitti: Well, it is not completely solved. With the patch, the reference count keeps on raising, but as it is for Python scalars, it is not a problem, but the underlying problem in Py_DECREF will show up eventually and it will need to be solved. But I'm afraid I'm not intimate enough with the mecanisms of Numpys arrays to solve it. I wrote a second patch that I think fixes the problem, and it seems to work at least for the testcases I tried. -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help needed with numpy 10.5 release blockers
I think the bug was referring to the fact that some types have duplicate names *explicitly* containing the letter c -- as in repr(N.intc) 'type 'numpy.int32'' Is this supposed to be consistent naming scheme (i.e. any C type T is accessible as N.Tc) ? Then c float-type should consequently be named N.floatc . Futhermore, sometimes the c appears first, as in: N.clongfloat type 'numpy.complex192' N.clongdouble type 'numpy.complex192' ... and what does the p stand for in N.intp type 'numpy.int32' Otherwise please elaborate why some names like intc exist, and which exactly those are !? (BTW, the name N.single is there to make FORTRAN people feel more comfortable - right ?) Thanks, -Sebastian On Wed, Mar 19, 2008 at 5:16 PM, Matthieu Brucher [EMAIL PROTECTED] wrote: For the not blocker bugs, I think that #420 should be closed : float32 is the the C float type, isn't it ? Matthieu 2008/3/13, Jarrod Millman [EMAIL PROTECTED]: Hello, I am sure that everyone has noticed that 1.0.5 hasn't been released yet. The main issue is that when I was getting ready to tag the release I noticed that the buildbot had a few failing tests: http://buildbot.scipy.org/waterfall?show_events=false Stefan van der Walt added tickets for the failures: http://projects.scipy.org/scipy/numpy/ticket/683 http://projects.scipy.org/scipy/numpy/ticket/684 http://projects.scipy.org/scipy/numpy/ticket/686 And Chuck Harris fixed ticket #683 with in minutes (thanks!). The others are still open. Stefan and I also triaged the remaining tickets--closing several and turning others in to release blockers: http://scipy.org/scipy/numpy/query?status=newseverity=blockermilestone=1.0.5order=priority I think that it is especially important that we spend some time trying to make the 1.0.5 release rock solid. There are several important changes in the trunk so I really hope we can get these tickets resolved ASAP. I need everyone's help getting this release out. If you can help work on any of the open release blockers, please try to close them over the weekend. If you have any ideas about the tickets but aren't exactly sure how to resolve them please post a message to the list or add a comment to the ticket. I will be traveling over the weekend, so I may be off-line until Monday. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
4. Update the docstring, using the format suggested in http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines I realize this is a bit of a johnny-come-lately comment, but I was surprised to see that the list of sections does not seem to include the single most common reason I usually try to access a doc string ... the function signature. IMO, this item would ideally be the last item in a docstring so that one could quickly figure out which parameter belongs in which position, which are keywords, and what the defaults are without scrolling up multiple pages or having to mentally assemble this from a vertical list of parameters and optional parameters. Was this omission deliberate or an oversight? And more importantly, what do people think of adding it to the guidelines? Gary ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help needed with numpy 10.5 release blockers
On 21 Mar 2008, at 12:29, Sebastian Haase wrote: ... and what does the p stand for in N.intp type 'numpy.int32' It stands for pointer. An intp is an integer large enough to contain a pointer address. J. Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
read relow...
On Fri, Mar 21, 2008 at 11:21 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
Hi Dieter
On Fri, Mar 21, 2008 at 9:55 AM, [EMAIL PROTECTED] wrote:
I want to know if creating individual documentation for each numpy
routine on the scipy.org wiki would, for some administrative reason
(or other) be frowned upon. Here is an example of what I'd like to do
for all of numpy's routines. http://www.scipy.org/sort.
Thank you very much for contributing to NumPy. Your timing is
perfect, today being our third doc-day -- I hope others join us as
well at #scipy on freenode.net, as we improve the documentation
coverage. In a discussion with Fernando and Gael, we've come up with
some suggestions.
The wiki is a great place for users to add documentation, since it
doesn't require special permissions, but we shall run into naming
conflicts if we create top-level pages for all the numpy functions
(some also exist in scipy, for example). I have created a
NumpyDocstrings category on the wiki, and suggest that we organise the
functions underneath it according to their numpy subpackage, e.g.
scipy.org/NumpyDocstrings/core/sort
If you need to know where a function belongs, use IPython's ? to inspect it:
In [4]: np.core.sort?
[...]
File:
/Users/stefan/lib/python2.5/site-packages/numpy/core/fromnumeric.py
[...]
Comment: I have read the module- or directory-name core many times
on this list, however: Who really knows where a given functions
belongs ? Isn't that mostly only the numpy svn commiters ?
In other words, using only the python side of numpy, someone (like
myself) would NOT know that sort is inside core !
Also: since import numpy as N; N.sort refers already to that same sort:
N.core.sort
function sort at 0x01BACB30
N.sort
function sort at 0x01BACB30
I would prefer not to require core sub-sub-page.
Instead, every name X that is accessible as N.X should be
documented without extra sub-page.
My 2 cents.
Thanks,
Sebastian
For these pages to be truly useful, we should re-absorb them into the
NumPy docstrings. This would be difficult to do using Moin markup, so
let's use ReST throughout. The suggested procedure is therefore:
1. Create NumpyDocstrings/subpackage/funcname
2. Start out the page with the following template:
{{{
#!rst
}}}
NumpyDocstrings
3. Copy the current docstring into the page (inside the rst section).
4. Update the docstring, using the format suggested in
http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines
From these pages, we can then automatically generate patches to the
NumPy source.
We also have a NumPy Examples List on the wiki. Many of these should
be incorporated into the docstrings as examples. Using IPython,
switch into doctest_mode:
In [3]: %doctest_mode
*** Pasting of code with or ... has been enabled.
Exception reporting mode: Plain
Doctest mode is: ON
Here you can generate examples for use in the Examples section,
while still having access to the enhanced capabilities of IPython.
These guidelines should provide us with a system which preserves but
enhances the current doctests, with the possibility of re-integrating
community contributions back into the source tree.
Thanks again for your help.
Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On Fri, Mar 21, 2008 at 8:54 AM, Sebastian Haase [EMAIL PROTECTED] wrote: read relow... NumpyDocstrings category on the wiki, and suggest that we organise the functions underneath it according to their numpy subpackage, e.g. scipy.org/NumpyDocstrings/core/sort If you need to know where a function belongs, use IPython's ? to inspect it: In [4]: np.core.sort? [...] File: /Users/stefan/lib/python2.5/site-packages/numpy/core/fromnumeric.py [...] Comment: I have read the module- or directory-name core many times on this list, however: Who really knows where a given functions belongs ? Isn't that mostly only the numpy svn commiters ? In other words, using only the python side of numpy, someone (like myself) would NOT know that sort is inside core ! Also: since import numpy as N; N.sort refers already to that same sort: N.core.sort function sort at 0x01BACB30 N.sort function sort at 0x01BACB30 I would prefer not to require core sub-sub-page. Instead, every name X that is accessible as N.X should be documented without extra sub-page. My 2 cents. Thanks, Sebastian Thats just a for placement. We can create all sorts of direct indexes, categories and cross-references, etc... -dieter ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On 21/03/2008, Sebastian Haase [EMAIL PROTECTED] wrote: Comment: I have read the module- or directory-name core many times on this list, however: Who really knows where a given functions belongs ? Isn't that mostly only the numpy svn commiters ? In other words, using only the python side of numpy, someone (like myself) would NOT know that sort is inside core ! Also: since import numpy as N; N.sort refers already to that same sort: N.core.sort function sort at 0x01BACB30 N.sort function sort at 0x01BACB30 I would prefer not to require core sub-sub-page. Instead, every name X that is accessible as N.X should be documented without extra sub-page. I don't have a solution, but I would like to complain about numpy's flat namespace. Perhaps we're stuck with it now, but it's very difficult to find the right function. In scipy, I can find the right numerical integration by importsing scipy.integrate and using tab completion, But in numpy, everything is loaded into the base namespace, so tab completion gets me an overwhelming 502 possibilities. That's why there's a numpy functions by category but no scipy functions by category - scipy functions are already by category. Is it perhaps possible to make all numpy functions accessible in submodules (in addition to in numpy, for backwards compatibility) and then promote accessing them that way? Are they already? If so how do I find out what the submodules are? Thanks, Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: I would like to see a unification of matrices and arrays. I often do calculation which involve both array processing and linear algebra, and the current solution of having function like dot and inv is not aesthetic. Switching between array and matrix types (or using .A attribute of a matrix) is not convinient either. Use ``asmatrix``. (Does not copy.) After that the only needed unification I have encountered is that iteration over a matrix should return arrays (not matrices). I believe this is under consideration for 1.1. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On Fri, Mar 21, 2008 at 1:54 PM, Sebastian Haase [EMAIL PROTECTED] wrote: read relow... On Fri, Mar 21, 2008 at 11:21 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Hi Dieter On Fri, Mar 21, 2008 at 9:55 AM, [EMAIL PROTECTED] wrote: I want to know if creating individual documentation for each numpy routine on the scipy.org wiki would, for some administrative reason (or other) be frowned upon. Here is an example of what I'd like to do for all of numpy's routines. http://www.scipy.org/sort. Thank you very much for contributing to NumPy. Your timing is perfect, today being our third doc-day -- I hope others join us as well at #scipy on freenode.net, as we improve the documentation coverage. In a discussion with Fernando and Gael, we've come up with some suggestions. The wiki is a great place for users to add documentation, since it doesn't require special permissions, but we shall run into naming conflicts if we create top-level pages for all the numpy functions (some also exist in scipy, for example). I have created a NumpyDocstrings category on the wiki, and suggest that we organise the functions underneath it according to their numpy subpackage, e.g. scipy.org/NumpyDocstrings/core/sort If you need to know where a function belongs, use IPython's ? to inspect it: In [4]: np.core.sort? [...] File: /Users/stefan/lib/python2.5/site-packages/numpy/core/fromnumeric.py [...] Comment: I have read the module- or directory-name core many times on this list, however: Who really knows where a given functions belongs ? Isn't that mostly only the numpy svn commiters ? In other words, using only the python side of numpy, someone (like myself) would NOT know that sort is inside core ! The idea is to merge the docstrings back into the source, so that you can simply do numpy.sort? in IPython and see the latest updated version. For that purpose, you don't need to know where the sort method is located. We do, however, need to know in order to have some sane organisation of the documentation on the wiki. From a user's perspective, other alternatives include doing a wiki search, or following my earlier advice and using ? in IPython to see where the function is located. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
Hi Gary On Fri, Mar 21, 2008 at 12:53 PM, Gary Strangman [EMAIL PROTECTED] wrote: 4. Update the docstring, using the format suggested in http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines I realize this is a bit of a johnny-come-lately comment, but I was surprised to see that the list of sections does not seem to include the single most common reason I usually try to access a doc string ... the function signature. IMO, this item would ideally be the last item in a docstring so that one could quickly figure out which parameter belongs in which position, which are keywords, and what the defaults are without scrolling up multiple pages or having to mentally assemble this from a vertical list of parameters and optional parameters. Was this omission deliberate or an oversight? And more importantly, what do people think of adding it to the guidelines? No, this is not an oversight but a way to avoid duplicating the same information. In IPython, use the ? to view the docstring, and the first thing you'll see is the function signature. For C functions we do include the signature, since it isn't shown. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On Fri, Mar 21, 2008 at 2:47 PM, Anne Archibald [EMAIL PROTECTED] wrote: On 21/03/2008, Sebastian Haase [EMAIL PROTECTED] wrote: Comment: I have read the module- or directory-name core many times on this list, however: Who really knows where a given functions belongs ? Isn't that mostly only the numpy svn commiters ? In other words, using only the python side of numpy, someone (like myself) would NOT know that sort is inside core ! Also: since import numpy as N; N.sort refers already to that same sort: N.core.sort function sort at 0x01BACB30 N.sort function sort at 0x01BACB30 I would prefer not to require core sub-sub-page. Instead, every name X that is accessible as N.X should be documented without extra sub-page. I don't have a solution, but I would like to complain about numpy's flat namespace. Perhaps we're stuck with it now, but it's very difficult to find the right function. In scipy, I can find the right numerical integration by importsing scipy.integrate and using tab completion, But in numpy, everything is loaded into the base namespace, so tab completion gets me an overwhelming 502 possibilities. That's why there's a numpy functions by category but no scipy functions by category - scipy functions are already by category. Is it perhaps possible to make all numpy functions accessible in submodules (in addition to in numpy, for backwards compatibility) and then promote accessing them that way? Are they already? If so how do I find out what the submodules are? We should definately discuss and consider this proposal for 1.1. Do you have a suggested organisation in mind? Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On 21/03/2008, Stéfan van der Walt [EMAIL PROTECTED] wrote: On Fri, Mar 21, 2008 at 2:47 PM, Anne Archibald [EMAIL PROTECTED] wrote: Is it perhaps possible to make all numpy functions accessible in submodules (in addition to in numpy, for backwards compatibility) and then promote accessing them that way? Are they already? If so how do I find out what the submodules are? We should definately discuss and consider this proposal for 1.1. Do you have a suggested organisation in mind? Not exactly. What do people think of the way I organized the numpy functions by category page? Apart from the sore-thumb other category, it does seem like the kind of grouping we might hope for. Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy's future (1.1 and beyond): which direction(s) ?
David Cournapeau wrote: Hi, numpy 1.0.5 is on the way, and I was wondering about numpy's future. I myself have some ideas about what could be done; has there been any discussion behind what is on 1.1 trac's roadmap ? Some of the things I would like to see myself: - a framework for plug-in architecture, that is the ability for numpy to load/unload some libraries at runtime, plus a common api to access the functions. Example: instead of calling directly atlas/etc..., it would load the dll at runtime, so that other libraries can be loaded instead (numpy itself could load different runtimes depending on the CPU, for example: SSE vs SSE2 vs SSE3, multi-thread vs non multi-thread). That would require the ability to build loadable libraries (numscons, or a new numpy.distutils command). - a pure C core library for some common operations. For example, I myself would really like to be able to use the fft in some C extensions. Numpy has a fft, but I cannot access it from C (well, I could access the python fft from C, but that would be... awkward); same for blas/lapack. I really like the idea of a numpy split into a core C library reusable by many C extensions, and python wrappers (in C, cython, ctypes, whatever). That would be a huge work, of course, but hopefully can be done gradually and smoothly. Only having fft + some basic blas/lapack (dot, inv, det, etc...) and some basic functions (beta, gamma, digamma) would be great, for example. - a highly optimized core library for memory copy, simple addition, etc... basically, everything which can see huge improvements when using MMX/SSE and co. This is somewhat linked to point 1. This would also require more sophisticated memory allocator (aligned, etc...). What do people think about this ? Is that a direction numpy developers are interested in ? cheers, David Looks great :) Something like http://idlastro.gsfc.nasa.gov/idl_html_help/TOTAL.html (Thread Pool Keywords) would be nice. A total like function could be a great pathfinder a put threads into numpy keeping the things as simple as they should remain. Not sure we need that is numpy in 1.1 but IMHO we need that in a near future (because every array oriented libs are now threaded). Xavier ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On Fri, Mar 21, 2008 at 5:00 PM, Anne Archibald [EMAIL PROTECTED] wrote: On 21/03/2008, Stéfan van der Walt [EMAIL PROTECTED] wrote: On Fri, Mar 21, 2008 at 2:47 PM, Anne Archibald [EMAIL PROTECTED] wrote: Is it perhaps possible to make all numpy functions accessible in submodules (in addition to in numpy, for backwards compatibility) and then promote accessing them that way? Are they already? If so how do I find out what the submodules are? We should definately discuss and consider this proposal for 1.1. Do you have a suggested organisation in mind? Not exactly. What do people think of the way I organized the numpy functions by category page? Apart from the sore-thumb other category, it does seem like the kind of grouping we might hope for. I can see categories 1 through 4 being one submodule, and the rest as they are. Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug with with fill_values in masked arrays?
Pierre GM wrote: This sucks to the point of feeling like a bug :-( It is not. Ignoring the fill value of masked array feels like a bug to me... Why is it desirable for it to behave like this? Because that way, you can compare anything to masked and see whether a value is masked or not. Anyway, in your case, it's just mean your value is masked. You don't care about the filling_value for this one. Where I cared was when trying to do a filled line plot in matplotlib and the nans, rather than being omitted, were being shown on the y-axis at 99, totally wrecking the plot. I'll buy your argument *iff* the masked arrays used the fill value from the parent ma. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug with with fill_values in masked arrays?
Pierre GM wrote: On Wednesday 19 March 2008 19:47:37 Matt Knox wrote: 1. why am I not getting my NaN's back? Because they're gone when you create your masked array. Really? At least one other post has disagreed with that. And it does seem odd that a value, even if it's a nan, would be destroyed... The idea here is to get rid of the nan in your data No, it's to mask them, otherwise I would have used a normal array, not a ma. to avoid potential problems while keeping track of where the nans were in the first place. ...like plotting them on a graph, which the current behaviour makes unworkable, that you end up doing a myarray.filled(0) to get around it, with imperfect results. So, the .data part of your masked array should be nan-free, Why? Surely that should be the source data, of which nan is a valid part? and the mask tells you where the nans were. Right, but why when the masked array is cast back to a list of numbers if the fill_value of the ma not respected? 2. why is the wrong fill value being used here? the second element in the array iteration here is actually the numpy.ma.masked constant, which always has the same fill value... ...and that's a bug. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
Is it perhaps possible to make all numpy functions accessible in submodules (in addition to in numpy, for backwards compatibility) and then promote accessing them that way? I would caution on breaking functionality out into too many categories. It is *very* cumbersome to constantly import little groups of functions to get anything done, and it presents a particular learning-curve hurdle for students. Unless you load into the top-level namespace, which I discourage, it also gets cumbersome to be typing N.X.Y.Z.sort(), because it means you have to memorize that sort() is in N.X.Y.Z but sinc() is in N.A.B.C. Your thinking also gets removed from the verb you are familiar with. The fewer useless adornments code has, the better. It's also hard to find stuff if it's not loaded, and when you get to subgroups of subgroups, there is no easy way even to know that something exists. For example, if you have scipy.x.y, and you're not an advanced enough user to know that y is related to x (say, filtering as a subcategory of fft), you hunt around for an hour and then say, sheesh, scipy can't even filter, when of course it can, you just didn't think to load the fft package. (I know this isn't the structure for these specific topics, but you get the idea). You can waste hours this way, especially if you find it embarrassing to ask for help, which many do. What you have brought up is really a documentation problem: how do I find the name of the routine I want? Languages like IDL have documentation search capabilities that we don't yet have. They also have indexes of related routines in both printed form and online. We need these, they're not too hard to do, and if plans work out, they'll be done as part of a project I'm putting together for the summer (stay tuned for an announcement and request for help in the coming weeks). There is value in python's namespace capability, but I find that it's more in the vein of allowing separate groups to develop functions with sensible names and not worry about a conflict. When people make numerous tiny categories, it becomes a memorization and extra typing exercise, and it steepens the learning curve substantially. We can and will break these functions out into small categories, but it's much better to do it in lists that you'll be able to call up rather than in the structure of the language. --jh-- ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Fri, 21 Mar 2008, Stéfan van der Walt apparently wrote: The last I remember, we considered adding RowVector, ColumnVector and letting slices out of a matrix either be one of those or a matrix itself. There was a subsequent discussion. I simply don't see a Matrix as a container of ndarrays That is hardly an argument. Remember, any indexing that when applied to an 2d array would produce a 2d array will when applied to a matrix still produce a matrix. This is really just principle of least surprise. Or, if you want a complementary way of looking at it, it is keeping as much of the natural behavior of the ndarray as possible while adding convenient submatrices, matrix multiplication, and inverse. Cheers, Alan Isaac PS Are you a *user* of matrices? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Import numeric error
Hello, I have installed numpy-1.0.4.win32-py2.5 on windows machine for python 2.5.1.But when I enter command import Numeric I get following error: Traceback (most recent call last): File pyshell#16, line 1, in module import Numeric ImportError: No module named Numeric Can anybody please help me to remove this error? Thank You. Aswad ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
But asmatrix returns a matrix object and any subsequent operation of it returns a matrix. What I am thinking about is a convenient way to apply matrix operation on an array. BTW, A matrix is just a rank 2 tensor, so matrix (tensor) algebra can be applied to an arbitrary rank tensor, for example APL's . operator. Nadav. -הודעה מקורית- מאת: [EMAIL PROTECTED] בשם Alan G Isaac נשלח: ו 21-מרץ-08 16:23 אל: Discussion of Numerical Python נושא: Re: [Numpy-discussion] matrices in 1.1 On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: I would like to see a unification of matrices and arrays. I often do calculation which involve both array processing and linear algebra, and the current solution of having function like dot and inv is not aesthetic. Switching between array and matrix types (or using .A attribute of a matrix) is not convinient either. Use ``asmatrix``. (Does not copy.) After that the only needed unification I have encountered is that iteration over a matrix should return arrays (not matrices). I believe this is under consideration for 1.1. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion winmail.dat___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
pe, 2008-03-21 kello 07:53 -0400, Gary Strangman kirjoitti: 4. Update the docstring, using the format suggested in http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines I realize this is a bit of a johnny-come-lately comment, but I was surprised to see that the list of sections does not seem to include the single most common reason I usually try to access a doc string ... the function signature. The function signature is automatically determined and shown for Python functions, both by help() and IPython ? or most tools that do generate docs from docstrings, adding it also to the docstring is extraneous. For functions implemented in C in extension modules, help() cannot find the signature automatically. However, the CodingStyleGuidelines does say that in this case including the function signature to the documentation is mandatory. -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines I realize this is a bit of a johnny-come-lately comment, but I was surprised to see that the list of sections does not seem to include the single most common reason I usually try to access a doc string ... the function signature. The function signature is automatically determined and shown for Python functions, both by help() and IPython ? or most tools that do generate docs from docstrings, adding it also to the docstring is extraneous. For functions implemented in C in extension modules, help() cannot find the signature automatically. However, the CodingStyleGuidelines does say that in this case including the function signature to the documentation is mandatory. Fair enough. I guess I'm just old-school ... standard python shell and not-infrequently directly-accessing the __doc__ attribute, which does not provide a function signature. Time for an ol' dog to learn new habits ... G ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
Charles R Harris wrote: On Fri, Mar 21, 2008 at 1:57 PM, Alan G Isaac [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: But asmatrix returns a matrix object and any subsequent operation of it returns a matrix. What I am thinking about is a convenient way to apply matrix operation on an array. I suspect what you are really wanting is a way for NumPy to define new operators ... I still kinda like the idea of using the call operator for matrix multiplication, i.e. A(v) := dot(A,v). Interesting idea.I kind of like that too. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
One problem with the matrix class is that it follows matlab way too much. For example: a = arange(9).reshape(3,3) A = asmatrix(a) v = arange(3) dot(a, v) array([ 5, 14, 23]) A*v Traceback (most recent call last): File pyshell#15, line 1, in module A*v File C:\Python25\lib\site-packages\numpy\core\defmatrix.py, line 157, in __mul__ return N.dot(self, asmatrix(other)) ValueError: objects are not aligned I do a lot of colour image processing. Most of the time I treat an image as a MxNx3 array, but some time I have to do matrix/ vector operations like colour-space conversion. In these cases the dot function becomes very handy (better then Matlab matrix multiplication), since I can write: new_image = dot(old_image, A) where A is either a 3x3 matrix or a length 3 vector. The result is that my code is cluttered with a lot of dots, and the matrix class can not help much. It is possible that my case is special and does not justify a special attention, but if many of us do colour/spectral imaging, or other type of high-rank tensors algebra, there could be a case to give numpy an edge. Nadav. -הודעה מקורית- מאת: [EMAIL PROTECTED] בשם Travis E. Oliphant נשלח: ש 22-מרץ-08 01:12 אל: Discussion of Numerical Python נושא: Re: [Numpy-discussion] matrices in 1.1 Charles R Harris wrote: On Fri, Mar 21, 2008 at 1:57 PM, Alan G Isaac [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Nadav Horesh apparently wrote: But asmatrix returns a matrix object and any subsequent operation of it returns a matrix. What I am thinking about is a convenient way to apply matrix operation on an array. I suspect what you are really wanting is a way for NumPy to define new operators ... I still kinda like the idea of using the call operator for matrix multiplication, i.e. A(v) := dot(A,v). Interesting idea.I kind of like that too. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion winmail.dat___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] bug with with fill_values in masked arrays?
On Friday 21 March 2008 12:52:45 Chris Withers wrote: Pierre GM wrote: This sucks to the point of feeling like a bug :-( It is not. Ignoring the fill value of masked array feels like a bug to me... You're right with masked arrays, but here we're talking the masked singleton, a special value. Where I cared was when trying to do a filled line plot in matplotlib and the nans, rather than being omitted, were being shown on the y-axis at 99, totally wrecking the plot. You're losing me there. Send a simple example/script so that I can have a better idea of what you're trying to do. I'll buy your argument *iff* the masked arrays used the fill value from the parent ma. What parent ma ? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrices in 1.1
On Sat, 22 Mar 2008, Nadav Horesh apparently wrote: A*v ... ValueError: objects are not aligned This is just how I want matrices to act! If A is m׳n, then v should be n׳1 for A*v to be defined. Anything else is trouble waiting to happen. But it seems that Charles's proposal would make life more convenient for you... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] dunno what array operation I'm looking for...
Hi All, Say I have an array like: measurements = array([100,109,115,117]) What do I do to it to get: array([9, 6, 2]) Is the following really the best way? result = [] for i in range(1,len(measurements)): ... result.append(measurements[i]-measurements[i-1]) ... array(result) array([9, 6, 2]) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dunno what array operation I'm looking for...
numpy.diff See http://www.scipy.org/Numpy_Example_List J. On 22 Mar 2008, at 03:43, Chris Withers wrote: Hi All, Say I have an array like: measurements = array([100,109,115,117]) What do I do to it to get: array([9, 6, 2]) Is the following really the best way? result = [] for i in range(1,len(measurements)): ... result.append(measurements[i]-measurements[i-1]) ... array(result) array([9, 6, 2]) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] dunno what array operation I'm looking for...
Try result = A[1:] - A[:-1] --Hoyt On Fri, Mar 21, 2008 at 7:43 PM, Chris Withers [EMAIL PROTECTED] wrote: Hi All, Say I have an array like: measurements = array([100,109,115,117]) What do I do to it to get: array([9, 6, 2]) Is the following really the best way? result = [] for i in range(1,len(measurements)): ... result.append(measurements[i]-measurements[i-1]) ... array(result) array([9, 6, 2]) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Improving Docs on Wiki
On 21 Mar 2008, at 18:22, Joe Harrington wrote:
What you have brought up is really a documentation problem: how do I
find the name of the routine I want?
One way of dealing with this, could be the implementation of a doc()
function in numpy that helps you to find what you want. A (still
fairly basic) version of such a doc() function is given below. It
understands the unix-like wildcards * and ?, and it will also find
numpy classes/functions in the subpackages linalg, fft, and random. If
it finds several possibilities it lists them, if only 1 match is
found, the docstring is immediately given. As an example:
doc(*inv)
numpy.linalg.inv
numpy.linalg.pinv
numpy.linalg.tensorinv
It's should not be difficult to improve doc() by letting it also
search in the docstrings, or by letting it respond intelligently to
some magic search terms like e.g. category names.
Cheers,
Joris
---
import numpy
from inspect import getdoc
import re
def doc(searchstr):
searchstr = searchstr.strip().replace('*','\w*').replace('?','\w')
pattern = re.compile('^'+searchstr+'$')
results = []
for package in [numpy, numpy.linalg, numpy.fft, numpy.random]:
searchlist = [a for a in dir(package) if a[0] != '_']
results += [package.__name__ + . + s for s in searchlist if
pattern.search(s) != None]
if len(results) == 0:
print Sorry, no matches
elif len(results) == 1:
print results[0]
mod = numpy
components = results[0].split('.')
for comp in components[1:]:
mod = getattr(mod, comp)
docstring = getdoc(mod)
if docstring is not None:
print docstring
else:
print results[0] + exists, but no docstring was found
else:
for s in results:
print s
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Vectorize leak fixed (and sage-reported leak fixed as well).
Hello all, Much thanks is deserved by the people who have been chasing down and fixing reference count problems in NumPy. Two of them are related to object arrays. So, if you have been having memory leak problems with object arrays (vectorize uses object arrays, BTW), you should try out the latest SVN of NumPy to see if they fix your problems. Hopefully, NumPy 1.0.5 will come out sometime next week so that everybody can enjoy a more memory-conscious NumPy. The vectorize-related leak was a particularly silly one which led to casting for simple cases actually doing more work instead of less (this led inexorably to leaks whenever object arrays were cast to other types). Best regards, -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Vectorize leak fixed (and sage-reported leak fixed as well).
Travis E. Oliphant wrote: Hello all, Much thanks is deserved by the people who have been chasing down and fixing reference count problems in NumPy. Two of them are related to object arrays. So, if you have been having memory leak problems with object arrays (vectorize uses object arrays, BTW), you should try out the latest SVN of NumPy to see if they fix your problems. Hopefully, NumPy 1.0.5 will come out sometime next week so that everybody can enjoy a more memory-conscious NumPy. The vectorize-related leak was a particularly silly one which led to casting for simple cases actually doing more work instead of less (this led inexorably to leaks whenever object arrays were cast to other types). Best regards, -Travis Hi Tavis, list, excellent. We will upgrade then officially once 1.0.5 is out. I will do some testing the 1.0.5svn to verify that the leak is actually gone - not that we don't trust you :) Cheers, Michael ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
