Mailman 3 November 2008 - SciPy-Dev

#331 and updating sigtoolmodules.c
by David Cournapeau Nov. 3, 2008

Nov. 3, 2008

Hi, I wanted to fix #331, and after having scratched my head, I think the code is too clever for me. I think the code could be updated and simplified quite a bit by using array iterator; it would mean that we would give up on the independance wrt python C API (Eric mentioned it in the commentary, if I believe svn blame and the comments). I just want to make sure it is not a concern anymore before rewriting the filter functions with the numpy array iterator, cheers, David

1 0

broken link
by Terrence Brannon Nov. 3, 2008

Nov. 3, 2008

At this page: http://scipy.org/Installing_SciPy/Windows The link in this sentence: """If you do not have Python installed on your system you can install the Enthought Python distribution which comes with Scipy and many other useful scientific tools""" points to a non-existent place (http://code.enthought.com/enthon/)

1 0

Re: [SciPy-dev] Timeseries Unusual Behaviour
by Pierre GM Nov. 3, 2008

Nov. 3, 2008

On Wednesday 29 October 2008 12:41:08 David Huard wrote: > Pierre, > > A similar problem occurs with fromrecords. Dates are ordered but not > the data that is passed. David, It should be fixed in SVN (r1569). Thanks again for reporting.

2 1

Technology Previews and Sphinx Docstring Annotations
by Damian Eads Nov. 3, 2008

Nov. 3, 2008

Hi there, Technology preview code is new code incorporated into the trunk of SciPy, but may also appear into a future SciPy release at our option. Such code is considered production grade and well-tested, but which also has no guarantees of a stable API to enable further improvements based on community feedback. The documentation will explicitly indicate which packages, modules, and functions are part of the technology preview. Jarrod and I had a discussion on how to best annotate the RST of the docstrings. One idea we came up with is to add a ".. techpreview" keyword for use in an info.py file (packages), module-level docstring, or function docstring. References in the index and detail documentation are footnoted "Technology preview". We'd like to get others to comment on the best way to annotate. Pauli: how easy would it be to add an extra keyword for this purpose? Thanks. Cheers, Damian ----------------------------------------------------- Damian Eads Ph.D. Student Jack Baskin School of Engineering, UCSC E2-489 1156 High Street Machine Learning Lab Santa Cruz, CA 95064 http://www.soe.ucsc.edu/~eads

1 0

percentileofscore rewrite
by Ariel Rokem Nov. 3, 2008

Nov. 3, 2008

Hello - following ticket #560 (http://scipy.org/scipy/scipy/ticket/560) I just rewrote the function scipy.stats.percentileofscore. The change can be reviewed here: http://codereview.appspot.com/7913 Note that the rewrite does something quite different than the previous version, including changes to the signature. Is this change actually an improvement? Does it make the function more/less useful? Cheers, Ariel ------------------------------------------------------ Ariel Rokem Helen Wills Neuroscience Institute 582 Minor Hall University of California, Berkeley Berkeley, CA 94720-2020 -- Tel: +1-510-6423134 -- http://argentum.ucbso.berkeley.edu/ariel ------------------------------------------------------

1 0

Re: [SciPy-dev] Generating SciPy Sphinx HTML
by jh＠physics.ucf.edu Nov. 3, 2008

Nov. 3, 2008

Sun, 02 Nov 2008 13:46:32 -0800, Damian Eads wrote: > I'm at the Berkeley sprint now trying to fix a few doc bugs. Can anyone > point me to instructions or a script for generating Sphinx HTML > documentation from the RST docstrings? [Pauli replied with instructions.] I just added Pauli's doc building instructions to the DevZone page. --jh--

1 0

Renaming fftpack to fft, removing backends
by David Cournapeau Nov. 2, 2008

Nov. 2, 2008

Hi, There are some things I would like to do for scipy.fftpack during the sprint, and I would like to know if anybody would be strongly against any one of those: renaming scipy.fftpack -> scipy.fft =================================== Rationale: fftpack is the name of an implementation (fftpack being the name of the Fortran library we use when no other fft library is available), and does not fit the convention of any other scipy top subpackage. How: For 0.7, we could rename it while keeping scipy.fftpack as an empty placeholder (like scipy.linsolve), and deprecating scipy.fftpack. Removing all backends but fftpack ================================= Rationale: we have 5 backends (fftpack, djbfft, fftw2 and 3, mkl), and none of them is complete. I would much prefer focus on one (fftpack), make it complete (for example supporting float32 type), than having 5 half implemented ones. Although, more backends mean more reliability problems for installation, distribution, support, etc... People may argue that fftw3 or MKL is faster: it is true in theory, but in practice, not so much. In particular, with the current implementation, both fftw2 and fftw3 are as fast or even slower than fftpack (because the wrappers are relatively naive, and do not use fftw effectively to get max speed). MKL is faster, but a lot of functionalities are missing for this backend. How: putting all the code not related to fftpack to a scikits or something, so people who really need the speed can use this. Since you need to compile scipy by yourself anyway for MKL, I don't see this as a huge problem. If I don't get answer within the sprint, I will proceed with the above plan, cheers, David

11 18

SciPy sprint in Stellenbosch today
by G-J van Rooyen Nov. 2, 2008

Nov. 2, 2008

OK, I post the ONLY because stefanv thought it was cool enough to send to the dev list... :P We had a SciPy sprint at the Stellenbosch University Media Lab today (a new lab that is only a year old, focusing on next-generation web tech). A number of new devs joined, including myself. Some had no experience in open source dev, source control or unit testing at all, and for them this was a great learning experience. If there's fizzy sugary caffeiny drinks and pizza, the postgrads will come :) Here's an animoto video and slideshow of the South African developers strutting their stuff: http://catpt.blogspot.com/2008/11/scipy-sprint-07-za.html One of my colleages (cover pic to the video) was very impressed with closing his first ticket! Thanks for all the support, and we look forward to being involved in future! G-J

2 1

Re: [SciPy-dev] docs.scipy.org -- new site for the documentation marathon
by jh＠physics.ucf.edu Nov. 1, 2008

Nov. 1, 2008

I like the Sphinx site! But, I like the scipy.org/Documentation URL, since docs are part of the package and not a separate project (like, say, ipython.scipy.org). We should have a consistent layout of URLs, so that things that are part of numpy/scipy are under http://scipy.org/ and things that are not might still be hosted on a scipy.org domain but are not directly under http://scipy.org/. Is it technically possible/feasible for a Moin site to (appear to) include another site underneath it? If not, I'd choose function over form, grudgingly. For the top page layout, I propose (rationale below): (No left sidebar) ------------------------------------------------------------ DOCUMENTATION EDITOR Write, review, or proof the docs! MATURE DOCUMENTS Guide to Numpy PDF book by Travis Oliphant DOCUMENT-IN-PROGRESS SNAPSHOTS Numpy Reference Guide (as of yyyy-mm-dd) PDF zipped HTML refguide glossary shortcut Numpy User Guide (as of yyyy-mm-dd) PDF zipped HTML Scipy Reference Guide (as of yyyy-mm-dd) PDF zipped HTML SEE ALSO SciPy.org all things NumPy/SciPy (bug reports, downloads, conferences, etc.) SciPy.org/Documentation more documentation not (yet) in the right format for this site SciPy.org/Cookbook live, user-contributed examples and recipes for common tasks ------------------------------------------------------------ Rationale: We have had a real problem getting a critical mass on doc writing. We rallied in the summer, but for the past two months almost no contributions have been made (click on stats to see). Originally, the only purpose of the site was editing the docs, and someone who wanted to read what was current did that through our editing infrastructure. This made it very encouraging to edit. Now, when they click on "improved docstrings" on scipy.org/Documentation, they instead go to a passive presentation of the current content, no editor. They have to go to the last link on the page to get into the editor, and the text there doesn't scream "Editor!". Until we have *at least* version 1 of each of our docs, we should keep the edit link first. I'm almost ready to say the docs in progress should *only* be accessible through the editor (which does present HTML, zipped HTML, and PDF) until we have version 1 done. We should also remove irrelevant links and text. The Developer Zone and its instructions for reporting bugs have their own section of the main web site and are not docs, so they don't belong here. The content of the left sidebar is redundant and wastes space. The download links should go under the live-doc links, as above, since this format is easier to read than that on the download page and there really isn't any other content on this page. Scipy.org is either a see-also or nonexistent, depending on whether we can get this page to appear under it. The glossary shortcut is also accomodated above. --jh--

4 4

FAIL: test_imresize (test_pilutil.TestPILUtil)
by Nils Wagner Nov. 1, 2008

Nov. 1, 2008

Hi all, Can someone reproduce the following failure ? ====================================================================== FAIL: test_imresize (test_pilutil.TestPILUtil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/numpy/testing/decorators.py", line 82, in skipper return f(*args, **kwargs) File "/usr/local/lib64/python2.5/site-packages/scipy/misc/tests/test_pilutil.py", line 24, in test_imresize assert_equal(im1.shape,(11,22)) File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 174, in assert_equal assert_equal(len(actual),len(desired),err_msg,verbose) File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 183, in assert_equal raise AssertionError(msg) AssertionError: Items are not equal: ACTUAL: 0 DESIRED: 2 ---------------------------------------------------------------------- Ran 2368 tests in 37.285s FAILED (KNOWNFAIL=2, failures=1) <nose.result.TextTestResult run=2368 errors=0 failures=1> >>> scipy.__version__ '0.7.0.dev4902' Cheers, Nils

1 0