ANNOUNCE: ETS 3.0.0 released!

Hello,

I'm pleased to announce that ETS 3.0.0 has just been tagged and
released! Source distributions have been pushed to PyPi and over the
next couple hours, Win32 and OSX binaries will also be uploaded to PyPi.
This means you can install ETS, assuming you have the prereq software
installed, via the simple command:
easy_install ETS[nonets]

Please see the Install page on our wiki for more detailed installation
instructions:
https://svn.enthought.com/enthought/wiki/Install

Developers of ETS will find that the projects' trunks have already been
bumped up to the next version numbers so a simple "ets up" (or svn up)
should bring you up to date. Others may wish to grab a complete new
checkout via a "ets co ETS". The release branches that had been created
are now removed. The next release is currently expected to be ETS 3.0.1

-- Dave

Enthought Tool Suite
---------------------------

The Enthought Tool Suite (ETS) is a collection of components developed
by Enthought and open source participants, which we use every day to
construct custom scientific applications. It includes a wide variety of
components, including:

* an extensible application framework

more arpack errors: OSX vecLib issue?

The ARPACK wrapper tests for complex and double complex matrices have
been commented out since they fail (Bus Error) on OSX/gfortran with
the standard vecLib framework.  They do work correctly with custom
ATLAS libraries and on other architectures and operating systems.

