Mailman 3 December 2008 - SciPy-Dev

ANNOUNCE: ETS 3.1.0 released!
by Dave Peterson Dec. 10, 2008

Dec. 10, 2008

I'm pleased to announce that the Enthought Tool Suite (ETS) 3.1.0 has been tagged, released, and uploaded to PyPi[1]! Both source distributions (.tar.gz) and binary (.egg) for Windows have been built and uploaded to PyPi. You can update an existing ETS install to v3.1.0 like so: easy_install -U ETS==3.1.0 What is ETS? ------------------ The Enthought Tool Suite (ETS) is a collection of projects developed by members of the OSS community, including Enthought employees, which we use every day to construct custom scientific applications. It includes a wide variety of components, including: * an extensible application framework * application building blocks * 2-D and 3-D graphics libraries * scientific and math libraries * developer tools The cornerstone on which these tools rest is the Traits project, which provides explicit type declarations in Python; its features include initialization, validation, delegation, notification, and visualization of typed attributes. More information is available for all these packages from the Enthought Tool Suite development home page: http://code.enthought.com/projects/index.php -- Dave

1 0

patch: writing 1x1 cell arrays in matlab
by Thouis (Ray) Jones Dec. 9, 2008

Dec. 9, 2008

Lee Kamnetsky discovered a possible bug in mio5.py. Diff and test case attached. The second test is the one that fails and is addressed by this patch, and this is the gist of it: cells = np.ndarray((1,1),dtype=object) cells[0,0]='Hello, world' savemat(StringIO(), {'x': cells}, format='5') Ray Jones

1 0

Please help prepare the 0.7 release notes
by Jarrod Millman Dec. 9, 2008

Dec. 9, 2008

