Mailman 3 July 2009 - SciPy-Dev

Test Design Question for Stats.Models Code
by Skipper Seabold July 18, 2009

July 18, 2009

Hello all, I am polishing up the generalized linear models right now for the stats.models project and I have a question about using decorators with my tests. The GLM framework has a central model with shared properties and then several variations on this model, so to test I have just as a simplified example: from numpy.testing import * DECIMAL = 4 class check_glm(object): ''' res2 results will be obtained from R or the RModelwrap ''' def test_params(self): assert_almost_equal(self.res1.params, self.res2.params, DECIMAL) def test_resids(self): assert_almost_equal(self.res1.resids, self.res2.resids, DECIMAL) class test_glm_gamma(check_glm): def __init__(self): # Preprocessing to setup results self.res1 = ResultsFromGLM self.res2 = R_Results if __name__=="__main__": run_module_suite() My question is whether I can skip, for arguments sake, test_resids depending, for example, on the class of self.res2 or because I defined the test condition as True in the test_<> class. I tried putting in the check_glm class @dec.skipif(TestCondition, "Skipping this test because of ...") def test_resids(self): ... TestCondition should be None by default, but how can I get the value of TestCondition to evaluate to True if appropriate? I have tried a few different ways, but I am a little stumped. Does this make sense/is it possible? I'm sure I'm missing something obvious, but any insights would be appreciated. Cheers, Skipper

5 5

ANN: SciPy 2009 early registration extended to July 22nd
by Jarrod Millman July 17, 2009

July 17, 2009