Perhaps this could be related to gfortran ABI issues
(e.g. http://scipy.org/scipy/scipy/ticket/238 ) or some other problem
with the vecLib library?

Can anyone help here?

See test_complex_symmetric_modes() and test_complex_nonsymmetric_modes()
in test_arpack.py.  I can produce a small failing example if that
helps.

Aric

Guidelines for documenting parameter types

A few of us participating in the doc marathon
(http://sd-2116.dedibox.fr/pydocweb/wiki/Front%20Page/) have some
questions about documenting parameter types, and I thought it would be
good to get others' opinions.  If we can agree on some guidelines,
perhaps they could be incorporated into the docstring standard
(http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines#docstring-standard)?

I don't mind what we end up deciding on, but I think it's a good idea
to address these situations in the guidelines so new people know what
to do, and can feel comfortable about cleaning up someone else's
docstring to match the guidelines (if necessary). Maybe some of these
are pedantic, but I think they'll help to give the docs a more unified
feel and make sure it's always clear what parameter types are meant.

(1) When we mention types in the parameters, we are mostly using the
following abbreviations:

integer : int
float : float
boolean : bool
complex : complex
list : list
tuple : tuple

i.e. the same as the python function names for each type.  It would be
nice to say in the guidelines that these should be followed where
possible.

(2) Often it's useful to state the type of an input or returned array.
If we want to say the array returned by np.all is of type bool, what

semi-duplicated code in minpack/multipack.h files

Hi all,

In looking into (properly) fixing the uses of PyArray_FromDims in  
scipy.interpolate, I noticed that the following header files are  
nearly identical (I assume the desire to have multiple copies of the  
same file is to keep each of the scipy sub-packages completely  
independent):

scipy/integrate/multipack.h
scipy/interpolate/multipack.h
scipy/optimize/minpack.h

Anyhow, various of these what look like bug fixes which others don't.  
Also, many of the macros defined in this header are rather problematic  
in that they rely on certain variables being defined in the code  
around the macro (despite the fact that the macros have arguments).  
See. e.g.
#define SET_DIAG(ap_diag,o_diag,mode) {

which depends on a variable named 'n' being available.

Any suggestions as to what to do here? Should I try to synch up the  
files and fix the macros? This is kind of delicate stuff, in terms of  
retaining portability, etc.

Zach

scipy sandbox going, going, gone....

Hey,

In preparation for the 0.7.0 beta release, I am going to remove
scipy.sandbox.  We are approaching 8 months since it was decided to
remove it.  If you are interested in why the sandbox was created and
why it is being removed, please read this:
http://jarrodmillman.blogspot.com/2007/12/end-of-scipy-sandbox.html

Most of the sandbox code has all ready been moved somewhere else, but
there is still some code that remains.  So my plan is to create a
branch called sandbox from the trunk on Saturday.  I will then remove
the sandbox from the trunk.

Thanks,

--

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/

Fwd: scipy 32 bit tests

I also have a report from Fernando about failures on 32bit Linux.

---------- Forwarded message ----------
From: Fernando Perez <Fernando.Perez <at> berkeley.edu>
Date: Thu, Aug 14, 2008 at 2:48 PM
Subject: scipy 32 bit tests
To: Jarrod Millman <millman <at> berkeley.edu>

Hey,

on 32 bit ubuntu, we get for scipy a bunch of these:

======================================================================
ERROR: test_var_in (test_wx_spec.TestWxConverter)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/tests/test_wx_spec.py",
line 31, in setUp
   self.s = wx_spec.wx_converter()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/wx_spec.py",
line 72, in __init__
   common_base_converter.__init__(self)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/c_spec.py",
line 74, in __init__
   self.init_info()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/wx_spec.py",
line 127, in init_info
   cxxflags = get_wxconfig('cxxflags')
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/scipy/weave/wx_spec.py",
line 32, in get_wxconfig

test_blas failures

I am getting test_blas failures on 64bit Linux, but not 32bit Linux.
Is anyone else seeing this?  I would like to get these fixed before
releasing the 0.7.0b1.

>>> scipy.test()
Running unit tests for scipy
NumPy version 1.2.0.dev5629
NumPy is installed in /usr/lib64/python2.5/site-packages/numpy
SciPy version 0.7.0.dev4637
SciPy is installed in /usr/lib64/python2.5/site-packages/scipy
Python version 2.5.1 (r251:54863, Jul 10 2008, 17:25:56) [GCC 4.1.2
20070925 (Red Hat 4.1.2-33)]
nose version 0.10.3

<snip>

======================================================================
FAIL: test_asum (test_blas.TestFBLAS1Simple)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.5/site-packages/scipy/lib/blas/tests/test_blas.py",
line 60, in test_asum
    assert_almost_equal(f([3,-4,5]),12)
  File "/usr/lib64/python2.5/site-packages/numpy/testing/utils.py",
line 207, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
 ACTUAL: 0.0
 DESIRED: 12

test_arpack errors on 64bit Linux

I am getting test_arpack errors on 64bit Linux, but not 32bit Linux.
Is anyone else seeing this?  I would like to get these fixed before
releasing the 0.7.0b1.

>>> scipy.test()
Running unit tests for scipy
NumPy version 1.2.0.dev5629
NumPy is installed in /usr/lib64/python2.5/site-packages/numpy
SciPy version 0.7.0.dev4637
SciPy is installed in /usr/lib64/python2.5/site-packages/scipy
Python version 2.5.1 (r251:54863, Jul 10 2008, 17:25:56) [GCC 4.1.2
20070925 (Red Hat 4.1.2-33)]
nose version 0.10.3

<snip>

======================================================================
ERROR: test_nonsymmetric_modes (test_arpack.TestEigenNonSymmetric)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.5/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py",
line 204, in test_nonsymmetric_modes
    self.eval_evec(m,typ,k,which)
  File "/usr/lib64/python2.5/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py",
line 186, in eval_evec
    eval,evec=eigen(a,k,which=which,**kwds)
  File "/usr/lib64/python2.5/site-packages/scipy/sparse/linalg/eigen/arpack/arpack.py",
line 220, in eigen
    raise RuntimeError("Error info=%d in arpack"%info)
RuntimeError: Error info=-9 in arpack

Enhancement proposal for generic.rvs method in scipy.stats.distributions

_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev

PyArray_FromDims and friends

Hi all,

In testing out svn scipy and numpy, I noticed some run-time errors  
from scipy.interpolate because the _fitpack module's c sources use  
PyArray_FromDims and PyArray_FromDimsAndData, which are now deprecated  
in numpy svn.

I opened a ticket and made a patch for this particular case, but I'm  
not sure if there's an overall strategy (someone writes a very good  
regexp, say, and lets it loose), or if these will be fixed piecemeal.  
If the latter, here's the patch:

http://scipy.org/scipy/scipy/ticket/723

Zach

[Fwd: Re: contact info for Hiroshi Akima]

Here is the view of the publications person at ITS.
Alan Isaac

Yes, he died just before I started working here (I started in 1998). You are right that everything Mr. Akima
wrote while he was at ITS would be in the public domain because it was government work.

Sincerely,
Margaret Luebs

-----Original Message-----
From: Alan G Isaac [mailto:aisaac <at> american.edu] 
Sent: Wednesday, August 13, 2008 8:51 AM
To: Margaret Luebs
Subject: Re: contact info for Hiroshi Akima

Margaret Luebs wrote:
>  Thank you for your message to the NTIA/ITS website.  
>  Hiroshi Akima died several years ago, I believe it was in 
>  1996.

Dear Ms. Luebs,

I am very sorry to learn of his death.

During his time at the ITS, Hiroshi Akima published
a number of papers in Transactions in Mathematical
Software.  The code for these papers was archived.
(For example: http://www.netlib.org/toms/526)

Is it correct that since this code was written
while he was at the ITS, it is in the public domain?

Thank you,
Alan Isaac

_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev