Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Documentation updates folded back from 0.4.4 branch

  • Loading branch information...
commit aea889b61ebcab15896cd18306b0b811576abaf3 1 parent c25e735
edschofield authored
Showing with 284 additions and 228 deletions.
  1. +101 −120 DEVELOPERS.txt
  2. +139 −83 INSTALL.txt
  3. +8 −0 LATEST.txt
  4. +32 −21 THANKS.txt
  5. +4 −4 TOCHANGE.txt
221 DEVELOPERS.txt
View
@@ -1,10 +1,11 @@
.. -*- rest -*-
.. NB! Keep this document a valid restructured document.
-Developing Scipy
+Developing SciPy
================
:Author: Pearu Peterson <pearu@cens.ioc.ee>
+:Modified by: Ed Schofield <edschofield@gmail.com>
:Last changed: $Date$
:Revision: $Revision$
:Discussions to: scipy-dev@scipy.org
@@ -14,79 +15,62 @@ Developing Scipy
Introduction
------------
-Scipy aims at being a robust and efficient "super-package" of a number
-of its modules, each having a complexity and size to be a highly
-non-trivial package itself. In order for "Scipy integration" to work
-flawlessly, all Scipy modules must follow certain rules that are
-described in this document. Hopefully this document will be helpful to
-Scipy contributors as well as to developers as a basic reference about
-the structure of Scipy package.
+SciPy aims at being a robust and efficient "super-package" of a number
+of modules, each of a non-trivial size and complexity. In order for
+"SciPy integration" to work flawlessly, all SciPy modules must follow
+certain rules that are described in this document. Hopefully this
+document will be helpful for SciPy contributors and developers as a
+basic reference about the structure of the SciPy package.
-Scipy structure
+SciPy structure
---------------
-Currently Scipy consists of the following files and directories:
+Currently SciPy consists of the following files and directories:
INSTALL.txt
- Scipy prerequisites, installation, testing, and troubleshooting.
+ SciPy prerequisites, installation, testing, and troubleshooting.
PACKAGERS.txt
- Information on how to package Scipy and related tools.
+ Information on how to package SciPy and related tools.
THANKS.txt
- Scipy developers and contributors. Please keep it up to date!!
+ SciPy developers and contributors. Please keep it up to date!!
DEVELOPERS.txt
- Scipy structure (this document).
+ SciPy structure (this document).
setup.py
- Script for building and installing Scipy. It calls also
- scipy_core/setup.py with the same command line arguments
- as specified for setup.py. You'll find scipy_core related
- files in scipy_core/{dist,build}.
+ Script for building and installing SciPy.
MANIFEST.in
- Additions to distutils generated Scipy tar-balls.
- Its usage is depreciated, in general.
-
- scipy_core/
- Contains four modules, scipy_base, scipy_distutils, scipy_test,
- and weave, that all Scipy modules may depend on. As a rule,
- scipy_distutils is required only for building, scipy_test for
- running tests, and scipy_base contains various tools for runtime
- usage.
+ Additions to distutils-generated SciPy tar-balls. Its usage is
+ deprecated.
Lib/
- Contains Scipy __init__.py and the directories of Scipy modules.
-
- tutorial/
- Scipy tutorial.
+ Contains SciPy __init__.py and the directories of SciPy modules.
- util/
- Various tools [Not useful in general. Could we get rid of this?].
-Scipy module
+SciPy module
------------
-In the following, a *Scipy module* is defined as a Python package, say
-xxx, that is located in the Lib/ directory. All Scipy modules should
+In the following, a *SciPy module* is defined as a Python package, say
+xxx, that is located in the Lib/ directory. All SciPy modules should
follow the following conventions:
-* Ideally, each Scipy module should be self-contained as much as
- possible, that is, it must be usable as standalone and have minimal
- dependencies to other packages or modules, even if they would be
- also Scipy modules. The exception is ``scipy_base``, its usage is
- encouraged as a replacement of ``Numeric`` or ``numarray`` modules
- to simplify the future transition Numeric->Numarray.
+* Ideally, each SciPy module should be as self-contained as
+ possible. That is, it should have minimal
+ dependencies on other packages or modules. Even dependencies on other
+ SciPy modules should be kept to a minimum. A dependency on NumPy is
+ of course assumed.
* Directory ``xxx/`` must contain
- + a file ``setup_xxx.py`` that defines
+ + a file ``setup.py`` that defines
``configuration(parent_package='',parent_path=None)`` function.
See below for more details.
- + a file ``info_xxx.py``. See below more details.
+ + a file ``info.py``. See below more details.
* Directory ``xxx/`` may contain
@@ -96,49 +80,48 @@ follow the following conventions:
+ a file ``MANIFEST.in`` that may contain only ``include setup.py`` line.
DO NOT specify sources in MANIFEST.in, you must specify all sources
- in setup_xxx.py file. Otherwise Scipy tar-ball will miss these sources.
+ in setup.py file. Otherwise released SciPy tarballs will miss these sources.
-[Open issues: where we should put documentation?]
+ + a directory ``docs/`` for documentation.
-File xxx/setup_xxx.py
+File xxx/setup.py
---------------------
-Each Scipy module setup_xxx.py file should contain a function
+Each SciPy module setup.py file should contain a function
``configuration(..)`` that returns a dictionary which must be usable
as an argument to distutils setup function.
-For example, a minimal setup_xxx.py file for a pure Python Scipy
+For example, a minimal setup.py file for a pure-Python SciPy
module xxx would be::
- def configuration(parent_package='',parent_path=None):
+ def configuration(parent_package='', parent_path=None):
package = 'xxx'
- from scipy_distutils.misc_util import default_config_dict
- config = default_config_dict(package,parent_package)
+ from numpy.distutils.misc_util import default_config_dict
+ config = default_config_dict(package, parent_package)
return config
if __name__ == '__main__':
- from scipy_distutils.core import setup
+ from numpy.distutils.core import setup
setup(**configuration(parent_path=''))
-A Scipy module may have also a ``xxx/setup.py`` file that should contain
+A SciPy module may have also a ``xxx/setup.py`` file that should contain
one statement::
- execfile('setup_xxx.py')
+ execfile('setup.py')
-Ideally there should be no need for this file but
+Ideally there should be no need for this file, but
``distutils/command/bdist_rpm.py`` (Python versions <=2.3) has
-``setup.py`` hardcoded in and therefore building .rpm files without
-the above described ``setup.py`` file will fail. This is only
-relevant when you wish to distribute Scipy module separately from
-scipy.
+``setup.py`` hardcoded, so building .rpm files without the above-
+described ``setup.py`` file will fail. This is only relevant when you
+wish to distribute a SciPy module separately from SciPy.
get_path
++++++++
-``scipy_distutils.misc_util`` provides function
+``numpy.distutils.misc_util`` provides function
``get_path(modulename,parent_path=None)`` that returns the directory
-of ``modulename``. In ``setup_xxx.py`` file this can be used to
+of ``modulename``. In the ``setup.py`` file this can be used to
determine the local directory name as follows::
local_path = get_path(__name__, parent_path)
@@ -146,7 +129,7 @@ determine the local directory name as follows::
If ``parent_path`` is not ``None`` then the returned path is relative
to parent path. This avoids longish paths.
-When ``setup_xxx.py`` script is going to use ``os.path.join`` a lot
+When the ``setup.py`` script is uses ``os.path.join`` heavily
then defining the following functions can be handy::
def local_join(*names):
@@ -163,21 +146,21 @@ generated by, for example, by SWIG or F2PY. However, such a step
should be carried out only when building a module and, in general,
should be skipped when creating a distribution, for instance.
-Scipy_distutils provides natural support for building sources from .i
+numpy.distutils provides native support for building sources from .i
(SWIG) and .pyf (F2PY) files. These files should be listed in the
-``sources`` list to ``Extension`` constructor and Scipy_distutils
+``sources`` list to ``Extension`` constructor and numpy.distutils
takes care of processing these files.
For examples, see
::
- scipy_distutils/tests/f2py_ext/
- scipy_distutils/tests/swig_ext/
+ numpy.distutils/tests/f2py_ext/
+ numpy.distutils/tests/swig_ext/
-In addition, Scipy_distutils allows building sources from whatever
-means that is most suitable for you. All you need to do is to provide
-in the ``sources`` list auxiliary functions with the following
+In addition, numpy.distutils allows building sources from whatever
+means is most suitable for you. All you need to do is to provide
+the ``sources`` list auxiliary functions with the following
signatures:
::
@@ -194,16 +177,16 @@ Here ``extension`` argument refers to the corresponding ``Extension``
instance so that all its attributes are available to be used or to be
changed in inside these functions. The ``build_dir`` argument is
suggested (and highly recommended) location for saving generated
-source files. Btw, if you will use ``build_dir`` as a prefix to all
-generated source files then Scipy_distutils will be able to build
-source distributions that contain built sources and in users side they
-will be used instead of regenerating them.
+source files. By the way, if you use ``build_dir`` as a prefix for all
+generated source files then numpy.distutils will be able to build
+source distributions that contain built sources and users will not
+have to regenerate them.
For an example, see
::
- scipy_distutils/tests/swig_ext/gen_ext/
+ numpy.distutils/tests/swig_ext/gen_ext/
Note that generated source files may be C or Fortran source files as
well as Python files.
@@ -213,33 +196,31 @@ etc that are used to generated sources and should not be installed)
should be specified in ``depends`` list of the ``Extension``
constructor.
-SourceGenerator [depreciated]
+SourceGenerator [deprecated]
+++++++++++++++++++++++++++++
Often building a module envolves a step where sources are generated by
whatever means. However, such a step should be carried out only when
-building modules and should be skipped when creating a distribution,
-for instance. To facilitate this, ``scipy_distutils.misc_util``
-provides a class ``SourceGenerator(func,target,sources=[],*args)``
-that can be used to hold the process of source generation. Here
-``func`` is a function ``func(target,sources,*args)`` that is called
-whenever ``target`` should be generated. ``target`` is a name of
-source file that ``func`` must create. ``sources`` is a list of files
-that ``target`` depends on and ``target`` will be regenerated whenever
-these dependencies are changed. ``args`` can be used to pass on extra
-arguments to ``func``. The instance of ``SourceGenerator`` can be used
-in the ``sources`` list argument of an Extension class constructor.
-See ``Lib/xxx/setup_xxx.py`` for a typical example of
-``SourceGenerator`` usage.
+building modules and should be skipped when creating a distribution, for
+instance. To facilitate this, ``numpy.distutils.misc_util`` provides a
+class ``SourceGenerator(func,target,sources=[],*args)`` that can be used
+to hold the process of source generation. Here ``func`` is a function
+``func(target,sources,*args)`` that is called whenever ``target`` should
+be generated. ``target`` is a name of source file that ``func`` must
+create. ``sources`` is a list of files that ``target`` depends on and
+``target`` will be regenerated whenever these dependencies are changed.
+``args`` can be used to pass on extra arguments to ``func``. The
+instance of ``SourceGenerator`` can be used in the ``sources`` list
+argument of an Extension class constructor. See ``Lib/xxx/setup.py``
+for a typical example of ``SourceGenerator`` usage.
If ``func`` is ``None`` then the ``target`` must exist and whenever
-``sources`` are modified, the ``target`` file is touched. This
-feature is useful when including non-standard dependencies to
-Extension instances, just put them to ``sources`` list. See fastumath
-module in ``scipy_core/scipy_base/setup_scipy_base.py`` for example.
+``sources`` are modified, the ``target`` file is touched. This feature
+is useful when including non-standard dependencies for Extension
+instances---just put them in the ``sources`` list.
-SourceFilter [depreciated]
+SourceFilter [deprecated]
++++++++++++++++++++++++++
On different platforms different sources may be required to build a
@@ -248,18 +229,18 @@ by defining different sources for an Extension instance, then there
might occur portability issues (e.g. missing files) when a source
tar-ball was created on a different platform than the users platform.
-To overcome this difficulty, ``scipy_distutils.misc_util`` provides
+To overcome this difficulty, ``numpy.distutils.misc_util`` provides
``SourceFilter(func,sources,*args)`` class that can be used to define
a holder of all sources. Function ``func(sources,*args)`` should
return a list of sources that is relevant for building the module on
the particular platfrom. ``SourceFilter`` instance can be used in the
list of ``sources`` argument of the Extension class.
-File xxx/info_xxx.py
+File xxx/info.py
--------------------
-Scipy setup.py and Lib/__init__.py files assume that each Scipy module
-contains a info_xxx.py file. The following information will be looked
+SciPy setup.py and Lib/__init__.py files assume that each SciPy module
+contains a info.py file. The following information will be looked
from this file:
__doc__
@@ -277,7 +258,7 @@ dependencies
[Support not implemented yet, may be it is YAGNI?]
List of module names that the module depends on. The module will not
be installed if any of the dependencies is missing. If the module
- depends on another Scipy module, say yyy, and that is not going to
+ depends on another SciPy module, say yyy, and that is not going to
be installed standalone, then use full name, that is, ``scipy.yyy``
instead of ``yyy``.
@@ -301,11 +282,11 @@ File xxx/__init__.py
To speed up the import time as well as to minimize memory usage, scipy
uses ppimport hooks to transparently postpone importing large modules
-that might not be used during a Scipy usage session. But in order to
-have an access to documentation of all Scipy modules, including of the
+that might not be used during a SciPy usage session. But in order to
+have an access to documentation of all SciPy modules, including of the
postponed modules, the documentation string of a module (that would
usually reside in __init__.py file) should be copied also
-to info_xxx.py file.
+to info.py file.
So, the header a typical xxx/__init__.py file is::
@@ -313,7 +294,7 @@ So, the header a typical xxx/__init__.py file is::
# Module xxx - ...
#
- from info_xxx import __doc__
+ from info import __doc__
...
File xxx/tests/test_yyy.py
@@ -333,7 +314,7 @@ A minimal example of a ``test_yyy.py`` file that implements tests for
a module ``xxx.yyy`` containing a function ``zzz()``, is shown below::
import sys
- from scipy_test.testing import *
+ from numpy.testing import *
set_package_path()
# import xxx symbols
@@ -355,7 +336,7 @@ a module ``xxx.yyy`` containing a function ``zzz()``, is shown below::
``ScipyTestCase`` is derived from ``unittest.TestCase`` and it
implements additional method ``measure(self, code_str, times=1)``.
-``scipy_test.testing`` module provides also the following convenience
+The ``numpy.testing`` module provides also the following convenience
functions::
assert_equal(ctual,desired,err_msg='',verbose=1)
@@ -391,13 +372,13 @@ Open issues and discussion
Documentation
+++++++++++++
-That is an important feature that Scipy is currently missing. Few
-Scipy modules have some documentation but they use different formats
-and are mostly out-dated.
+This is an important feature where SciPy is currently lacking. A few
+SciPy modules have some documentation but they use different formats
+and are mostly out of date. We could use some help with this.
Currently there are
-* Scipy tutorial by Travis E. Oliphant that is maintained using LyX.
+* A SciPy tutorial by Travis E. Oliphant. This is maintained using LyX.
The main advantage of this approach is that one can use mathematical
formulas in documentation.
@@ -411,22 +392,22 @@ Currently there are
dated.
* Documentation strings of Python functions, classes, and modules.
- Some Scipy modules are well-documented in this sense, other again
- are very poorly documented. Other issue is that there is no
- consensus on how to format documentation strings, mainly because
- we haven't decided which tool to use to generate, for instance, HTML
- pages of documentation strings.
+ Some SciPy modules are well-documented in this sense, others are very
+ poorly documented. Another issue is that there is no consensus on how
+ to format documentation strings, mainly because we haven't decided
+ which tool to use to generate, for instance, HTML pages of
+ documentation strings.
-So, we need unique rules for documenting Scipy modules. Here are some
+So, we need unique rules for documenting SciPy modules. Here are some
requirements that documentation tools should satsify:
* Easy to use. This is important to lower the threshold of developers
to use the same documentation utilities.
-* In general, all functions that are visible to Scipy end-users, must
+* In general, all functions that are visible to SciPy end-users, must
have well-maintained documentation strings.
-* Support for mathematical formulas. Since Scipy is a tool for
+* Support for mathematical formulas. Since SciPy is a tool for
scientific work, it is hard to avoid formulas to describe how its
modules are good for. So, documentation tools should support LaTeX.
@@ -434,9 +415,9 @@ requirements that documentation tools should satsify:
interface and implementation. This is important for keeping
documentation up to date. One option would be to maintain
documentation in source files (and have a tool that extracts
- documentation from sources). The main disadvantage with that is
- the lack of convenience writing documentation as the editor would be
- in different mode (e.g. Python mode) from the mode suitable for
+ documentation from sources). The main disadvantage with that is the
+ lack of convenience writing documentation as the editor would be in
+ different mode (e.g. Python mode) from the mode suitable for
documentation.
* Differentiation of implementation (e.g. from scanning sources) and
222 INSTALL.txt
View
@@ -4,7 +4,8 @@
Building and installing SciPy
+++++++++++++++++++++++++++++
-:Author: Pearu Peterson <pearu@cens.ioc.ee>
+:Authors: Pearu Peterson <pearu@cens.ioc.ee>
+:Modified by: Ed Schofield <edschofield@gmail.com>
:Last changed: $Date$
:Revision: $Revision$
:Discussions to: scipy-dev@scipy.org
@@ -19,65 +20,79 @@ PREREQUISITES
SciPy requires the following software installed:
-1) Python__ 2.1.x, 2.2.x, or 2.3.x (see NOTES 1)
+1) Python__ 2.3.x or 2.4.x
Debian packages: python python-dev
-__ http://www.python.org
+ Make sure that the Python package distutils is installed before
+ continuing. For example, in Debian GNU/Linux, distutils is included
+ in the python-dev package.
+
+ Python must also be compiled with the zlib module enabled.
-2) `Numerical Python`__ 21.0 or newer but not Numarray (yet)
+__ http://www.python.org
- Debian packages: python-numeric
+2) NumPy__ 0.9.2 or newer
__ http://www.numpy.org/
-3) ATLAS__ 3.2.1 or newer and complete LAPACK__ (see NOTES 2, 3, 4)
+3) Complete LAPACK__ library (see NOTES 1, 2, 3)
Debian packages: atlas2-headers atlas2-base atlas2-base-dev
-__ http://math-atlas.sourceforge.net/
+ Various SciPy packages do linear algebra computations using the LAPACK
+ routines. SciPy's setup.py scripts can use number of different LAPACK
+ library setups, including optimized LAPACK libraries such as ATLAS__ or
+ the Accelerate/vecLib framework on OS X. The notes below give
+ more information on how to prepare the build environment so that
+ SciPy's setup.py scripts can use whatever LAPACK library setup one has.
+
__ http://www.netlib.org/lapack/
+__ http://math-atlas.sourceforge.net/
-4) f2py__ 2.35.229-1492 or newer
-__ http://cens.ioc.ee/projects/f2py2e/
-5) C, C++, Fortran 77 compilers (see COMPILER NOTES)
+OPTIONAL PACKAGES
+=================
+
+The following software is optional, but SciPy can use these if present
+for extra functionality:
+
+1) C, C++, Fortran 77 compilers (see COMPILER NOTES)
+
+ To build SciPy or any other extension modules for Python, you'll need
+ a C compiler.
+
+ Various SciPy modules use Fortran 77 libraries, so you'll need also
+ at least a Fortran 77 compiler installed. Currently the SciPy build
+ process does not use a C++ compiler, but the SciPy module Weave uses
+ a C++ compiler at run time, so it is good to have C++ compiler around
+ as well.
+
+ gcc__ 3.x compilers are recommended. gcc 2.95 and 4.0.x also work on
+ some platforms, but may be more problematic (see COMPILER NOTES).
- gcc__ 2.95.x, 3.x compilers are recommended.
- When building with Chaco, gcc 3.x is required.
-
Debian packages: gcc g++ g77
__ http://gcc.gnu.org/
-The following software is optional:
+2) FFTW__ 2.1.x (see Lib/fftpack/NOTES.txt)
-6) FFTW__ 2.1.x (see Lib/fftpack/NOTES.txt) but not 2.2.x (yet)
+ FFTW 3.0.x may also work, but SciPy currently has better performance
+ with FFTW 2.1.x.
Debian packages: fftw2 fftw-dev
__ http://www.fftw.org/
-7) wxPython__
-
- Debian packages: libwxgtk2.4-python libwxgtk2.4 libwxgtk2.4-dev
- wxwin2.4-headers
-
-__ http://www.wxpython.org/
-
-8) SWIG 1.3.x, required when building with chaco. See setup.py
- for how to disable chaco.
- Debian packages: swig1.3 libswig1.3
NOTES
-----
-1) Python must be build with zlib module enabled.
-
-2) Complete lapack library is required when using ATLAS, see
+1) To use ATLAS, version 3.2.1 or newer and a *complete* LAPACK library
+ are required. See
http://math-atlas.sourceforge.net/errata.html#completelp
@@ -133,20 +148,23 @@ NOTES
export ATLAS=/usr/local/lib/atlas
-3) If you are willing to sacrifice the performance (by factor of 5 to
- 15 for large problems) of the linalg module then it is possible to
- build SciPy without ATLAS. For that you'll need either Fortran
- LAPACK/BLAS libraries installed in your system or Fortran
- LAPACK/BLAS sources to be accessible by SciPy setup scripts (use
- ``LAPACK_SRC``/``BLAS_SRC`` environment variables to indicate the location
- of the corresponding source directories).
+2) If you are willing to sacrifice the performance (by factor of 5 to 15
+ for large problems) of the linalg module then it is possible to build
+ SciPy without ATLAS. For that you'll need either Fortran LAPACK/BLAS
+ libraries installed in your system or Fortran LAPACK/BLAS sources to be
+ accessible by SciPy setup scripts (use ``LAPACK_SRC``/``BLAS_SRC``
+ environment variables to indicate the location of the corresponding
+ source directories). More details of how to do this are on the SciPy
+ Wiki, at:
+
+ http://new.scipy.org/Wiki/Installing_SciPy/BuildingGeneral
-4) Debian users can use the following deb packages::
+3) Users of Debian (and derivatives like Ubuntu) can use the following
+ deb packages::
atlas2-headers
and
- ::
atlas2-base atlas2-base-dev
or
@@ -156,42 +174,69 @@ NOTES
or
atlas2-3dnow atlas2-3dnow-dev
- It is not necessary to install blas or lapack libraries then.
+ It is not necessary to install blas or lapack libraries in addition.
+
GETTING SCIPY
=============
-See
- http://scipy.org/
+For the latest information, see the Wiki site
+
+ http://new.scipy.org/Wiki
+
+The main website is:
+
+ http://www.scipy.org
+
+but this is currently out of date (as of January 2006).
-Development version from CVS
+
+Development version from Subversion (SVN)
----------------------------
-See
- http://www.scipy.org/site_content/tutorials/CVSInstruct
-Daily snapshots of SciPy CVS repository is available at
- http://www.scipy.org/site_content/download_list
+Use the command:
+
+ svn co http://svn.scipy.org/svn/scipy/trunk scipy
+
+Before building and installing from SVN, remove the old installation
+(e.g. in /usr/lib/python2.4/site-packages/scipy or
+$HOME/lib/python2.4/site-packages/scipy). Then type:
+
+ cd scipy
+ rm -rf build
+ python setup.py install
+
+
INSTALLATION
============
-Make sure that all SciPy prerequisites are installed and working
-properly before continuing SciPy installation.
+First make sure that all SciPy prerequisites are installed and working
+properly. Then be sure to remove any old SciPy installations (e.g.
+/usr/lib/python2.4/site-packages/scipy or $HOME/lib/python2.4/
+site-packages/scipy).
From tarballs
-------------
-Unpack ``SciPy-<version>.tar.gz``, change to ``SciPy-<version>/``
+Unpack ``SciPy-<version>.tar.gz``, change to the ``SciPy-<version>/``
directory, and run
::
python setup.py install
-This may take several minutes to hours depending on the speed of your
-computer.
+This may take several minutes to an hour depending on the speed of your
+computer. This may require root privileges. To install to a
+user-specific location instead, run
+
+ python setup.py install --prefix=$MYDIR
+
+where $MYDIR is, for example, $HOME or $HOME/usr.
+
+
TESTING
=======
-To test SciPy installation (highly recommended), execute in python
+To test SciPy after installation (highly recommended), execute in Python
>>> import scipy
>>> scipy.test(level=1)
@@ -201,16 +246,28 @@ messages about what tests are being executed, use
>>> scipy.test(level=1, verbosity=2)
+
COMPILER NOTES
==============
-You can specify which Fortran compiler to use by
+Note that SciPy is developed mainly using GNU compilers. Compilers from
+other vendors such as Intel, Absoft, Sun, NAG, Compaq, Vast, Porland,
+Lahey, HP, IBM are supported in the form of community feedback.
+
+gcc__ 3.x compilers are recommended. gcc 4.0.x also works on some
+platforms (e.g. Linux x86). SciPy is not fully compatible with gcc
+4.0.x on OS X. If building on OS X, we recommend you use gcc 3.3, by
+typing:
+ gcc_select 3.3
+
+You can specify which
+Fortran compiler to use by
::
export FC_VENDOR=<Vendor>
before the install command. <Vendor> is Absoft, Sun, SGI, Intel,
-Itanium, NAG, Compaq, Digital, Gnu, or VAST.
+Itanium, NAG, Compaq, Digital, GNU, or VAST.
Or use the following install command::
python setup.py build build_flib --fcompiler=<Vendor> install
@@ -219,31 +276,29 @@ IMPORTANT: It is highly recommended that all libraries that scipy uses
(e.g. blas and atlas libraries) are built with the same Fortran
compiler.
-Using non-Gnu Fortran compiler with gcc/g77 compiled Atlas/Lapack libraries
+Using non-GNU Fortran compiler with gcc/g77 compiled Atlas/Lapack libraries
---------------------------------------------------------------------------
-When Atlas/Lapack libraries are compiled with Gnu compilers but
-one wishes to build scipy with some non-gnu Fortran compiler then
+When Atlas/Lapack libraries are compiled with GNU compilers but
+one wishes to build scipy with some non-GNU Fortran compiler then
linking extension modules may require -lg2c. You can specify it
in installation command line as follows::
python setup.py build build_ext -lg2c install
-If using non-Gnu C compiler or linker, the location of g2c library can
+If using non-GNU C compiler or linker, the location of g2c library can
be specified in a similar manner using -L/path/to/libg2c.a after
build_ext command.
Intel Fortran Compiler
----------------------
-Intel Fortran Compiler (IFC) compiled codes are not binary compatible
-with g77 compiled codes. Therefore, when using IFC, *all* Fortran
-codes used in SciPy must be compiled with IFC, this also includes
-LAPACK, BLAS, and ATLAS libraries. Usage of GCC for compiling C codes
-is OK.
-
-IFC version 5.0 is not supported (because its bugs cause segfaults in
-scipy tests).
+Note that code compiled by the Intel Fortran Compiler (IFC) is not
+binary compatible with code compiled by g77. Therefore, when using IFC,
+all Fortran codes used in SciPy must be compiled with IFC. This also
+includes the LAPACK, BLAS, and ATLAS libraries. Using GCC for compiling
+C code is OK. IFC version 5.0 is not supported (because it has bugs that
+cause SciPy's tests to segfault).
Minimum IFC flags for building LAPACK and ATLAS are
::
@@ -263,8 +318,9 @@ these routines)::
cd ..
make lapacklib
-KNOWN PROBLEMS
-==============
+
+KNOWN INSTALLATION PROBLEMS
+===========================
BLAS sources shipped with LAPACK are incomplete
-----------------------------------------------
@@ -290,10 +346,11 @@ size of the file liblapack.a -- it should be about 6MB. The location
of liblapack.a is shown by executing
::
- python scipy_core/scipy_distutils/system_info.py
+ python /lib/python2.4/site-packages/numpy/distutils/system_info.py
-Fix:
- Follow the instructions in
+(or the appropriate installation directory).
+
+To fix: follow the instructions in
http://math-atlas.sourceforge.net/errata.html#completelp
@@ -315,29 +372,30 @@ Fix:
2) Rebuild/reinstall scipy.
-Using non-Gnu Fortran Compiler
+Using non-GNU Fortran Compiler
------------------------------
If import scipy shows a message
::
ImportError: undefined symbol: s_wsfe
-and you are using non-Gnu Fortran compiler, then it means that any of
+and you are using non-GNU Fortran compiler, then it means that any of
the (may be system provided) Fortran libraries such as LAPACK or BLAS
were compiled with g77. See also compilers notes above.
Recommended fix: Recompile all Fortran libraries with the same Fortran
compiler and rebuild/reinstall scipy.
-Another fix: See `Using non-gnu Fortran compiler with gcc/g77 compiled
+Another fix: See `Using non-GNU Fortran compiler with gcc/g77 compiled
Atlas/Lapack libraries` section above.
+
TROUBLESHOOTING
===============
If you experience problems when building/installing/testing SciPy, you
can ask help from scipy-user@scipy.org or scipy-dev@scipy.org mailing
-lists. Please include the following information to your message:
+lists. Please include the following information in your message:
NOTE: With recent f2py version (>=2.33.xxx-xxxx) you can generate
some of the following information (items 1-5) in one command::
@@ -363,15 +421,11 @@ some of the following information (items 1-5) in one command::
python -c 'import sys;print sys.version'
-4) Python Numeric version::
-
- python -c 'import Numeric;print Numeric.__version__'
+4) NumPy version::
-5) f2py version::
+ python -c 'import numpy;print numpy.__version__'
- f2py -v
-
-6) ATLAS version, the locations of atlas and lapack libraries, building
+5) ATLAS version, the locations of atlas and lapack libraries, building
information if any. If you have ATLAS version 3.3.6 or newer, then
give the output of the last command in
::
@@ -383,8 +437,10 @@ some of the following information (items 1-5) in one command::
7) The output of the following commands
::
- python scipy_core/scipy_distutils/system_info.py
- python scipy_core/scipy_distutils/command/build_flib.py
+ python INSTALLDIR/numpy/distutils/system_info.py
+ python INSTALLDIR/numpy/distutils/command/build_flib.py
+
+where INSTALLDIR is, for example, /usr/lib/python2.4/site-packages/.
8) Feel free to add any other relevant information.
For example, the full output (both stdout and stderr) of the SciPy
8 LATEST.txt
View
@@ -0,0 +1,8 @@
+The Subversion tree for this distribution contains the latest code. It can be
+downloaded using the subversion client as
+
+svn co http://svn.scipy.org/svn/scipy/trunk scipy
+
+which will create a directory named scipy in your current directory and fill it with the current version of scipy.
+
+
53 THANKS.txt
View
@@ -1,43 +1,54 @@
-SciPy is an open source library developed by Enthought, Inc. Many people have
-contributed to SciPy, both in code development, suggestions, and financial
-support. Below is a partial list. If you've been left off, please let me know
-(eric@enthought.com), and I'll add your name.
+SciPy is an open source library of routines for science and engineering
+using Python. It is a community project sponsored by Enthought, Inc.
+Many people have contributed to SciPy, both in code development,
+suggestions, and financial support. Below is a partial list. If you've
+been left off, please let me know (eric@enthought.com), and I'll add
+your name.
Code Contributions:
The main developers on SciPy are Travis Oliphant, Pearu Peterson, and Eric
Jones. Travis and Eric each contributed about half the orginal code. Pearu
-developed f2py which is the integral to wrapping the many Fortran libraries
+developed f2py, which is the integral to wrapping the many Fortran libraries
used in SciPy. All three continually work on both algorithm development and
improvements to the feature set, build process, and robustness of SciPy.
-Prabhu Ramachandran -- improvements to gui_thread.
-Jochen Kupper -- the zoom feature in plt.
-Jeff Whitaker -- Mac OS X support.
-Travis Vaught -- initial work on stats module clean up.
-David M. Cooke -- improvements to system_info, and lbfgsb wrapper
-Chuck Harris -- Zeros package in optimize (1d root-finding algorithms)
-Jean-Sebastien Roy -- fmin_tnc code which he adapted from Stephen Nash's
+Robert Cimrman -- UMFpack wrapper for sparse matrix module
+David M. Cooke -- improvements to system_info, and LBFGSB wrapper
+Chuck Harris -- Zeros package in optimize (1d root-finding algorithms)
+Prabhu Ramachandran -- improvements to gui_thread
+Jean-Sebastien Roy -- fmin_tnc code which he adapted from Stephen Nash's
original Fortran
-Ed Schofield -- sparse adaptation and improvements
-Robert Cimrman -- umfpack wrapper for sparse
+Ed Schofield -- Maximum entropy and Monte Carlo modules, help with
+ sparse matrix module
+Travis Vaught -- initial work on stats module clean up
+Jeff Whitaker -- Mac OS X support
+
Testing:
David Morrill for getting the scoreboard test system up and running.
Louis Luangkesorn for providing multiple tests for the stats module.
-Website Development:
-Travis Vaught, Tiffany Kamm, and Eric Jones for building the community web-site.
-Travis Vaught for maintaining the web-site.
+Others:
-Institutions:
+Others who have contributed in the past include:
-Enthought for providing resources and finances for development of SciPy.
+Jochen Kupper -- the zoom feature in the now-deprecated plt plotting module
-Brigham Young University has provided resources for students to work on SciPy.
-Agilent has given a genereous donation for support of SciPy.
+Website Development:
+
+Travis Vaught, Tiffany Kamm, and Eric Jones -- for building the community web-site.
+Travis Vaught, Mark Koudritsky -- for maintaining the web-site
+Andrew Straw -- for setting up the new Wiki at scipy.org
+
+
+Institutions:
+
+Enthought -- for providing resources and finances for development of SciPy.
+Brigham Young University -- for providing resources for students to work on SciPy.
+Agilent -- which gave a genereous donation for support of SciPy.
8 TOCHANGE.txt
View
@@ -1,4 +1,4 @@
-Changes needed to convert scipy to work with the new scipy core.
+Changes needed to convert SciPy to work with the new NumPy.
done * scipy_distutils and scipy_base to scipy.disutils and scipy.base
done * Numeric/arrayobject.h to scipy/arrayobject.h
@@ -12,7 +12,7 @@ done * Look for use of descr->zero and descr->ones --- need to be replaced
Changes that should be made someday:
* io rewritten to use internal writing capabilities of arrays
-* distributions heavy use of extract and insert (could use fancy indexing -- but we should wait until we learn how slow fancy indexing is....)
-* Use of old Numeric C-API. Using it means an extra C-level function cal think that's a problem, but...
-* Make use of type addition to extend certain ufuncs with cephes quad types.
+* distributions heavy use of extract and insert (could use fancy indexing?) -- but we should wait until we learn how slow fancy indexing is....)
+* Use of old Numeric C-API. Using it means an extra C-level function call, but ...
+* Make use of type addition to extend certain ufuncs with cephes quad types
* Use finfo(foo).bar instead of limits.foo_bar
Please sign in to comment.
Something went wrong with that request. Please try again.