The early registration deadline for SciPy 2009 has been extended until Wednesday, July 22, 2009. Please register ( http://conference.scipy.org/to_register ) by this date to take advantage of the reduced early registration rate. Since we just announced the conference schedule, I was asked to provide extra time for people to register. Fortunately, we were able to get a few extra days from our vendors. But we will have to place orders next Thursday, so this is the last time we will be able to extend the deadline for registration. The conference schedule is available here: http://conference.scipy.org/schedule About the conference -------------------- SciPy 2009, the 8th Python in Science conference, will be held from August 18-23, 2009 at Caltech in Pasadena, CA, USA. The conference starts with two days of tutorials to the scientific Python tools. There will be two tracks, one for introduction of the basic tools to beginners, and one for more advanced tools. The tutorials will be followed by two days of talks. Both days of talks will begin with a keynote address. The first day’s keynote will be given by Peter Norvig, the Director of Research at Google; while, the second keynote will be delivered by Jon Guyer, a Materials Scientist in the Thermodynamics and Kinetics Group at NIST. The program committee will select the remaining talks from submissions to our call for papers. All selected talks will be included in our conference proceedings edited by the program committee. After the talks each day we will provide several rooms for impromptu birds of a feather discussions. Finally, the last two days of the conference will be used for a number of coding sprints on the major software projects in our community. For the 8th consecutive year, the conference will bring together the developers and users of the open source software stack for scientific computing with Python. Attendees have the opportunity to review the available tools and how they apply to specific problems. By providing a forum for developers to share their Python expertise with the wider commercial, academic, and research communities, this conference fosters collaboration and facilitates the sharing of software components, techniques, and a vision for high level language use in scientific computing. For further information, please visit the conference homepage: http://conference.scipy.org. Important Dates --------------- * Friday, July 3: Abstracts Due * Wednesday, July 15: Announce accepted talks, post schedule * Wednesday, July 22: Early Registration ends * Tuesday-Wednesday, August 18-19: Tutorials * Thursday-Friday, August 20-21: Conference * Saturday-Sunday, August 22-23: Sprints * Friday, September 4: Papers for proceedings due Executive Committee ------------------- * Jarrod Millman, UC Berkeley, USA (Conference Chair) * Gaël Varoquaux, INRIA Saclay, France (Program Co-Chair) * Stéfan van der Walt, University of Stellenbosch, South Africa (Program Co-Chair) * Fernando Pérez, UC Berkeley, USA (Tutorial Chair)

1 0

[ANN] Announcing the SciPy conference schedule
by Gael Varoquaux July 17, 2009

July 17, 2009

The SciPy conference committee is pleased to announce the schedule of the conference: http://conference.scipy.org/schedule This year’s program is very rich. In order to limit the number of interesting talks that we had to turn down, we decided to reduce the length of talks. Although this results in many short talks, we hope that it will foster discussions, and give new ideas. Many subjects are covered, both varying technical subject in the scientific computing spectrum, and covering a lot of different research areas. I would personally like to thank the members of the program committee, who spent time reviewing the proposed abstracts and giving the chairs feedback. Fernando Perez and the tutorial presenters are hard at work finishing planning all the details of the two-day tutorial session that will precede the conference. An introduction tutorial track and an advanced tutorial track, both covering various aspect of scientific computing in Python, presented by experts in the field, should help many people getting up to speed on the amazing technology driving this community. The SciPy 2009 program committee * Co-Chair Gaël Varoquaux, Applied Mathematics and Neuroscience, * Neurospin, CEA - INRIA Saclay (France) * Co-Chair Stéfan van der Walt, Applied Mathematics, University of * Stellenbosch (South Africa) * Michael Aivazis, Center for Advanced Computing Research, California * Institute of Technology (USA) * Brian Granger, Physics Department, California Polytechnic State * University, San Luis Obispo (USA) * Aric Hagberg, Theoretical Division, Los Alamos National Laboratory * (USA) * Konrad Hinsen, Centre de Biophysique Moléculaire, CNRS Orléans * (France) * Randall LeVeque, Mathematics, University of Washington, Seattle * (USA) * Travis Oliphant, Enthought (USA) * Prabhu Ramachandran, Department of Aerospace Engineering, IIT * Bombay (India) * Raphael Ritz, International Neuroinformatics Coordinating Facility * (Sweden) * William Stein, Mathematics, University of Washington, Seattle (USA) Conference Chair: Jarrod Millman, Neuroscience Institute, UC Berkeley (USA)

3 2

Skypecon Minutes
by David Goldsmith July 17, 2009

July 17, 2009

NumPy Doc Summer '09 Marathon July 14, 2009 Skypecon Minutes Start: 18:15 UTC End: 19:15 UTC Present: David Goldsmith (Secretary); Ralf Gommers; Joe Harrington; Jack Liddle; Stéfan van der Walt Discussions: 0) Status of current effort Joe expressed general satisfaction with the current state and momentum. Ralf opined (and no one really argued the point) that much of what is left is either “loose ends,” should be “Unimportant” if it isn’t already, or will require the contributions of persons w/ more in-depth knowledge of NumPy than the average contributor to date. This motivated the next discussion: 1) Commencement of work on SciPy doc Joe expressed the view that we should be well into the review process for NumPy before beginning work on SciPy. This led to a discussion of the “two review process,” and, mostly, its labor requirements, vis-à-vis required expertise, reviewer vetting criteria and process, etc.; subsequently, a ticket was filed requesting enhancement of the pydocweb infrastructure to support this, and development of some rough guidelines for Reviewers was assigned to David. Joe also expressed concern over the possibility that SciPy may soon (i.e., on the order of years, since the SciPy doc effort is seen as likely being of the same order) undergo a medium-to-major overhaul, and thus, perhaps, a lot of labor documenting soon-to-be obsolete material may be wasted; Stéfan countered that this shouldn’t be a great concern, because even if there is an overhaul, modules within SciPy are relatively independent of each other and not that much in the way of code will be completely discarded, and thus, mostly, if not completely, documenting SciPy as it is presently will not be wasted effort. Also on the other hand, Jack, with David and Ralf’s support, pointed out that the lack of “pedestrian” docstrings to edit in NumPy, of which SciPy has a plethora, may discourage a lot of the volunteer labor pool, perhaps resulting in another “stall” in activity. Everyone agreed that this was the greater concern, and it was resolved that work should commence on the SciPy docstring project, beginning with organization of the SciPy material into Milestones ala what we presently have for NumPy, a task which was delegated to Jack. 2) Discussed the idea of a “User Guide” And whether, for instance, SciPy and NumPy should have separate UG’s or be packaged together and designed and organized accordingly. No resolution. 3) Meeting concluded w/ a specific question Jack asked for clarification of how to document a function which is basically just a convenience function, in that it thinly wraps another function, merely setting one parameter before “relaying” its call; David noted that this is exactly analogous to the recent discussions about methods equivalent to functions, and the same solution was suggested, namely, document the wrapper function minimally, referring to the wrapped function for details; no opposing view was voiced. Next Skypecon: Wednesday, July 22, 19:00 UTC Notes: A few “drops,” but relatively minor considering the number of people participating and the technical problems we’ve had in recent Skypecons.

1 0

threaded fftw + blitz + weave
by M Trumpis July 16, 2009

July 16, 2009

I just finished reworking some code I wrote a while ago that drives FFTW in parallel for repeated transforms. My original code only operated in a restrictive manner, but I finally got around to letting it run in arbitrarily strided arrays. The idea is to plan an FFT of a certain structure on one thread, and then split the data up and apply the plan on multiple threads. (Since I work with images and like my arrays to be centered at N/2, my implementation has the threads do some change of variables magic with hairy strided pointer walking--more memory efficient than fftshift.) I'm wondering if people think this could be useful, and if it would be a small effort to bring it to scipy? here's a look at the c++ code and the weave wrapping https://cirl.berkeley.edu/trac/browser/bic/branches/rtools_weave/root/recon… https://cirl.berkeley.edu/trac/browser/bic/branches/rtools_weave/root/recon… The code is definitely working and passes comparison tests within reasonable accuracy. That said, it's sure to be rough around the edges (I'm not terribly careful coding in C++). Has: *If an N-D array is to be split up into T transforms (of any rank R <= N), and T can be split evenly into P threads, then the tool parallelizes the fft calls *inplace and out of place xforms *shifted or non-shifted xforms Hasn't: *no Microsoft threads (no clue how they work) *no real-to-complex or c2r transforms *no fftw plan caching -- other than what the fftw libs keep persistent *may not work for negatively strided arrays.. haven't checked *definitely won't work for funky strides (==0) of course

1 0

'nother goal met!
by David Goldsmith July 16, 2009

July 16, 2009

Scalar Types! (Two items need to be changed to "Unimportant" by someone who can do that, everything else "Needs Review".) DG

1 0

scipy.linalg.eigvals error on 64bit RH3 & RH4
by David Martin July 16, 2009

July 16, 2009

Has anyone else gotten these scipy.test() errors when running on RH3 and RH4 (both 64bit)? The following tests pass on RH5 64-bit and RH3,4,5 32-bit, so this seems to be a 64-bit RH issue prior to RH5. It looks like eigvals isn't returning the correct values: -David On Windows XP 32-bit: Python 2.5.4 (r254:67916, May 17 2009, 21:12:18) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from numpy import sqrt >>> from scipy.linalg import eigvals >>> a = [[1,2,3],[1,2,3],[2,5,6]] >>> w = eigvals(a) >>> exact_w = [(9+sqrt(93))/2,0,(9-sqrt(93))/2] >>> w array([ 9.32182538e+00+0.j, -9.59852072e-16+0.j, -3.21825380e-01+0.j]) >>> exact_w [9.3218253804964775, 0, -0.32182538049647746] On RH3.8 64-bit: Python 2.5.4 (r254:67916, May 20 2009, 22:57:32) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-56)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from numpy import sqrt >>> from scipy.linalg import eigvals >>> a = [[1,2,3],[1,2,3],[2,5,6]] >>> w = eigvals(a) >>> exact_w = [(9+sqrt(93))/2,0,(9-sqrt(93))/2] >>> w array([ 9.43719064+0.j, -0.11536526+0.j, -0.32182538+0.j]) >>> exact_w [9.3218253804964775, 0, -0.32182538049647746] ====================================================================== FAIL: test_simple (test_decomp.TestEig) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tester/master/lib/python2.5/site-packages/scipy/linalg/tests/test_decomp.py", line 145, in test_simple assert_array_almost_equal(w,exact_w) File "/home/tester/master/lib/python2.5/site-packages/numpy/testing/utils.py", line 537, in assert_array_almost_equal header='Arrays are not almost equal') File "/home/tester/master/lib/python2.5/site-packages/numpy/testing/utils.py", line 395, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 66.6666666667%) x: array([ 9.43719064+0.j, -0.11536526+0.j, -0.32182538+0.j]) y: array([ 9.32182538, 0. , -0.32182538]) ====================================================================== FAIL: test_simple (test_decomp.TestEigVals) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tester/master/lib/python2.5/site-packages/scipy/linalg/tests/test_decomp.py", line 114, in test_simple assert_array_almost_equal(w,exact_w) File "/home/tester/master/lib/python2.5/site-packages/numpy/testing/utils.py", line 537, in assert_array_almost_equal header='Arrays are not almost equal') File "/home/tester/master/lib/python2.5/site-packages/numpy/testing/utils.py", line 395, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 66.6666666667%) x: array([ 9.43719064+0.j, -0.11536526+0.j, -0.32182538+0.j]) y: array([ 9.32182538, 0. , -0.32182538]) ====================================================================== FAIL: test_simple_tr (test_decomp.TestEigVals) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tester/master/lib/python2.5/site-packages/scipy/linalg/tests/test_decomp.py", line 122, in test_simple_tr assert_array_almost_equal(w,exact_w) File "/home/tester/master/lib/python2.5/site-packages/numpy/testing/utils.py", line 537, in assert_array_almost_equal header='Arrays are not almost equal') File "/home/tester/master/lib/python2.5/site-packages/numpy/testing/utils.py", line 395, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 66.6666666667%) x: array([ 9.43719064+0.j, -0.11536526+0.j, -0.32182538+0.j]) y: array([ 9.32182538, 0. , -0.32182538]) ====================================================================== FAIL: test (test_speigs.TestEigs) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tester/master/lib/python2.5/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_speigs.py", line 34, in test assert_array_almost_equal(calc_vals, vals[0:nev], decimal=7) File "/home/tester/master/lib/python2.5/site-packages/numpy/testing/utils.py", line 537, in assert_array_almost_equal header='Arrays are not almost equal') File "/home/tester/master/lib/python2.5/site-packages/numpy/testing/utils.py", line 395, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([ 0.03559256, 0.73900411, 0.73525312, 1.07213911]) y: array([ 0.25819889, 0.51639778, 0.77459667, 1.03279556])

3 7

ANNOUNCEMENT: Enthought Tool Suite (ETS) v3.3.0 released
by Dave Peterson July 16, 2009

July 16, 2009

Hello, I'm pleased to announce that Enthought Tool Suite (ETS) version 3.3.0 has been tagged and released! Please see below for a partial list of changes for this release. PyPi has been updated with the release, including the availability of both Windows binaries (.egg) and source distributions (.tar.gz). A full install of ETS can be done using a command like: easy_install -U "ETS[nonets] == 3.3.0" HOWEVER, it is important to note that there are still package dependencies that are outside the scope of easy_install. Therefore, we recommend that you have the following installed prior to installing ETS: setuptools: minimum version 0.6c9 VTK: minimum version 5.0, recommended 5.2 or later And at least one of: wxPython: minimum version 2.8.7.1 PyQt: minimum version 4.4 For additional installation information, see: https://svn.enthought.com/enthought/wiki/Install What Is ETS? =========== The Enthought Tool Suite (ETS) is a collection of components developed by Enthought and the open-source community, which we use every day to construct 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 package, which provides explicit type declarations in Python; its features include initialization, validation, delegation, notification, and visualization of typed attributes. More information on ETS is available from the development home page: http://code.enthought.com/projects/index.php ETS 3.3.0 is a feature-added update to ETS 3.2.0, including numerous bug-fixes. Some of the notable changes include (sub-projects listed in alphabetical order): Chaco 3.2.0 (July 15, 2009) =========================== Enhancements ------------ * Bounded grids - Horizontal and Vertical grid line start and end points can now be set to a fixed value in data space, or to be the return value of an arbitrary callable. The start and end tick can also be configured via the data_min and data_max traits. * Added dictionary interface to ArrayPlotData * Added a Traits UI view to the ScalesAxis * Added a new chaco.overlays subpackage and a new overlay, the DataBox. * Improved appearance of PlotToolbar * Changed add_default_axis() in the plot_factory module to take an axis class as a keyword argument. * Refactored contour plots into a common base class and implemented proper event handling when their colormaps or data ranges change. * Changed default colormap on img_plot() and contour_plot() method of Plot to be Spectral instead of Jet. * Added two more color palettes to the auto color palette, and created a default_colors module. * Added CandlePlot renderer * Changed Plot Labels to able to display inside the plot area, instead of only on the outside * Added optional title attribute to plot legends * Updated all containers to respect and use the new fixed_preferred_size trait on enable.Component * New Examples: * Interval trait editor as a Chaco example (from Stefan van der Walt) * embedding an interactive Chaco plot inside a VTK RenderWindow using the new Enable VTK backend * lasso tool on an image plot * bounded grid * candle plot Fixes ----- * Fixed call signature of ShowAllTickGenerator.get_ticks() * Plot.title_font is now a delegate to the underlying PlotLabel object (from Chris Colbert) * Fixed mouse event handling bug in RangeSelection (from Stefan van der Walt) * ImagePlots now redraw when their input data changes. * Fixed cached image invalidation in colormapped image plots * Optimized ScatterPlot.map_index() when index_only is True and the index data is sorted * Changed ColormappedScatterPlot to no longer incorrectly apply the fill_alpha to the outline color * Improved date ticking heuristics in chaco.scales subpackage, specifically eliminating the bug where all times between, midnight and 1am would be formatted at too course of a time resolution. * Cleanup of various examples (titles, appearance) * The spectrum.py (audio spectrograph) example now properly closes the audio stream. Enable 3.2.0 (July 15th, 2009) ============================== enthought.enable Enhancements ----------------------------- * Added Slider and Compass widgets * Added an OverlayContainer (almost identical to the one in Chaco) * Added ImageGraphicsContextEnable class so that one can always import a Kiva Image backend-based GraphicsContextEnable * renaming marker_trait to MarkerTrait (the old name is still permitted for backwards compatibility, but should be avoided) * Moved the scatter_markers module from Chaco to Enable, so that Enable components can use MarkerTrait * Added an experimental VTK backend for Enable, along with an example * Changed SVGButtonEditor toggle to draw a SVG under the button SVG instead of drawing a plain box * Added labels for SVGButton * Improving backbuffering performance on the Mac by creating the layer context from the window context instead of from a bitmap. * Adding a "fixed_preferred_size" trait to Components, so that relative size preferences can be expressed amongst different components in a container enthought.enable Fixes ---------------------- * Improved the backend selection to match the Traits UI backend unless ETSConfig.enable_toolkit is explicitly set * Fixed demo_main() in example_support.py so that it doesn't crash IPython * Fixed RGBAColorTrait so it can be used with the null toolkit * Changed the "sys_window" color to be the same as the Traits UI "WindowColor" constant * Fixed backend_cairo's get_text_extent() implementation to match other backends enthought.kiva Enhancements --------------------------- * Added basic gradients to Kiva enthought.kiva Fixes -------------------- * Fixed Python 2.6 datatype errors * Fixed memory leak as reported in ticket 1815 * The macport test is only run on Darwin systems * Removed deprecated calls to old numpy APIs Traits 3.2.0 ============ * Implemented editable_labels attribute in the TabularEditor for enabling editing of the labels (i.e. the first column) * Saving/restoring window positions works with multiple displays of different sizes * New ProgressEditor * Changed default colors for TableEditor * Added support for HTMLEditor for QT backend using QtWebKit * Improved support for opening links in external browser from HTMLEditor * Added support for TabularEditor for QT backend * Added support for marking up the CodeEditor, including adding squiggles and dimming lines * Added SearchEditor * Improved unicode support * Changed behavior of RangeEditor text box to not auto-set * Added support in RangeEditor for specifying the method to evaluate new values. * Add DefaultOverride editor factory courtesy Stéfan van der Walt * Removed sys.exit() call from SaveHandler.exit() TraitsBackendQt 3.2.0 (July 15, 2009) ===================================== * Fixed a plethora of layout bugs * Implemented RGBColor trait * Fixed events not fired for 'custom' TextEditor * Improved the method by which the QT backend dispatches trait handlers when dispatch='ui'. Before, the code only worked when on the main application thread or a QThread. Now it works for regular Python threads too. * Fixed events not being fired correctly in TableEditor * Added support or 'click' and 'dclick' factory attributes to the TableEditor * TableEditor instances now editable * Improved FileEditor to look and act like the WX editor * Fixed missing minimize/maximize buttons for resizable dialogs * New HTMLEditor using QtWebKit * New TabularEditor * Added support for panel buttons * New SearchEditor * Added support for clipboard * Now responds to SIGINT correctly rather than raising KeyboardInterrupt TraitsBackendWX 3.2.0 (July 15, 2009) ===================================== * Fixed bug in DateEditor which would not display Feb correctly if the current date was visible and greater than the number of days in Feb * Reduced border_size from 1 to 4 for Group instances * Fixed layout issues: * Windows are now resized if they are larger than the desktop * Windows are now put in a valid location if they were opened off-screen * Windows with smaller parent are no longer opened at invalid positions with negative y values * Implemented editable_labels attribute in the TabularEditor for enabling editing of the labels (i.e. the first column) * Fix bug in ListEditor where a trait change listener would be fired when intermediate traits changed (when extended_name was of the type item1.item2.item3..) leading to a traceback. * Saving/restoring windows now works with multiple displays of different sizes * New ProgressDialog * Improved window colors to match desktop colors more closely * Replaced calls of wx.Yield() with wx.GetApp().Yield(True) * Changed default font to use system font * Fixed TabularEditor compatibility problem with wx 2.6 regarding the page-down key * Fixed bug in propagating click events in the TabularEditor to parent windows * DateEditor wx 2.6 compatability fixed * TableEditor scrollbar fixed * Improved support for opening links in external browser from HTMLEditor * Reduced the number of update events the PythonEditor fired * moved grid package from TraitsGui egg into enthought.pyface.ui.wx * moved clipboard from enthought.util.wx into pyface TraitsGUI 3.1.0 (July 15, 2009) =============================== * Removed Theming support from DockWindows. Borders and tabs are now drawn using lines instead of stretching images. * Changed default font to use the system font * Moved enthought.util.wx.clipboard to Pyface * Moved the grid package out of pyface and into pyface.ui.wx, left deprecated warnings * Improved info shown to the user if toolkits don't work as expected

1 0

bool8 link returns bool_ docstring
by David Goldsmith July 15, 2009

July 15, 2009

Hi! So, now I'm working on the Scalar Types category; perhaps this is "old news," but when I click on the link for bool8, I get the docstring for bool_; similarly for other types (e.g., cfloat and complex128 both return the docstring for complex128). Is this a "bug" or a "feature"? If the latter, may I assume that if link_type_A and link_type_B both return the docstring for type_A, then type_A is the "base" and type_B is the "alias"? Thanks! DG

1 0

Anybody to confirm a result in scipy.stats.distributions
by Pierre GM July 14, 2009

July 14, 2009

All, Could anybody in/confirm the following result ? (scipy 0.8.0.dev5845), >>> import scipy.stats.distributions as dist >>> dist.gamma(4.).cdf(dist.gamma(4.).ppf(0.25)) 0.0 I would have expected 0.25, of course. The pb seems to be >>> dist.gamma(4.).ppf(0.25) 0.0 when R gives 2.53532 Thx in advance for any help/comments P.

2 2