Mailman 3 May 2009 - SciPy-Dev

TABLES/STSDAS v3.10 and STScI_Python v2.8 now available]
by Christopher Hanley May 12, 2009

May 12, 2009

For those that may be interested. Chris -------- Original Message -------- Subject: [AstroPy] TABLES/STSDAS v3.10 and STScI_Python v2.8 now available Date: Tue, 12 May 2009 14:38:25 -0400 From: Warren J. Hack <hack(a)stsci.edu> To: iraf-announce(a)tucana.tuc.noao.edu, astropy(a)scipy.net, pyraf-regist(a)stsci.edu ******************************************************* TABLES/STSDAS v3.10 and STSCI_PYTHON v2.8 NOW AVAILABLE ******************************************************* The Science Software Branch of the Space Telescope Science Institute wishes to announce the availability of version 3.10 of the Space Telescope Science Data Analysis Software (STSDAS). Concurrent with the STSDAS release, we have also released v3.10 of the TABLES external package. Both of these packages are layered upon IRAF as external packages; it is therefore necessary to obtain and install IRAF (from http://iraf.noao.edu) before installing TABLES and STSDAS. STSDAS is linked against libraries in TABLES, so TABLES must be installed before STSDAS. This release of STSDAS contains changes to NICMOS, ACS, STIS, WFPC/CALWP2, COS, WFC3, and the Dither packages. This release includes the same versions of the calibration software used in the pipeline to support all active HST instruments after Servicing Mission 4, including the new instruments Wide-Field Camera 3 (WFC3) and the Cosmic Origins Spectrograph (COS). STSDAS also includes some Python-based tasks; running these requires the STScI Python Libraries to be installed (all the non-Python tasks can be used in the traditional way and do not require Python or the STScI Python libraries). These tasks can only be run from PyRAF using standard IRAF CL task syntax, or within Python scripts using Python syntax. The Science Software Branch of STScI also wishes to announce the availability of version 2.8 of STSCI_PYTHON. Stsci_python is a collection of Python modules, packages and C extensions that has been developed to provide a general astronomical data analysis infrastructure. They can be used for Python tasks that are accessible from within STSDAS when running under PyRAF or standalone from within Python. All tasks in this release of STScI_Python rely on the use of numpy for array operations. All references to numarray and Numeric have been removed from the code, with support no longer being provided for use of numarray or Numeric. This distribution continues to develop packages with tasks specific to each HST instrument, with updates being made to code for NICMOS and COS. This release also contains an updated version of Multidrizzle and PyDrizzle as used by the HST ACS and WFPC2 pipelines, along with significantly updated versions of PyFITS and PyRAF. Use of the Python tasks requires upgrading to this version of STSCI_PYTHON. No More support for numarray ============================ Numarray is no longer used by tasks within STScI_Python. Compatibility with numarray still exists in PyFITS and PyRAF in this release, but will be eliminated entirely after this release. As a result, you are advised to migrate to numpy as soon as possible, as no further support will be provided for the use of numarray. This switch to numpy represents a step towards unifying the Python scientific community in the use of a common array package. This is a very desirable outcome despite the inconvenience in making the switch. Information on making the switch to numpy from numarray can be found in this document: http://www.stsci.edu/resources/software_hardware/numarray/numarray2numpy.pdf STSCI_Python on WINDOWS ======================= This release includes a port of stsci_python that runs natively under Windows. Although IRAF is now available for running under Cygwin, PyRAF is not yet available for use under Windows. This means that, in this release, all the tasks in the STScI_Python distribution will be run under Python (or preferably, IPython) on Windows using Python syntax rather than a parameter-based interface provided by PyRAF and IRAF. The primary requirement is that the Windows executables were built against and, therefore, can run only under Python 2.5. WHERE TO OBTAIN THIS SOFTWARE ============================= STSDAS/TABLES v3.10 can be downloaded from the STSDAS web site http://www.stsci.edu/resources/software_hardware/stsdas/download Installation instructions are available on the web site. Precompiled binaries also exist for some of the ports supported by NOAO, including Sun Solaris, RedHat Linux and Mac OS X. STSCI_PYTHON v 2.8 be downloaded from the PyRAF web site http://www.stsci.edu/resources/software_hardware/pyraf/stsci_python/current… Installation instructions are available from the PyRAF web site, with support for installations on Sun Solaris, RedHat Linux, Mac OS X, and Windows. Please contact us through e-mail (help(a)stsci.edu), by telephone at (410) 338-1082. _______________________________________________ AstroPy mailing list AstroPy(a)scipy.org http://mail.scipy.org/mailman/listinfo/astropy -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338

1 0

ANN: SfePy 2009.2
by Robert Cimrman May 12, 2009

May 12, 2009

I am pleased to announce the release of SfePy 2009.2. SfePy (simple finite elements in Python) is a software, distributed under the BSD license, for solving systems of coupled partial differential equations by the finite element method. The code is based on NumPy and SciPy packages. Mailing lists, issue tracking, git repository: http://sfepy.org Home page: http://sfepy.kme.zcu.cz People who contributed to this release: Vladimir Lukes. Major improvements: - new scripts: - isfepy (interactive sfepy) - customized IPython shell for quick "compute and visualize" work - postproc.py - a script to visualize (via mayavi2) results saved in result files - probe.py - a script to probe and plot results along geometrical objects (e.g. lines, rays) intersecting the mesh - automatic html documentation generation via doxygen - extended syntax of equations to allow boundary traces of variables - fixed live plotting via multiprocessing for multi-core machines - short input syntax for LCBC conditions, fields, integrals, materials and solvers - new solvers: - Broyden and Anderson nonlinear solvers (SciPy implementation) - new mesh readers: - Nastran (.bdf) format - Abaqus ascii (.inp) - new example problems, tests and terms Applications: - phononic materials: - plotting improved - caching of eigen-problem solution and Christoffel acoustic tensor - schroedinger.py: - choose and call DFT solver via solver interface For more information on this release, see http://sfepy.googlecode.com/svn/web/releases/2009.2_RELEASE_NOTES.txt Best regards, Robert Cimrman

1 0

RFR: Nonlinear solver rewrite
by Pauli Virtanen May 11, 2009

May 11, 2009

Hi, The large-scale nonlinear equation solver (nonlin.py) rewrite is nearing completion. Git branch is here: http://github.com/pv/scipy-work/commits/ticket/791-optimize-nonlin-rewrite Review ticket is here: http://codereview.appspot.com/62059 Trac ticket is here: http://projects.scipy.org/scipy/ticket/791 You may want to try out the examples in the docstring of nonlin.py The following new features are added - Proper termination conditions - Generic framework for tolerance-controlled inexact Newton methods - Backtracking and line searches - Limited-memory Broyden methods, including SVD rank reduction in addition to more basic options - Newton-Krylov solver, using any of the solvers from scipy.sparse.linalg The new code API is mostly backward-compatible to the old one. Some methods that were not very useful are deprecated. All of the code is rewritten and refactored, aiming for easier maintenance. The API may need some tuning still; should the method_name wrappers be discarded, and the nonlin_solve(..., jacobian='foo') be the preferred interface? Note that this patchset includes some work in other parts of Scipy; these are in review separately (so don't comment on those in this ticket): - LGMRES sparse solver http://codereview.appspot.com/53096 http://github.com/pv/scipy-work/commits/lgmres - Line search refactoring http://codereview.appspot.com/52096 http://github.com/pv/scipy-work/commits/linesearch-refactor Cheers, Pauli

2 1

Question about doc editing - here the right place?
by David Goldsmith May 11, 2009

May 11, 2009

Hi, all. First, is this the right place to ask technical questions about editing the doc, or is there a sub-list for that? Second, for now, I'll ask my present question here: the "template" states "refer to variables using back-ticks, e.g. `var`," but I find that when I do so for variables that are also numpy function names (e.g., pv, nper, pmt, etc. in fv), the resulting formatting is a link, not the italics present in the function declaration; so, which takes precedence: the dictum "refer to variables using back-ticks," or the desire to have the variables appear in the same font as they do in the function declaration? Thanks! DG

2 2

adding mpfit to scipy optimize (Please respond)
by william ratcliff May 10, 2009

May 10, 2009

Hi! For a long time, there has been a standard package used by IDL users for fitting functions to data called MPFIT: http://cow.physics.wisc.edu/~craigm/idl/fitting.html <http://cow.physics.wisc.edu/%7Ecraigm/idl/fitting.html> It allows the user to limit the domain (simple box limits), fix parameters, etc. It also returns errors on the parameters based on the covariance matrix. Essentially, it translates MINPACK to IDL and adds some nice features (like the ability to fix parameters). Some time later, Mark Rivers translated this to python for use with Numeric, and Sergei Koposov migrated the code to numpy and added several bug fixes from the Numeric version of the code. We've been working with the author of the IDL package, Craig Markwardt to include the additional bug fixes which he has added. I have written a nose-test compatible test. Could someone look at it and tell me if it meets the scipy style before I continue adding more tests from Craig's test-suite for the C version of his program? Also, what else would we need to do to include this in scipy? Mark Rivers, Craig, and Sergey have agreed to a BSD license for their contributions. Thanks, William I realize that in my previous email, the attachment with the files were scrubbed. They can be found at: http://drop.io/mpfitdrop Thanks, William

4 11

2 trac instances? http://scipy.org/scipy/scikits/timeline vs http://projects.scipy.org/scikits/timeline
by josef.pktd＠gmail.com May 8, 2009

May 8, 2009

I was using an old bookmark to access the scikits trac and was surprised to see no recent updates. Are there two trac instances running? Is it possible that the old one redirects to the new? It's confusing until I figured out that I was on the wrong address. Josef

3 3

Lagrange interpolation.
by Charles R Harris May 7, 2009

May 7, 2009

Hi All, I was just looking for Lagrange interpolation in scipy and didn't find it. So I wrote my own, then found this thread http://mail.scipy.org/pipermail/scipy-user/2008-April/016407.html. Anne's version of barycentric interpolation is almost the same as the one I just wrote, and I have a fortran version of Krogh that I wrote for scipy about, oh, seven years ago ;) Anyway, I don't see Anne's routines in scipy, what happened to them? I've attached my version for comparison. BTW, the current lagrange in scipy is the interpolating polynomial, which is pretty much useless for numerical work. And the barycentric form can be differentiated, but it is work. Note that with the proper grid the barycentric form provides a good way to interpolate with chebyschev polynomials and can also be adapted for trigonometric and rational interpolation, all of which are useful. Chuck

