David Cournapeau | 1 Jul 2008 05:31
Picon
Picon

Re: Install error on RHEL5

Michael Hearne wrote:
> I just finished an install of numpy/scipy/matplotlib on a 64-bit RHEL5 
> system, and am now trying to replicate that on a 32-bit system.  So far, 
> there are two differences:
>
> 1) fftw3 is not available through yum on the 32-bit system, so I built 
> it from source.
>   

That's strange. I doubt that any software available on 64 bits are not
available on 32 bits.

> 2) Attempting to build scipy results in the error below.
>
> Attached is a PDF with the notes (most of which came from Phil Austin) I 
> compiled after installing on the 64-bit system.
>
> I'm currently recompiling ATLAS (which takes an amazingly long time), 
> and then will try to rebuild LAPACK, BLAS, etc.  Before I get there, 
> does anyone have any idea what the root of the below error might be?
>
>  usr/local/bin/python setup.py build
> Traceback (most recent call last):
>   File "setup.py", line 53, in <module>
>     setup_package()
>   File "setup.py", line 28, in setup_package
>     from numpy.distutils.core import setup
>   File "/usr/local/lib/python2.5/site-packages/numpy/__init__.py", line 
> 103, in <module>
>     import linalg
(Continue reading)

David Cournapeau | 1 Jul 2008 09:57
Picon
Picon

fftpack: what should the API for fftn be ?

Hi,

    While taking a look at the ticket 244, there is something I don't
quite understand about the current behaviour for scipy fftn. The problem
in the ticket is that when both shape and axes arguments are given, fftn
wrongly ignore axes when padding the input according to shape. OTOH,
scipy fftn accepts shape and axes of different lengths (contrary to
numpy fftn), and I don't understand the expected behavior in that case.
Should we forbid the case len(shape) != len(axes); if not, what's the
expected behavior ?

cheers,

David
Robert Cimrman | 1 Jul 2008 16:13
Picon

ANN: SfePy 00.46.02


I am pleased announce the release of SfePy 00.46.02.

SfePy is a finite element analysis software in Python, based primarily
on Numpy and SciPy.

Mailing lists, issue tracking, mercurial repository: http://sfepy.org
Home page: http://sfepy.kme.zcu.cz

Major improvements:
- alternative short syntax for specifying essential boundary conditions, 
variables and regions
- manufactured solutions tests:
     - SymPy support
- site configuration now via script/config.py + site_cfg.py
- new solvers
- new terms

For more information on this release, see
http://sfepy.googlecode.com/svn/web/releases/004602_RELEASE_NOTES.txt

If you happen to come to Leipzig for EuroSciPy 2008, see you there!

Best regards,
Robert Cimrman & SfePy developers

Travis Vaught | 2 Jul 2008 16:34

Enthought Python Distribution

Greetings,

We're pleased to announce the beta release of the Enthought Python  
Distribution for *Mac OS X*.

http://www.enthought.com/products/epd.php

This release should safely install alongside other existing Python  
installations on your Mac.  With the Mac OS X platform support, EPD  
now provides a consistent scientific application tool set across three  
major platforms (Windows, RedHat Linux (32 and 64 bit) and OS X). This  
is a _beta_ release, so install at your own risk.  Please provide any  
feedback to info <at> enthought.com.  See the included EPD Readme.txt for  
instructions and known issues.

About EPD
---------
The Enthought Python Distribution (EPD) is a "kitchen-sink-included"  
distribution of the Pythonâ„¢ Programming Language, including over 60  
additional tools and libraries. The EPD bundle includes the following  
major packages:

Python       Core Python
NumPy        Multidimensional arrays and fast numerics for Python
SciPy        Scientific Library for Python
Enthought Tool Suite (ETS)   A suite of tools including:
  Traits      Manifest typing, validation, visualization, delegation,  
etc.
  Mayavi      3D interactive data exploration environment.
  Chaco       Advanced 2D plotting toolkit for interactive 2D  
(Continue reading)

Pauli Virtanen | 3 Jul 2008 09:58
Picon
Picon
Favicon