We are almost ready for 0.7.0rc1 (we just need to sort out the Numerical Recipes issues and I haven't had time to look though them yet). So I wanted to ask once more for help with preparing the release notes: http://projects.scipy.org/scipy/scipy/browser/trunk/doc/release/0.7.0-notes… There have been numerous improvements and changes. As always I would appreciate any feedback about mistakes or omissions. It would also be nice to know how many tests were in the last release and how many are there now. Highlighting major bug fixes or pointing out know issues would be very useful. I would also like to ask if anyone would be interested in stepping forward to work on something like Andrew Kuchling's "What's New in Python ....": http://docs.python.org/whatsnew/2.6.html This would be a great area to contribute. The release notes provide visibility for our developers' immense contributions of time and effort. They help provide an atmosphere of momentum, maturity, and excitement to a project. It is also a great service to users who haven't been following the trunk closely as well as other developer's who have missed what is happening in other areas of the code. It is also becomes a nice historical artifact for the future. It would be great if someone wanted to contribute in this way. Ideally, I would like to have someone who be interested in doing this for several releases of scipy and numpy. Such a person could develop a standard template for this and write some scripts to gather specific statistics (e.g., how many lines of code have changed, how many unit tests were added, what is the test coverage, what is the docstring coverage, who were the top contributors, who has increased their code contributions the most, how many new developers, etc.) Just a thought. Figure it won't happen, if I don't ask. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

4 5

Patch for writing Matlab structs with long field names
by Vebjorn Ljosa Dec. 8, 2008

Dec. 8, 2008

There is a bug in io/matlab/mio5.py: it can only write structs the file names of which are shorter than 32 characters. I am passing on a patch from Lee Kamentsky <leek(a)broad.mit.edu> that extends this to the 64 characters, which is what Matlab can handle. Thanks, Vebjorn Index: mio5.py =================================================================== --- mio5.py (revision 5227) +++ mio5.py (working copy) @@ -808,9 +808,11 @@ def write_fields(self): # write fieldnames fieldnames = [f[0] for f in self.arr.dtype.descr] - self.write_element(np.array([32], dtype='i4')) - self.write_element(np.array(fieldnames, dtype='S32'), - mdtype=miINT8) + length = max([len(fieldname) for fieldname in fieldnames])+1 + if length > 64: + raise ValueError, "Field names are restricted to 64 characters in Matlab" + self.write_element(np.array([length], dtype='i4')) + self.write_element(np.array(fieldnames, dtype='S%d'%(length)), mdtype=miINT8) A = np.atleast_2d(self.arr).flatten('F') MWG = Mat5WriterGetter(self.file_stream, self.unicode_strings)

3 6

Re: [SciPy-dev] Scipy Tutorial (and updating it)
by jh＠physics.ucf.edu Dec. 8, 2008

Dec. 8, 2008

> 2008/12/5 Pauli Virtanen <pav(a)iki.fi>: > I do not believe that preventing people from editing scipy docstrings > will improve numpy documentation in any way; it will only prevent point > fixes to Scipy docstrings (eg. people becoming annoyed with a specific > bad docstring, and fixing it). We can say instead that "concentrate on > Numpy", strongly, on the front page, and remove scipy links from the > table on the front page. This seems like a good compromise. If we see a lot of migration to systematic scipy writing (as opposed to point fixes), we can revisit. I do want the developers to get in there and write in the areas where they are expert, and to see point fixes made. > What in my opinion could help Numpy documentation now is coordination. > For example via milestones: > > - Compile a list of functions; sort it appropriately, and parcel it out > to manageable chunks (say, tens of items). > > - One possible way to parcel these could be to work in the order the > functions currently appear in the current reference guide. > > - I'd include a couple of "unimportant" functions to each milestone, > so that we don't end up with dull milestones at the end of the run. > > - Ask editors to work from top to bottom, one parcel at a time. Ditto for > reviewers. > > - I wouldn't necessarily include any deadlines, as these will slip, > which is demotivating. > > This should be fairly easy to compose, just requires putting up a new > wiki page with appropriate links and sections for this. This could also > speed up the review and QA that I feel is now not really progressing. Do we have a coherent-enough group of writers to do this? If so, I think it's a fantastic idea. What we said a few months ago was that writers looking for something to do should take the Functional List of Routines and write a section, or part of a section. That would give coherence to the text in each area, and encourage cross-referencing. > "Scott Sinclair" <scott.sinclair.za(a)gmail.com> writes: > I think that reviewing of docstrings is going to be tough to get going > because it relies on the input of people who are already heavily > involved in the project(s). Any docstring that someone feels can be > marked "ready for review" is usually pretty good anyway, we should aim > to get as many docstrings as possible to this level before getting > overly concerned about review. We've already said that our current goal is to get all functions to the state of "needs review" before pushing hard on the review, for the reasons you state. At this point, everything, finished or not, is included in the numpy releases, as it is an improvement on the past. Once everything "needs review", we push on the review, and when that's complete, we only include changes that pass review. We do have a few contributors who are mainly reviewers, and most of the reviewed functions were approved by them, I think. I have come to recognize two forms of review: content and presentation. Some functions that are clearly not well written and others that are incomplete have been marked as reviewed. My guess is that a reviewer expert in the other area missed that the presentation or content of the given item was lacking. So, when we do get to the point of review, I think we should consider requiring both kinds of review. It will slow us but will improve the product a lot. Some of our experts are not great writers and some of our great writers are not experts. This is hardly surprising, and both have a lot to contribute, but we should ensure our liabilities get caught. --jh--

3 2

#693 (Evaluating bivariate piecewise splines at arbitrary points)
by Pauli Virtanen Dec. 7, 2008

Dec. 7, 2008

Hi all, Do we want to get this: http://www.scipy.org/scipy/scipy/ticket/693 to Scipy 0.7.0, or does it need improvements etc.? It's pretty straightforward; probably the only question is whether >>> zi = spline_object.ev(xi, yi) is a good interface for getting zi[j] = spline(xi[j], yi[j]). [As opposed to BivariateSpline.__call__(x,y), which returns answers evaluated on meshgrid(x,y)] -- Pauli Virtanen

3 5

help needed with 0.7.0 release notes
by Jarrod Millman Dec. 7, 2008

Dec. 7, 2008

Hey, In preparation for the upcoming release, I have moved the release notes for SciPy into the code repository in the documentation directory: http://projects.scipy.org/scipy/scipy/browser/trunk/doc/release/0.7.0-notes… You can see the rendered version here: http://scipy.org/scipy/scipy/milestone/0.7.0 Please take a look at the release notes and let me know if you see anything missing or find any other problems. Of course, it would be even better if you would just go ahead and make any changes yourself. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

3 5

Re: [SciPy-dev] Scipy Tutorial (and updating it)
by jh＠physics.ucf.edu Dec. 6, 2008

Dec. 6, 2008

> Pauli Virtanen <pav(a)iki.fi> writes: > > Second, a (good) user manual takes a level of planning and commitment > > that has not gone into any of our documents so far. > I don't think it's fair to say that no planning has been done. I didn't! > The > content of the Numpy reference guide is based on Travis's work, and I > streamlined it by editing out the user-guidish parts. > Criticism is of course welcome, but it's more helpful to be specific. > I have seen little to no feedback on this. I'm not criticizing your work at all, Pauli. I'm saying that the document I call User Guide needs to follow a different path from any we've taken so far. I outlined this process, used widely in academic publishing, in a prior post. For example, we used it in writing this book: http://www.amazon.com/Jupiter-Satellites-Magnetosphere-Cambridge-Planetary/… The organizer held a conference at which chapter topics were discussed. She got a publisher (CUP) and then put out an RFP for additional editors and chapter teams. Teams proposed to take on chapters. She selected two more editors and they selected among the proposals for each chapter. I think a few shotgun marriages were arranged between proposal teams, etc. We (I led chapter 8, on the 1994 Shoemaker-Levy 9 comet impact) got guidelines and a latex format, and a set of (teflon-coated) deadlines. We wrote. They sent the chapters out to three reviewers. We revised, were re-reviewed, resubmitted. They sent out lists of consistency issues. We fixed them. A professional indexer went through the whole book and did the index. We sent it to Cambridge Univ. Press, which printed it. I am quite proud of both my own chapter and the degree of integration we were able to achieve across the whole volume. This is now The Book on Jupiter. I don't expect we'll start on this volume until at least two years from now, based on our rate of progress on the docstrings, but I propose we use the academic process outlined here. For our case, we don't need to have a commercial publisher (but could, with appropriate license), and we can put the chapter drafts online for a public review in addition to getting expert reviews. --jh--

2 1

numpy/scipy docs and make html
by Nils Wagner Dec. 5, 2008

Dec. 5, 2008

Hi all, A make html in numpy/doc failed (/usr/share/texmf/tex/latex/amsfonts/amssymb.sty (/usr/share/texmf/tex/latex/amsfonts/amsfonts.sty)) (/usr/share/texmf/tex/latex/tools/bm.sty) ! LaTeX Error: File `preview.sty' not found. Type X to quit or <RETURN> to proceed, or enter new name. (Default extension: sty) Enter file name: ! Emergency stop. <read *> l.13 \begin {document}^^M No pages of output. Transcript written on math.log. make: *** [html] Error 1 echo $TEXINPUT /data/home/nwagner/texmf:/usr/share/texmf find ~/texmf/ -name preview.sty /data/home/nwagner/texmf/preview/preview.sty Any idea ? Nils

2 3

I would like to contribute to the scipy documentation.
by Per.Brodtkorb＠ffi.no Dec. 5, 2008

Dec. 5, 2008

Could someone give me edit rights? My user name is pbrod. Best regards Per A

2 1