2 2

Lagrange interpolation
by Charles R Harris May 7, 2009

May 7, 2009

Hi All, I am going to add Anne's barycentric Lagrange interpolation with some modifications to scale the weights and separate out the weight computations, which depend only on the grid, from the interpolator. I have also made the interpolation handle more general inputs. Any objections? In my experience Krogh interpolation needs to be in C to be efficient, there are too many decisions involved in finding the right path to make it fast when written in python. Barycentric interpolation also tends to be more stable than divided difference based approaches, especially with complex interpolation points. But I will take a closer look at Anne's implementation. It is somewhat scandalous that Scipy doesn't have decent polynomial interpolation after all these years. Chuck

2 1

Re: [SciPy-dev] Scipy-dev Digest, Vol 67, Issue 12
by Andrew Schein May 7, 2009

May 7, 2009

> > Date: Thu, 7 May 2009 11:49:08 -0600 > From: Charles R Harris <charlesr.harris(a)gmail.com> > Subject: Re: [SciPy-dev] fast sorting of most numpy array types > To: SciPy Developers List <scipy-dev(a)scipy.org> > > Numpy has quicksort, mergesort, and heapsort and now and then someone on > the > list suggests adding radix sort. No doubt radix is suitable for certain > types, char arrays seem a natural. But there are problems with byte order > for the different integer types and floats can become complicated. And > unlike quicksort radix sort isn't done inplace. So it isn't clear that a > radix sort is the way to go for sorting in general but it could be useful > in > some places. Do you have some time results? > Hi Charles - There are time results against glibc qsort() in the original post. The distribution of usort also provides an optimized quicksort with inlined comparisons and the capacity to test this against glibc. The "win" from inlining comparions is not as great as using radix sort. I have not timed against heap/merge sorts... since I believe these are slower on average on randomized inputs. By byte order were you referring to endianess of different architectures? This could be a deal breaker as the code is written. The usort library already consists of in-place routines. -Andy -- Andrew I. Schein www.andrewschein.com

2 1

fast sorting of most numpy array types
by Andrew Schein May 7, 2009

May 7, 2009

Hi developers - I have recently release highly optimized type-specific C routines for sorting arrays of numeric types: **http://bitbucket.org/ais/usort/wiki/Home The code was motivated in part by noting that the numpy implementation of sort appears to be a template-ized (over comparison) quicksort... and radix sort is often the better choice. Actually, it has been a few months since I looked at the numpy source, so don't quote me. The usort routines use a variety of strategies depending on the size of the array: radix sort, quick sort, insertion sort. I think the code could easily be incorporated in to numpy... and if there is interest in accepting such a change, I might find time to do it myself. Cheers, Andy -- Andrew I. Schein www.andrewschein.com

4 4