from scipy import * in r4484 doesn't load submodules

Hi,

It was so in Scipy 0.6 that

>>> from scipy import *

imported also the submodules 'optimize', 'integrate', 'special', 
'linalg', etc, etc. to the namespace.

It seems that this has changed in Scipy 0.7 SVN since that. Is removing 
these from __all__ and the API change intentional? (If it is, getting it 
to release notes would be nice.)

--

-- 
Pauli Virtanen
Robert Kern | 3 Jul 2008 10:00
Picon
Gravatar

Re: from scipy import * in r4484 doesn't load submodules

On Thu, Jul 3, 2008 at 02:58, Pauli Virtanen <pav <at> iki.fi> wrote:
> Hi,
>
> It was so in Scipy 0.6 that
>
>>>> from scipy import *
>
> imported also the submodules 'optimize', 'integrate', 'special',
> 'linalg', etc, etc. to the namespace.
>
> It seems that this has changed in Scipy 0.7 SVN since that. Is removing
> these from __all__ and the API change intentional? (If it is, getting it
> to release notes would be nice.)

Yes. These were intended to have been removed long, long ago. They do
not exist with just "import scipy". Their presence with "from scipy
import *" was a bug that got fixed.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco
Joe Harrington | 3 Jul 2008 23:59
Picon

Summer Doc Marathon status report and request for more writers

This is an interim status report on the Summer Documentation Marathon.
It is also an invitation and plea for all experienced users to
participate!  I am cross-posting in an effort to get broader
participation.  Please hold any discussion on the scipy-dev mailing
list.

As you know, our immediate goal is to produce first-draft docstrings
for the user-visible parts of Numpy in time for a release before Fall
classes (about 1 August).  The short version is: We are really moving
along!  But, we need *your* help to make it in time for August.

Here's the scoop:

1. We have all our infrastructure, standards, and procedure in place:
We have a wiki that makes editing the docs easy and even fun.  It
communicates directly with the numpy sources.  We have PDF and HTML
reference guides being generated essentially automatically:

http://sd-2116.dedibox.fr/pydocweb
http://mentat.za.net/numpy/refguide/NumPy.pdf
http://mentat.za.net/numpy/refguide/

The wiki front page contains or points to all you need to get started.

The wiki lets you pull down a docstring with a few mouse clicks, edit
on your machine, upload it, and see how it will look in its HTML
version right away.  You can also read everyone else's docstrings,
comment on them, see the status of the project, and so on.  The
formatted versions necessarily lag the docstrings on the wiki because
they are made whenever the docstrings are checked into the sources.
(Continue reading)

Roban Kramer | 4 Jul 2008 18:35

joining the effort

Hi,

I'd like to join the docstrings marathon. I probably won't get to
contribute until I'm back from a conference in a week or so, but I'd
guess I'll mostly be reviewing and proofreading, though I could do
some editing, too.

Thanks,
Roban
Roban Kramer | 4 Jul 2008 18:36

Re: joining the effort

Oh, uh... the username's RobanKramer

On Fri, Jul 4, 2008 at 12:35 PM, Roban Kramer <roban <at> astro.columbia.edu> wrote:
> Hi,
>
> I'd like to join the docstrings marathon. I probably won't get to
> contribute until I'm back from a conference in a week or so, but I'd
> guess I'll mostly be reviewing and proofreading, though I could do
> some editing, too.
>
> Thanks,
> Roban
>
Pauli Virtanen | 4 Jul 2008 20:10
Picon
Picon
Favicon

Re: joining the effort

> On Fri, Jul 4, 2008 at 12:35 PM, Roban Kramer <roban <at> astro.columbia.edu>
> wrote:
>> I'd like to join the docstrings marathon. I probably won't get to
>> contribute until I'm back from a conference in a week or so, but I'd
>> guess I'll mostly be reviewing and proofreading, though I could do some
>> editing, too.

Thanks, feel free to edit/review when you have time.

--

-- 
Pauli Virtanen

Gmane