From nicolist at limare.net  Mon Sep  4 08:40:36 2006
From: nicolist at limare.net (Nicolas Limare)
Date: Mon, 04 Sep 2006 14:40:36 +0200
Subject: [SciPy-dev] scipy svn 2186 test() failure
Message-ID: <edh6s6$ca5$1@sea.gmane.org>

built on numpy svn3107.
python 2.4.3, gcc 4.0.3, ubuntu dapper 6.06
linux 2.6.15-26-686 SMP i686

In [3]: import scipy
Overwriting info=<function info at 0xb661009c> from scipy.misc (was
<function info at 0xb72df374> from numpy.lib.utils)
In [4]: scipy.test()
Overwriting fft=<function fft at 0xb646fd84> from scipy.fftpack.basic
(was <module 'numpy.fft' from
'/usr/lib/python2.4/site-packages/numpy/fft/__init__.pyc'> from
/usr/lib/python2.4/site-packages/numpy/fft/__init__.pyc)
  Found 4 tests for scipy.linsolve.umfpack.umfpack
  Found 4 tests for scipy.io.array_import
  Found 128 tests for scipy.linalg.fblas
  Found 397 tests for scipy.ndimage
  Found 10 tests for scipy.integrate.quadpack
  Found 97 tests for scipy.stats.stats
  Found 47 tests for scipy.linalg.decomp
  Found 2 tests for scipy.integrate.quadrature
  Found 95 tests for scipy.sparse.sparse
  Found 20 tests for scipy.fftpack.pseudo_diffs
  Found 6 tests for scipy.optimize.optimize
  Found 5 tests for scipy.interpolate.fitpack
  Found 1 tests for scipy.interpolate
  Found 70 tests for scipy.stats.distributions
  Found 12 tests for scipy.io.mmio
  Found 10 tests for scipy.stats.morestats
  Found 4 tests for scipy.linalg.lapack
  Found 18 tests for scipy.fftpack.basic
  Found 4 tests for scipy.optimize.zeros
  Found 17 tests for scipy.io.mio
  Found 4 tests for scipy.fftpack.helper
  Found 41 tests for scipy.linalg.basic
  Found 2 tests for scipy.maxentropy.maxentropy
  Found 358 tests for scipy.special.basic
  Found 128 tests for scipy.lib.blas.fblas
  Found 7 tests for scipy.linalg.matfuncs
  Found 42 tests for scipy.lib.lapack
  Found 1 tests for scipy.optimize.cobyla
  Found 16 tests for scipy.lib.blas
  Found 1 tests for scipy.integrate
  Found 14 tests for scipy.linalg.blas
  Found 4 tests for scipy.signal.signaltools
  Found 0 tests for __main__
data-ftype: z compared to data D
Calling _superlu.zgssv
Use minimum degree ordering on A'+A.
.data-ftype: c compared to data F
Calling _superlu.cgssv
Use minimum degree ordering on A'+A.
.data-ftype: d compared to data d
Calling _superlu.dgssv
Use minimum degree ordering on A'+A.
.data-ftype: s compared to data f
Calling _superlu.sgssv
Use minimum degree ordering on A'+A.
.
Don't worry about a warning regarding the number of bytes read.
Warning: 1000000 bytes requested, 20 bytes read.
.......caxpy:n=4
..caxpy:n=3
....ccopy:n=4
..ccopy:n=3
.............cscal:n=4
....cswap:n=4
..cswap:n=3
.....daxpy:n=4
..daxpy:n=3
....dcopy:n=4
..dcopy:n=3
.............dscal:n=4
....dswap:n=4
..dswap:n=3
.....saxpy:n=4
..saxpy:n=3
....scopy:n=4
..scopy:n=3
.............sscal:n=4
....sswap:n=4
..sswap:n=3
.....zaxpy:n=4
..zaxpy:n=3
....zcopy:n=4
..zcopy:n=3
.............zscal:n=4
....zswap:n=4
..zswap:n=3
.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Took
13 points.
..........Resizing... 16 17 24
Resizing... 20 7 35
Resizing... 23 7 47
Resizing... 24 25 58
Resizing... 28 7 68
Resizing... 28 27 73
.....Use minimum degree ordering on A'+A.
........................Use minimum degree ordering on A'+A.
...................Resizing... 16 17 24
Resizing... 20 7 35
Resizing... 23 7 47
Resizing... 24 25 58
Resizing... 28 7 68
Resizing... 28 27 73
.....Use minimum degree ordering on A'+A.
.................Resizing... 16 17 24
Resizing... 20 7 35
Resizing... 23 7 47
Resizing... 24 25 58
Resizing... 28 7 68
Resizing... 28 27 73
.....Use minimum degree ordering on A'+A.
....................................../usr/lib/python2.4/site-packages/scipy/interpolate/fitpack2.py:410:
UserWarning:
The coefficients of the spline returned have been computed as the
minimal norm least-squares solution of a (numerically) rank deficient
system (deficiency=7). If deficiency is large, the results may be
inaccurate. Deficiency may strongly depend on the value of eps.
  warnings.warn(message)
.........................................................................................FTies
preclude use of exact statistic.
..Ties preclude use of exact statistic.
.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................caxpy:n=4
..caxpy:n=3
....ccopy:n=4
..ccopy:n=3
.............cscal:n=4
....cswap:n=4
..cswap:n=3
.....daxpy:n=4
..daxpy:n=3
....dcopy:n=4
..dcopy:n=3
.............dscal:n=4
....dswap:n=4
..dswap:n=3
.....saxpy:n=4
..saxpy:n=3
....scopy:n=4
..scopy:n=3
.............sscal:n=4
....sswap:n=4
..sswap:n=3
.....zaxpy:n=4
..zaxpy:n=3
....zcopy:n=4
..zcopy:n=3
.............zscal:n=4
....zswap:n=4
..zswap:n=3
...Result may be inaccurate, approximate err = 1.36217727555e-08
...Result may be inaccurate, approximate err = 1.30251255798e-10
..............................................................Residual:
1.05006950608e-07
...................
======================================================================
FAIL: check_normal (scipy.stats.tests.test_morestats.test_anderson)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.4/site-packages/scipy/stats/tests/test_morestats.py",
line 51, in check_normal
    assert_array_less(A, crit[-2:])
  File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line
235, in assert_array_less
    header='Arrays are not less-ordered')
  File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line
215, in assert_array_compare
    assert cond, msg
AssertionError:
Arrays are not less-ordered

(mismatch 50.0%)
 x: array(0.97993935779150831)
 y: array([ 0.858,  1.021])

----------------------------------------------------------------------
Ran 1569 tests in 3.014s

FAILED (failures=1)
Out[4]: <unittest.TextTestRunner object at 0xb5a9edac>
In [5]: scipy.version.version
Out[5]: '0.5.1.dev2186'






-- 
Nico



From nicolist at limare.net  Mon Sep  4 09:10:52 2006
From: nicolist at limare.net (Nicolas Limare)
Date: Mon, 04 Sep 2006 15:10:52 +0200
Subject: [SciPy-dev] scipy svn 2186 test() other failures (on hppa)
In-Reply-To: <edh6s6$ca5$1@sea.gmane.org>
References: <edh6s6$ca5$1@sea.gmane.org>
Message-ID: <edh8l2$ioe$1@sea.gmane.org>

built on numpy svn3107.
python 2.3.5, gcc 3.3.5, debian sarge
linux 2.6.8-3-32 parisc (hp-pa)

In [3]: import scipy
Overwriting info=<function info at 0x40e4e9b0> from scipy.misc (was
<function info at 0x40742170> from numpy.lib.utils)
In [4]: scipy.test()
Overwriting fft=<function fft at 0x40e12ef0> from scipy.fftpack.basic
(was <module 'numpy.fft' from
'/usr/lib/python2.3/site-packages/numpy/fft/__init__.pyc'> from
/usr/lib/python2.3/site-packages/numpy/fft/__init__.pyc)
import lib.lapack -> failed:
/usr/lib/python2.3/site-packages/scipy/lib/lapack/flapack.so: undefined
symbol: PyArray_API
  Found 4 tests for scipy.linsolve.umfpack.umfpack
  Found 4 tests for scipy.io.array_import
  Found 128 tests for scipy.linalg.fblas
  Found 397 tests for scipy.ndimage
  Found 10 tests for scipy.integrate.quadpack
  Found 97 tests for scipy.stats.stats
  Found 47 tests for scipy.linalg.decomp
  Found 2 tests for scipy.integrate.quadrature
  Found 95 tests for scipy.sparse.sparse
  Found 20 tests for scipy.fftpack.pseudo_diffs
  Found 6 tests for scipy.optimize.optimize
  Found 5 tests for scipy.interpolate.fitpack
  Found 1 tests for scipy.interpolate
  Found 70 tests for scipy.stats.distributions
  Found 12 tests for scipy.io.mmio
  Found 10 tests for scipy.stats.morestats
  Found 4 tests for scipy.linalg.lapack
  Found 18 tests for scipy.fftpack.basic
  Found 4 tests for scipy.optimize.zeros
  Found 17 tests for scipy.io.mio
  Found 4 tests for scipy.fftpack.helper
  Found 41 tests for scipy.linalg.basic
  Found 2 tests for scipy.maxentropy.maxentropy
  Found 358 tests for scipy.special.basic
  Found 128 tests for scipy.lib.blas.fblas
  Found 7 tests for scipy.linalg.matfuncs
Warning: FAILURE importing tests for <module 'scipy.lib.lapack' from
'.../scipy/lib/lapack/__init__.pyc'>
/usr/lib/python2.3/site-packages/scipy/lib/lapack/__init__.py:15:
ImportError:
/usr/lib/python2.3/site-packages/scipy/lib/lapack/flapack.so: undefined
symbol: PyArray_API (in ?)
  Found 1 tests for scipy.optimize.cobyla
  Found 16 tests for scipy.lib.blas
  Found 1 tests for scipy.integrate
  Found 14 tests for scipy.linalg.blas
  Found 4 tests for scipy.signal.signaltools
  Found 0 tests for __main__
data-ftype: z compared to data D
Calling _superlu.zgssv
Use minimum degree ordering on A'+A.
.data-ftype: c compared to data F
Calling _superlu.cgssv
Use minimum degree ordering on A'+A.
.data-ftype: d compared to data d
Calling _superlu.dgssv
Use minimum degree ordering on A'+A.
.data-ftype: s compared to data f
Calling _superlu.sgssv
Use minimum degree ordering on A'+A.
.
Don't worry about a warning regarding the number of bytes read.
Warning: 1000000 bytes requested, 20 bytes read.
.......caxpy:n=4
..caxpy:n=3
....ccopy:n=4
..ccopy:n=3
.............cscal:n=4
....cswap:n=4
..cswap:n=3
.....daxpy:n=4
..daxpy:n=3
....dcopy:n=4
..dcopy:n=3
.............dscal:n=4
....dswap:n=4
..dswap:n=3
.....saxpy:n=4
..saxpy:n=3
....scopy:n=4
..scopy:n=3
.............sscal:n=4
....sswap:n=4
..sswap:n=3
.....zaxpy:n=4
..zaxpy:n=3
....zcopy:n=4
..zcopy:n=3
.............zscal:n=4
....zswap:n=4
..zswap:n=3
.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Took
13 points.
..........Resizing... 16 17 24
Resizing... 20 7 35
Resizing... 23 7 47
Resizing... 24 25 58
Resizing... 28 7 68
Resizing... 28 27 73
.....Use minimum degree ordering on A'+A.
........................Use minimum degree ordering on A'+A.
...................Resizing... 16 17 24
Resizing... 20 7 35
Resizing... 23 7 47
Resizing... 24 25 58
Resizing... 28 7 68
Resizing... 28 27 73
.....Use minimum degree ordering on A'+A.
.................Resizing... 16 17 24
Resizing... 20 7 35
Resizing... 23 7 47
Resizing... 24 25 58
Resizing... 28 7 68
Resizing... 28 27 73
.....Use minimum degree ordering on A'+A.
....................................../usr/lib/python2.3/site-packages/scipy/interpolate/fitpack2.py:410:
UserWarning:
The coefficients of the spline returned have been computed as the
minimal norm least-squares solution of a (numerically) rank deficient
system (deficiency=7). If deficiency is large, the results may be
inaccurate. Deficiency may strongly depend on the value of eps.
  warnings.warn(message)
................FF........F...............................................................Ties
preclude use of exact statistic.
..Ties preclude use of exact statistic.
.FF.............................................Warning: 184549376 bytes
requested, 73 bytes read.
F..............................................................................................................................................................................................................................................................................F..................F..................................FF..................................................................................caxpy:n=4
..caxpy:n=3
....ccopy:n=4
..ccopy:n=3
.............cscal:n=4
....cswap:n=4
..cswap:n=3
.....daxpy:n=4
..daxpy:n=3
....dcopy:n=4
..dcopy:n=3
.............dscal:n=4
....dswap:n=4
..dswap:n=3
.....saxpy:n=4
..saxpy:n=3
....scopy:n=4
..scopy:n=3
.............sscal:n=4
....sswap:n=4
..sswap:n=3
.....zaxpy:n=4
..zaxpy:n=3
....zcopy:n=4
..zcopy:n=3
.............zscal:n=4
....zswap:n=4
..zswap:n=3
...Result may be inaccurate, approximate err = 1.24142097959e-08
...Result may be inaccurate, approximate err = 3.90044584243e-10
...................Residual: 1.05006987327e-07
...................
======================================================================
FAIL: check_cdf (scipy.stats.tests.test_distributions.test_chi)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 9, in check_cdf
AssertionError: D = 0.611395254754; pval = 1.3262280163e-11; alpha = 0.01
args = (1.5671875277704621,)

======================================================================
FAIL: check_cdf (scipy.stats.tests.test_distributions.test_chi2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 9, in check_cdf
AssertionError: D = 0.300736970157; pval = 0.00333143555133; alpha = 0.01
args = (1.4249100071916856,)

======================================================================
FAIL: check_cdf (scipy.stats.tests.test_distributions.test_fatiguelife)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<string>", line 9, in check_cdf
AssertionError: D = 0.341252570181; pval = 0.000636283285767; alpha = 0.01
args = (1.1031049127753509,)

======================================================================
FAIL: check_data (scipy.stats.tests.test_morestats.test_bartlett)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.3/site-packages/scipy/stats/tests/test_morestats.py",
line 90, in check_data
    assert_almost_equal(pval,0.0136358632781,7)
  File "/usr/lib/python2.3/site-packages/numpy/testing/utils.py", line
154, in assert_almost_equal
    return assert_array_almost_equal(actual, desired, decimal, err_msg)
  File "/usr/lib/python2.3/site-packages/numpy/testing/utils.py", line
230, in assert_array_almost_equal
    header='Arrays are not almost equal')
  File "/usr/lib/python2.3/site-packages/numpy/testing/utils.py", line
215, in assert_array_compare
    assert cond, msg
AssertionError:
Arrays are not almost equal

(mismatch 100.0%)
 x: array(0.018126703796836161)
 y: array(0.013635863278099999)

======================================================================
FAIL: check_data (scipy.stats.tests.test_morestats.test_binom_test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.3/site-packages/scipy/stats/tests/test_morestats.py",
line 104, in check_data
    assert_almost_equal(pval,0.0018833009350757682,11)
  File "/usr/lib/python2.3/site-packages/numpy/testing/utils.py", line
156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
 ACTUAL: 0.99999999999999989
 DESIRED: 0.0018833009350757682

======================================================================
FAIL: check loadmat case vec
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/scipy/io/tests/test_mio.py",
line 80, in cc
    self._check_case(name, expected)
  File "/usr/lib/python2.3/site-packages/scipy/io/tests/test_mio.py",
line 74, in _check_case
    assert k in matdict, "Missing key at %s" % k_label
AssertionError: Missing key at Test 'vec',
file:/usr/lib/python2.3/site-packages/scipy/io/tests/./data/testvec_4_GLNX86.mat,
variable fit_params

======================================================================
FAIL: check_gammainc (scipy.special.tests.test_basic.test_gammainc)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.3/site-packages/scipy/special/tests/test_basic.py",
line 996, in check_gammainc
    assert_almost_equal(gama,.7,1)
  File "/usr/lib/python2.3/site-packages/numpy/testing/utils.py", line
156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
 ACTUAL: 0.90752671516550643
 DESIRED: 0.69999999999999996

======================================================================
FAIL: check_hyp1f1 (scipy.special.tests.test_basic.test_hyp1f1)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.3/site-packages/scipy/special/tests/test_basic.py",
line 1144, in check_hyp1f1
    assert_almost_equal(hyp1, 1.3498588075760032,7)
  File "/usr/lib/python2.3/site-packages/numpy/testing/utils.py", line
156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
 ACTUAL: 1.2898968548511782
 DESIRED: 1.3498588075760032

======================================================================
FAIL: check_k1 (scipy.special.tests.test_basic.test_k1)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.3/site-packages/scipy/special/tests/test_basic.py",
line 1445, in check_k1
    assert_almost_equal(o1k,o1kr,8)
  File "/usr/lib/python2.3/site-packages/numpy/testing/utils.py", line
156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
 ACTUAL: -3.4541289156353865e+280
 DESIRED: 9.853844780870606

======================================================================
FAIL: check_k1e (scipy.special.tests.test_basic.test_k1e)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/lib/python2.3/site-packages/scipy/special/tests/test_basic.py",
line 1452, in check_k1e
    assert_almost_equal(o1ke,o1ker,8)
  File "/usr/lib/python2.3/site-packages/numpy/testing/utils.py", line
156, in assert_almost_equal
    assert round(abs(desired - actual),decimal) == 0, msg
AssertionError:
Items are not equal:
 ACTUAL: -3.8174028248444013e+280
 DESIRED: 10.890182683049698

----------------------------------------------------------------------
Ran 1527 tests in 33.493s

FAILED (failures=10)



-- 
Nico



From nmarais at sun.ac.za  Mon Sep  4 10:18:44 2006
From: nmarais at sun.ac.za (Neilen Marais)
Date: Mon, 04 Sep 2006 16:18:44 +0200
Subject: [SciPy-dev] ARPACK (large scale eigen-solver) wrappers
Message-ID: <pan.2006.09.04.14.18.43.422112@sun.ac.za>

Hi

As promised a while ago I've started messing around with ARPACK wrappers
for SciPy. The typical form of an ARPACK solution is that you iteratively
call an ARPACK routine which then asks you to do certain matrix-vector
operations on the matrix that you need the eigenvalues of. I've only
played around with the simplest mode of the dnaupd routine where it will
only ask you for matrix-vector products.

I seem to have a reasonable f2py wrapper for that routine. ARPACK seems to
think that it has converged after a resonable seeming number of
iterations. But getting at the actual eigenvalues requires postprocessing
using the dneupd routine. At the moment I get segfaults if I run it, or
otherwise just after. 

I'm not quite sure where the problem is. I'll spend a bit more time on it,
but if anyone is interested I could put up a bzr archive of what I've done
so far. It's not a whole lot yet, though :)

Regards
Neilen

-- 
you know its kind of tragic 
we live in the new world
but we've lost the magic
-- Battery 9 (www.battery9.co.za)



From nicolist at limare.net  Tue Sep  5 06:29:18 2006
From: nicolist at limare.net (Nicolas Limare)
Date: Tue, 05 Sep 2006 12:29:18 +0200
Subject: [SciPy-dev] scipy svn 2186 test() failure
In-Reply-To: <edh6s6$ca5$1@sea.gmane.org>
References: <edh6s6$ca5$1@sea.gmane.org>
Message-ID: <edjji0$ho8$1@sea.gmane.org>

Nicolas Limare wrote:
> built on numpy svn3107.
> python 2.4.3, gcc 4.0.3, ubuntu dapper 6.06
> linux 2.6.15-26-686 SMP i686

solved in svn2190

-- 
Nico



From wilna at sun.ac.za  Thu Sep  7 11:10:18 2006
From: wilna at sun.ac.za (Du Toit, Wilna <wilna@sun.ac.za>)
Date: Thu, 7 Sep 2006 17:10:18 +0200
Subject: [SciPy-dev] Python 3D plotting
Message-ID: <9C48EEFF0A9A1147A920EBEF2CE8CBF016F3A8@STBEVS01.stb.sun.ac.za>

Hi, I've developed a simple 3D plotting module which u can find at http://www.scipy.org/WilnaDuToit . There's still alot of work to be done, so please feel free to play/use/extend/break it if u find it useful and send comments/enquiries/fixes etc to wilna at sun.ac.za.
 
Hope someone can use it :)
 
Wilna du Toit
 


From jstrunk at enthought.com  Thu Sep  7 19:16:52 2006
From: jstrunk at enthought.com (Jeff Strunk)
Date: Thu, 7 Sep 2006 18:16:52 -0500
Subject: [SciPy-dev] ISP changeover Tuesday 9/12 7:00 PM Central
Message-ID: <200609071816.53060.jstrunk@enthought.com>

Good afternoon,

Unfortunately, our recent change in internet service providers is not working 
out. We will be switching to a more reliable provider on Tuesday 9/12 at 7:00 
PM Central. Please allow for up to two hours of downtime. I will send an 
email announcing the start and completion of this maintenance.

This will effect all Enthought servers as well as the SciPy server which hosts 
many Open Source projects.

The problem was that our in-building internet service provider neglected to 
mention that our internet connection was over a wireless link to a different 
building. This link had very high latency. They have fixed this problem, but 
we feel that wireless is not stable enough for our needs. In order to provide 
higher quality service, we will be using 3 bonded T1s from AT&T after this 
switchover.

Please pass this message along to people that I have missed. If you have any 
questions, please direct them to me.

We apologize for the inconvenience.
Jeff Strunk
Enthought, Inc.


From a.h.jaffe at gmail.com  Mon Sep 11 11:06:36 2006
From: a.h.jaffe at gmail.com (Andrew Jaffe)
Date: Mon, 11 Sep 2006 16:06:36 +0100
Subject: [SciPy-dev] rfft different in numpy vs scipy
Message-ID: <45057B7C.9000405@gmail.com>

Steven G. Johnson wrote:
 > Andrew Jaffe wrote:
 >> numpy returns n/2+1 complex numbers (so the first and last numbers are
 >> actually real) with the frequencies equivalent to the positive part of
 >> the fftfreq, whereas scipy returns n real numbers with the frequencies
 >> as in rfftfreq (i.e., two real numbers at the same frequency, except for
 >> the highest and lowest) [All of the above for even n; but the difference
 >> between numpy and scipy remains for odd n.]
 >>
 >> I think the numpy behavior makes more sense, as it doesn't require any
 >> unpacking after the fact, at the expense of a tiny amount of wasted
 >> space. But would this in fact require scipy doing extra work from
 >> whatever the 'native' real_fft (fftw, I assume) produces?
 >
 > As an author of FFTW, let me interject a couple of points into this
 > discussion.
 >
 > First, if you are using FFTW, then its real-input r2c routines
 > "natively" produce output in the "unpacked" numpy format as described
 > above: an array of n/2+1 complex numbers.  Any "packed" format would
 > require some data permutations.  Other FFT implementations use a
 > variety of formats.
 >
 > Second, the *reason* why FFTW's r2c routines produce unpacked output is
 > largely because "packed" formats do not generalize well to
 > multi-dimensional FFTs, while the "unpacked" format does.  (Packed
 > formats are *possible* for multidimensional transforms, but become
 > increasingly intricate as you add more dimensions.)  Additionally, I
 > personally find the unpacked format more convenient in most
 > applications.
 >
 > I hope this is helpful.

OK -- so it appears that all (three) of the votes so far are in support
of the numpy convention -- a complex result.

If this is something that can be done in pure python, I'm willing to
give it a stab, but I'm probably not capable of handling any python/C
issues. Does anyone out there understand the interaction between fftpack
(C & python?), fftw (C), scipy and numpy in this context well enough to
give some advice?

Yours,

Andrew



-- 
______________________________________________________________________
Andrew Jaffe a.jaffe at imperial.ac.uk
Astrophysics Group +44 207 594-7526
Blackett Laboratory, Room 1013 FAX 7541
Imperial College, Prince Consort Road
London SW7 2AZ ENGLAND http://astro.imperial.ac.uk/~jaffe


From rex at nosyntax.com  Mon Sep 11 18:17:24 2006
From: rex at nosyntax.com (rex)
Date: Mon, 11 Sep 2006 15:17:24 -0700
Subject: [SciPy-dev] lognormal(): TypeError: Cannot convert float to
	numpy.ndarray
Message-ID: <20060911221724.GG5064@x2.nosyntax.com>

>>> import scipy as S
>>> S.random.lognormal(0,1,4)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "mtrand.pyx", line 930, in mtrand.RandomState.lognormal
TypeError: Cannot convert int to numpy.ndarray

>>> S.random.lognormal(0.,1.,7)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "mtrand.pyx", line 930, in mtrand.RandomState.lognormal
TypeError: Cannot convert float to numpy.ndarray


S.random.beta(), chisquare(), exponential(), f(), gamma(), and the
others I tried returned without errors.

Scipy was built from a recent SVN, but I don't recall the checkout
number.

Thanks,

-rex


From robert.kern at gmail.com  Mon Sep 11 18:32:55 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 11 Sep 2006 17:32:55 -0500
Subject: [SciPy-dev] lognormal(): TypeError: Cannot convert float
	to	numpy.ndarray
In-Reply-To: <20060911221724.GG5064@x2.nosyntax.com>
References: <20060911221724.GG5064@x2.nosyntax.com>
Message-ID: <4505E417.8070408@gmail.com>

rex wrote:
>>>> import scipy as S
>>>> S.random.lognormal(0,1,4)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "mtrand.pyx", line 930, in mtrand.RandomState.lognormal
> TypeError: Cannot convert int to numpy.ndarray
> 
>>>> S.random.lognormal(0.,1.,7)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "mtrand.pyx", line 930, in mtrand.RandomState.lognormal
> TypeError: Cannot convert float to numpy.ndarray
> 
> 
> S.random.beta(), chisquare(), exponential(), f(), gamma(), and the
> others I tried returned without errors.
> 
> Scipy was built from a recent SVN, but I don't recall the checkout
> number.

Thank you. The problem is in numpy, not scipy, but I found the problem and fixed 
it in SVN r3141.

-- 
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


From rex at nosyntax.com  Mon Sep 11 18:41:10 2006
From: rex at nosyntax.com (rex)
Date: Mon, 11 Sep 2006 15:41:10 -0700
Subject: [SciPy-dev] lognormal(): TypeError: Cannot convert float to
	numpy.ndarray
In-Reply-To: <4505E417.8070408@gmail.com>
References: <20060911221724.GG5064@x2.nosyntax.com>
	<4505E417.8070408@gmail.com>
Message-ID: <20060911224110.GJ5064@x2.nosyntax.com>

Robert Kern <robert.kern at gmail.com> [2006-09-11 15:34]:
> rex wrote:
> >>>> import scipy as S
> >>>> S.random.lognormal(0.,1.,7)
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File "mtrand.pyx", line 930, in mtrand.RandomState.lognormal
> > TypeError: Cannot convert float to numpy.ndarray
> 
> Thank you. The problem is in numpy, not scipy, but I found the problem and fixed 
> it in SVN r3141.

Wow, that was fast!! Thanks much. 

I don't know if this means I need to rebuild SciPy also, but I'll find
out soon enough...

-rex


From robert.kern at gmail.com  Mon Sep 11 19:14:33 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 11 Sep 2006 18:14:33 -0500
Subject: [SciPy-dev] lognormal(): TypeError: Cannot convert float
	to	numpy.ndarray
In-Reply-To: <20060911224110.GJ5064@x2.nosyntax.com>
References: <20060911221724.GG5064@x2.nosyntax.com>	<4505E417.8070408@gmail.com>
	<20060911224110.GJ5064@x2.nosyntax.com>
Message-ID: <4505EDD9.8010405@gmail.com>

rex wrote:
> Robert Kern <robert.kern at gmail.com> [2006-09-11 15:34]:
>> rex wrote:
>>>>>> import scipy as S
>>>>>> S.random.lognormal(0.,1.,7)
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in ?
>>>   File "mtrand.pyx", line 930, in mtrand.RandomState.lognormal
>>> TypeError: Cannot convert float to numpy.ndarray
>> Thank you. The problem is in numpy, not scipy, but I found the problem and fixed 
>> it in SVN r3141.
> 
> Wow, that was fast!! Thanks much. 
> 
> I don't know if this means I need to rebuild SciPy also, but I'll find
> out soon enough...

Not for this fix. However, if the last time you built scipy was versus a rather 
older version of numpy, then numpy's C API may have changed. But that wasn't my 
fault.  :-)

-- 
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


From jstrunk at enthought.com  Tue Sep 12 10:26:51 2006
From: jstrunk at enthought.com (Jeff Strunk)
Date: Tue, 12 Sep 2006 09:26:51 -0500
Subject: [SciPy-dev] REMINDER: ISP changeover today 9/12 7:00 PM Central
Message-ID: <200609120926.51762.jstrunk@enthought.com>

Good morning,

This is a reminder for this evening's network maintenance.

Unfortunately, our recent change in internet service providers is not working 
out. We will be switching to a more reliable provider tonight at 7:00 
PM Central. Please allow for up to two hours of downtime. I will send an 
email announcing the start and completion of this maintenance.

This will effect all Enthought servers as well as the SciPy server which hosts 
many Open Source projects.

Please pass this message along to people that I have missed. If you have any 
questions, please direct them to me.

We apologize for the inconvenience.
Jeff Strunk
Enthought, Inc.


From jstrunk at enthought.com  Tue Sep 12 19:30:03 2006
From: jstrunk at enthought.com (Jeff Strunk)
Date: Tue, 12 Sep 2006 18:30:03 -0500
Subject: [SciPy-dev] ISP changeover beginning in 30 minutes (7:00 PM Central)
Message-ID: <200609121830.03566.jstrunk@enthought.com>

Good evening,

We will begin switching our internet service over in about 30 minutes. Please 
allow for up to two hours of downtime. I will send an email announcing the 
completion of this maintenance.

This will effect all Enthought servers as well as the SciPy server which hosts 
many Open Source projects.

We apologize for the inconvenience.
Jeff Strunk
Enthought, Inc.


From jstrunk at enthought.com  Tue Sep 12 21:11:58 2006
From: jstrunk at enthought.com (Jeff Strunk)
Date: Tue, 12 Sep 2006 20:11:58 -0500
Subject: [SciPy-dev] ISP Changeover complete
Message-ID: <200609122011.58960.jstrunk@enthought.com>

Good evening,

We have completed our internet service switchover. Thank you for your 
patience. If you have any trouble, please let me know.

Thank you,
Jeff Strunk
IT Administrator
Enthought, Inc.


From david at ar.media.kyoto-u.ac.jp  Thu Sep 14 06:32:48 2006
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 14 Sep 2006 19:32:48 +0900
Subject: [SciPy-dev] Include patch in ticket {1} (slow fft when using fftw3)
	?
Message-ID: <45092FD0.3040600@ar.media.kyoto-u.ac.jp>

Hi,

    I would like to know if it would be possible to include the patch I 
posted to solve the slow fft in scipy problem (scipy ticket 1). I am 
using it myself for some time, never failed on me, and have a dramatic 
influence on speed (between 2 and 5 for complex input 1d fft),

    cheers,

    David


From jtravs at gmail.com  Mon Sep 18 13:39:49 2006
From: jtravs at gmail.com (John Travers)
Date: Mon, 18 Sep 2006 18:39:49 +0100
Subject: [SciPy-dev] Thank you, Intel compilers, MKL+fft
Message-ID: <3a1077e70609181039n18ef34c8wff32469e20ae9df4@mail.gmail.com>

Hello SciPy developers,

I've started to use SciPy in my work (nonlinear fibre optics) and I
just wanted to say a big thank you to Travis, Pearu, Eric and everyone
else for developing SciPy. I have recently moved a fairly large amount
of numerical code over from Matlab and got an immediate speedup of 30%
Which is very nice. Especially as I can now use the whole of python
rather than just Matlab to write my code with now. (And it's much much
cheaper!!). So thanks very much! Another main advantage I now have
with SciPy is that I can use exactly the same code on my linux
cluster.. but that brings a question:

Have the problems reported by Arnd Baecker in December/January with
the intel c compiler (to do with cephes and more) been solved yet. At
the moment, I can't get SciPy to compile on the cluster system with
the intel c compiler. (It is working very well with gcc + intel ifort
+ MKL though).

Another question:
Has anything been done to use the MKL fft library for the ffts in
SciPy? I'm am currently half way through getting this working (have
complex transforms in 1D working I think), but I don't want to
duplicate. If not, I'll submit a patch as soon as I get it going.

Thanks again for all the hard work!!
John Travers

----------------------------------
Femtosecond Optics Group
Physics Department
Imperial College
Prince Consort Road
London, SW7 2BW


From jtravs at gmail.com  Mon Sep 18 14:01:33 2006
From: jtravs at gmail.com (John Travers)
Date: Mon, 18 Sep 2006 19:01:33 +0100
Subject: [SciPy-dev] system_info for MKL fft
Message-ID: <3a1077e70609181101n56fc8773l154494a199737a43@mail.gmail.com>

Hello,

I have made some reasonable progress with adding Intel MKL fft support
to the SciPy fft module. However, to get it to compile I need a
SCIPY_MKL or something similar defined so that the preprocessor
selects the correct code rather than fftw etc if MKL is detected. I'm
having trouble understanding how to do this in system_info.py.  Any
help would be much apreciated.

Thanks,
John Travers

----------------------------------
Femtosecond Optics Group
Physics Department
Imperial College
Prince Consort Road
London, SW7 2BW


From dd55 at cornell.edu  Tue Sep 19 11:24:21 2006
From: dd55 at cornell.edu (Darren Dale)
Date: Tue, 19 Sep 2006 11:24:21 -0400
Subject: [SciPy-dev] umfpack-5.1
Message-ID: <200609191124.22568.dd55@cornell.edu>

After updating umfpack to the current version (umfpack-5.1), I am not able to 
build scipy. There is a long list of errors, such as 

/usr/include/umfpack/umfpack.h:31:22: error: UFconfig.h: No such file or 
directory
In file included from /usr/include/umfpack/umfpack.h:48,
                 from 
build/src.linux-x86_64-2.4/Lib/linsolve/umfpack/_umfpack_wrap.c:2478:
/usr/include/umfpack/umfpack_symbolic.h:23: error: 
expected '=', ',', ';', 'asm' or '__attribute__' before 'umfpack_dl_symbolic'
/usr/include/umfpack/umfpack_symbolic.h:47: error: 
expected '=', ',', ';', 'asm' or '__attribute__' before 'umfpack_zl_symbolic'

and 

build/src.linux-x86_64-2.4/Lib/linsolve/umfpack/_umfpack_wrap.c:2810: 
error: 'UF_long' undeclared (first use in this function)
build/src.linux-x86_64-2.4/Lib/linsolve/umfpack/_umfpack_wrap.c:2810: error: 
(Each undeclared identifier is reported only once
build/src.linux-x86_64-2.4/Lib/linsolve/umfpack/_umfpack_wrap.c:2810: error: 
for each function it appears in.)
build/src.linux-x86_64-2.4/Lib/linsolve/umfpack/_umfpack_wrap.c:2810: error: 
expected ';' before 'arg1'

Will scipy support new versions of umfpack?

Thanks,
Darren


From cimrman3 at ntc.zcu.cz  Tue Sep 19 11:33:48 2006
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Tue, 19 Sep 2006 17:33:48 +0200
Subject: [SciPy-dev] umfpack-5.1
In-Reply-To: <200609191124.22568.dd55@cornell.edu>
References: <200609191124.22568.dd55@cornell.edu>
Message-ID: <45100DDC.302@ntc.zcu.cz>

Darren Dale wrote:
> After updating umfpack to the current version (umfpack-5.1), I am not able to 
> build scipy. There is a long list of errors, such as 
> ...
> Will scipy support new versions of umfpack?

Sure. Unfortunately, I have some urgent things to do now, so stick, 
please, with the version 5.0 (which works for me) for the moment if you can.

r.



From nwagner at iam.uni-stuttgart.de  Wed Sep 20 02:46:47 2006
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 20 Sep 2006 08:46:47 +0200
Subject: [SciPy-dev] No test failures/errors
Message-ID: <4510E3D7.2070804@iam.uni-stuttgart.de>

Dear developers,

No more errors and failures wrt to numpy.test(), scipy.test() in latest
numpy/svn !
Thank you very much !

>>> numpy.__version__
'1.0rc1.dev3194'
>>> scipy.__version__
'0.5.2.dev2205'

The following tickets may be closed. I can't do it (no permission)

http://projects.scipy.org/scipy/scipy/ticket/263
http://projects.scipy.org/scipy/scipy/ticket/265

Nils



From matthew.brett at gmail.com  Wed Sep 20 03:59:56 2006
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 20 Sep 2006 08:59:56 +0100
Subject: [SciPy-dev] No test failures/errors
In-Reply-To: <4510E3D7.2070804@iam.uni-stuttgart.de>
References: <4510E3D7.2070804@iam.uni-stuttgart.de>
Message-ID: <1e2af89e0609200059v6e9033edv986e97a833487cda@mail.gmail.com>

Hi,

> No more errors and failures wrt to numpy.test(), scipy.test() in latest
> numpy/svn !

Looks like it's time to write more tests!

Best,

Matthew


From eric at enthought.com  Wed Sep 20 12:29:28 2006
From: eric at enthought.com (eric)
Date: Wed, 20 Sep 2006 11:29:28 -0500
Subject: [SciPy-dev] ANN: Job postings -- Enthought, Inc.
Message-ID: <45116C68.1070706@enthought.com>

Hey group,

We are growing again and have multiple positions open here at Enthought.  I'd
love to recruit more people out of the Scipy/numpy community.  I think many of you would
find the work interesting.  You can look at our career page for more info:

http://www.enthought.com/careers.htm <http://www.enthought.com/careers.html>


thanks!

eric



From jtravs at gmail.com  Wed Sep 20 13:25:20 2006
From: jtravs at gmail.com (John Travers)
Date: Wed, 20 Sep 2006 18:25:20 +0100
Subject: [SciPy-dev] patches for Intel MKL fft support (complex only)
Message-ID: <3a1077e70609201025g11449154x873106554b27355e@mail.gmail.com>

Hi all,

Attached are two patches that combined will enable support for the use
of Intel MKL fft library calls in scipy.fftpack. At the moment only
complex transforms zfft and zfftnd and their inverses are supported.
Convolution and real transforms are in progress.

The motivation for this work is that the MKL fft's are considerably
faster than fftw.
The benchmarks below show a speedup of between 0x and 2x (and probably
more for arrays larger than 8192) which is certainly significant for
my work ( approx 30% speed up of my code when using MKL vs fftw.

The first patch: mkl_fft_numpy.patch, is against numpy to enable
selection of MKL for the fft library in system_info.py of
numpy.distutils. I'm not sure if this is implemented correctly as
system_info.py seems a little bit mysterious to me. It does however
work! (on my system). If possible it selects MKL over fftw/djbfft etc.
as MKL is faster, but still uses fftw for the real data tarnsforms at
the moment.

The second patch:  mkl_fft_scipy.patch, is against scipy and modifies
Lib/fftpack/src fftpack.h zfft.c zfftnd.c, to give complete support
for the complex transforms, following the spirit of the previous
contents of those files.

When applied and rebuilt all tests pass on my GNU/Linux based x86_64
intel system using gcc and intel ifort.

I hope someone will take the time to commit and test these patches on
their systems.

Thanks,
John Travers

Just as a teaser some comparison benchmarks are added below:

>>>> With MKL (note real data versions are not implemented).

=================================================
      |    real input     |   complex input
-------------------------------------------------
 size |  scipy  |  numpy  |  scipy  |  numpy
-------------------------------------------------
  100 |    0.20 |    0.17 |    0.15 |    0.14  (secs for 7000 calls)
 1000 |    0.13 |    0.18 |    0.09 |    0.15  (secs for 2000 calls)
  256 |    0.31 |    0.23 |    0.17 |    0.20  (secs for 10000 calls)
  512 |    0.31 |    0.38 |    0.20 |    0.31  (secs for 10000 calls)
 1024 |    0.05 |    0.07 |    0.03 |    0.05  (secs for 1000 calls)
 2048 |    0.09 |    0.12 |    0.05 |    0.11  (secs for 1000 calls)
 4096 |    0.07 |    0.11 |    0.04 |    0.11  (secs for 500 calls)
 8192 |    0.15 |    0.27 |    0.10 |    0.26  (secs for 500 calls)

>>>> With fftw2

Fast Fourier Transform
=================================================
      |    real input     |   complex input
-------------------------------------------------
 size |  scipy  |  numpy  |  scipy  |  numpy
-------------------------------------------------
  100 |    0.19 |    0.16 |    0.15 |    0.13  (secs for 7000 calls)
 1000 |    0.13 |    0.18 |    0.13 |    0.16  (secs for 2000 calls)
  256 |    0.31 |    0.27 |    0.25 |    0.23  (secs for 10000 calls)
  512 |    0.37 |    0.44 |    0.32 |    0.32  (secs for 10000 calls)
 1024 |    0.05 |    0.06 |    0.05 |    0.06  (secs for 1000 calls)
 2048 |    0.08 |    0.12 |    0.09 |    0.11  (secs for 1000 calls)
 4096 |    0.07 |    0.12 |    0.09 |    0.10  (secs for 500 calls)
 8192 |    0.15 |    0.27 |    0.18 |    0.25  (secs for 500 calls)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkl_fft_numpy.patch
Type: application/octet-stream
Size: 1194 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20060920/5e00c8f8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkl_fft_scipy.patch
Type: application/octet-stream
Size: 7831 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20060920/5e00c8f8/attachment-0001.obj>

From jtravs at gmail.com  Wed Sep 20 18:07:39 2006
From: jtravs at gmail.com (John Travers)
Date: Wed, 20 Sep 2006 23:07:39 +0100
Subject: [SciPy-dev] patches for Intel MKL fft support (complex only)
In-Reply-To: <E1GQ8xx-0005xo-P1@mail2.sun.ac.za>
References: <3a1077e70609201025g11449154x873106554b27355e@mail.gmail.com>
	<E1GQ8xx-0005xo-P1@mail2.sun.ac.za>
Message-ID: <3a1077e70609201507k5b9576f4q14736f1eef432f0d@mail.gmail.com>

Thanks, I have done as you suggested.
This topic can now be followed with scipy Trac ticket #268
Best regards,
John

On 20/09/06, Albert Strasheim <fullung at gmail.com> wrote:
> Hey John
>
> Great patches! I suggest creating a new ticket in the SciPy Trac site so
> that the SciPy developers can keep track of them. You can attach patches to
> this ticket as you complete your work.
>
> Go here to do the necessary:
>
> 1. http://projects.scipy.org/scipy/scipy/register
> 2. http://projects.scipy.org/scipy/scipy/login
> 3. http://projects.scipy.org/scipy/scipy/newticket
>
> Regards,
>
> Albert
>
> > -----Original Message-----
> > From: scipy-dev-bounces at scipy.org [mailto:scipy-dev-bounces at scipy.org] On
> > Behalf Of John Travers
> > Sent: 20 September 2006 19:25
> > To: scipy-dev at scipy.org
> > Subject: [SciPy-dev] patches for Intel MKL fft support (complex only)
> >
> > Hi all,
> >
> > Attached are two patches that combined will enable support for the use
> > of Intel MKL fft library calls in scipy.fftpack. At the moment only
> > complex transforms zfft and zfftnd and their inverses are supported.
> > Convolution and real transforms are in progress.
> >
> > <snup>
>
>


-- 
My mobile (which I rarely answer): (+44) (0) 7739 105209
If you want to see what I do: www.femto.ph.ic.ac.uk


From nwagner at iam.uni-stuttgart.de  Thu Sep 21 04:04:10 2006
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Sep 2006 10:04:10 +0200
Subject: [SciPy-dev] sandbox xplt
Message-ID: <4512477A.9010907@iam.uni-stuttgart.de>

Hi all,

I added xplt to the packages in enabled_packages.txt

python setup.py install results in

/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
cannot find -lX11
collect2: ld returned 1 exit status

locate libX11 yields

/usr/lib/NX/lib/libX11.so.6
/usr/lib/NX/lib/libX11.so.6.2
/usr/X11R6/lib/libX11.so.6
/usr/X11R6/lib/libX11.so.6.2
/usr/X11R6/lib64/libX11.a
/usr/X11R6/lib64/libX11.so
/usr/X11R6/lib64/libX11.so.6
/usr/X11R6/lib64/libX11.so.6.2


How can I fix this problem ?

Nils



From pearu at cens.ioc.ee  Thu Sep 21 04:21:44 2006
From: pearu at cens.ioc.ee (pearu at cens.ioc.ee)
Date: Thu, 21 Sep 2006 11:21:44 +0300 (EEST)
Subject: [SciPy-dev] sandbox xplt
In-Reply-To: <4512477A.9010907@iam.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0609211120480.30462-100000@cens.kybi>




On Thu, 21 Sep 2006, Nils Wagner wrote:

> Hi all,
> 
> I added xplt to the packages in enabled_packages.txt
> 
> python setup.py install results in
> 
> /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
> cannot find -lX11
> collect2: ld returned 1 exit status
> 
> locate libX11 yields
> 
> /usr/lib/NX/lib/libX11.so.6
> /usr/lib/NX/lib/libX11.so.6.2
> /usr/X11R6/lib/libX11.so.6
> /usr/X11R6/lib/libX11.so.6.2
> /usr/X11R6/lib64/libX11.a
> /usr/X11R6/lib64/libX11.so
> /usr/X11R6/lib64/libX11.so.6
> /usr/X11R6/lib64/libX11.so.6.2
> 
> 
> How can I fix this problem ?

Install libx11-dev (in suse this package may have different name).

Pearu



From nwagner at iam.uni-stuttgart.de  Thu Sep 21 04:29:55 2006
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Sep 2006 10:29:55 +0200
Subject: [SciPy-dev] sandbox xplt
In-Reply-To: <Pine.LNX.4.21.0609211120480.30462-100000@cens.kybi>
References: <Pine.LNX.4.21.0609211120480.30462-100000@cens.kybi>
Message-ID: <45124D83.2000504@iam.uni-stuttgart.de>

pearu at cens.ioc.ee wrote:
>
> On Thu, 21 Sep 2006, Nils Wagner wrote:
>
>   
>> Hi all,
>>
>> I added xplt to the packages in enabled_packages.txt
>>
>> python setup.py install results in
>>
>> /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
>> cannot find -lX11
>> collect2: ld returned 1 exit status
>>
>> locate libX11 yields
>>
>> /usr/lib/NX/lib/libX11.so.6
>> /usr/lib/NX/lib/libX11.so.6.2
>> /usr/X11R6/lib/libX11.so.6
>> /usr/X11R6/lib/libX11.so.6.2
>> /usr/X11R6/lib64/libX11.a
>> /usr/X11R6/lib64/libX11.so
>> /usr/X11R6/lib64/libX11.so.6
>> /usr/X11R6/lib64/libX11.so.6.2
>>
>>
>> How can I fix this problem ?
>>     
>
> Install libx11-dev (in suse this package may have different name).
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   
Hi Pearu,

Thank you very much for your prompt reply.

rpm -qi xorg-x11-devel

yields

Name        : xorg-x11-devel               Relocations: (not relocatable)
Version     : 6.8.2                             Vendor: SUSE LINUX
Products GmbH, Nuernberg, Germany
Release     : 100                           Build Date: Tue 13 Sep 2005
12:56:49 AM CEST
Install date: Mon 27 Feb 2006 11:01:32 AM CET      Build Host:
mahler.suse.de
Group       : Development/Libraries/X11     Source RPM:
xorg-x11-6.8.2-100.src.rpm
Size        : 11022807                         License: X11/MIT, Other
License(s), see package
Signature   : DSA/SHA1, Tue 13 Sep 2005 01:07:38 AM CEST, Key ID
a84edae89c800aca
Packager    : http://www.suse.de/feedback
URL         : http://freedesktop.org/XOrg
Summary     : Include Files and Libraries mandatory for Development
Description :
This package contains all necessary include files and libraries needed
to develop applications that require these.

Maybe it's a 64-bit issue.

Nils



From pearu at cens.ioc.ee  Thu Sep 21 04:44:12 2006
From: pearu at cens.ioc.ee (pearu at cens.ioc.ee)
Date: Thu, 21 Sep 2006 11:44:12 +0300 (EEST)
Subject: [SciPy-dev] sandbox xplt
In-Reply-To: <45124D83.2000504@iam.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0609211141500.30462-100000@cens.kybi>



> pearu at cens.ioc.ee wrote:
> >
> > On Thu, 21 Sep 2006, Nils Wagner wrote:
> >
> >   
> >> Hi all,
> >>
> >> I added xplt to the packages in enabled_packages.txt
> >>
> >> python setup.py install results in
> >>
> >> /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
> >> cannot find -lX11
> >> collect2: ld returned 1 exit status
> >>
> >> locate libX11 yields
> >>
> >> /usr/lib/NX/lib/libX11.so.6
> >> /usr/lib/NX/lib/libX11.so.6.2
> >> /usr/X11R6/lib/libX11.so.6
> >> /usr/X11R6/lib/libX11.so.6.2
> >> /usr/X11R6/lib64/libX11.a
> >> /usr/X11R6/lib64/libX11.so
> >> /usr/X11R6/lib64/libX11.so.6
> >> /usr/X11R6/lib64/libX11.so.6.2
> >>
> >>
> >> How can I fix this problem ?

You need to add /usr/X11R6/lib64 directory to default_x11_lib_dirs list in
system_info.py, and also update default_x11_include_dirs accordingly.

HTH,
Pearu



From nwagner at iam.uni-stuttgart.de  Thu Sep 21 05:06:46 2006
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Sep 2006 11:06:46 +0200
Subject: [SciPy-dev] sandbox xplt
In-Reply-To: <Pine.LNX.4.21.0609211141500.30462-100000@cens.kybi>
References: <Pine.LNX.4.21.0609211141500.30462-100000@cens.kybi>
Message-ID: <45125626.6040801@iam.uni-stuttgart.de>

pearu at cens.ioc.ee wrote:
>   
>> pearu at cens.ioc.ee wrote:
>>     
>>> On Thu, 21 Sep 2006, Nils Wagner wrote:
>>>
>>>   
>>>       
>>>> Hi all,
>>>>
>>>> I added xplt to the packages in enabled_packages.txt
>>>>
>>>> python setup.py install results in
>>>>
>>>> /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
>>>> cannot find -lX11
>>>> collect2: ld returned 1 exit status
>>>>
>>>> locate libX11 yields
>>>>
>>>> /usr/lib/NX/lib/libX11.so.6
>>>> /usr/lib/NX/lib/libX11.so.6.2
>>>> /usr/X11R6/lib/libX11.so.6
>>>> /usr/X11R6/lib/libX11.so.6.2
>>>> /usr/X11R6/lib64/libX11.a
>>>> /usr/X11R6/lib64/libX11.so
>>>> /usr/X11R6/lib64/libX11.so.6
>>>> /usr/X11R6/lib64/libX11.so.6.2
>>>>
>>>>
>>>> How can I fix this problem ?
>>>>         
>
> You need to add /usr/X11R6/lib64 directory to default_x11_lib_dirs list in
> system_info.py, and also update default_x11_include_dirs accordingly.
>
> HTH,
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   
This is the X11 part of my modified system_info.py

[x11]
library_dirs = /usr/X11R6/lib:/usr/X11R6/lib64
include_dirs = /usr/X11R6/include
 
I have installed numpy from scratch.

python setup.py install

results in

/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
cannot find -lX11
collect2: ld returned 1 exit status
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
cannot find -lX11
collect2: ld returned 1 exit status
error: Command "gcc -pthread -shared
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/pygist/gistCmodule.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/gist.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/tick.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/tick60.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/engine.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/gtext.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/draw.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/draw0.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/clip.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/gread.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/gcntr.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/hlevel.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/ps.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/cgm.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/eps.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/style.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/xfancy.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/gist/xbasic.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/dir.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/files.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/fpuset.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/pathnm.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/timew.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/uevent.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/ugetc.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/umain.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/usernm.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/unix/slinks.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/colors.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/connect.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/cursors.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/errors.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/events.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/fills.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/fonts.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/images.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/lines.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/pals.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/pwin.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/resource.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/rgbread.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/textout.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/rect.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/clips.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/x11/points.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/hash.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/hash0.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/mm.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/alarms.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/pstrcpy.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/pstrncat.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/p595.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/bitrev.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/bitlrot.o
build/temp.linux-x86_64-2.4/Lib/sandbox/xplt/src/play/all/bitmrot.o
-LLib/sandbox/xplt/. -LLib/sandbox/xplt/src -L/usr/lib
-Lbuild/temp.linux-x86_64-2.4 -lX11 -lm -o
build/lib.linux-x86_64-2.4/scipy/sandbox/xplt/gistC.so" failed with exit
status 1

Am I missing something ?

Nils



From pearu at cens.ioc.ee  Thu Sep 21 05:13:15 2006
From: pearu at cens.ioc.ee (pearu at cens.ioc.ee)
Date: Thu, 21 Sep 2006 12:13:15 +0300 (EEST)
Subject: [SciPy-dev] sandbox xplt
In-Reply-To: <45125626.6040801@iam.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0609211211110.30462-100000@cens.kybi>



On Thu, 21 Sep 2006, Nils Wagner wrote:

> > You need to add /usr/X11R6/lib64 directory to default_x11_lib_dirs list in
> > system_info.py, and also update default_x11_include_dirs accordingly.
> >
> > HTH,
> > Pearu
> >   
> This is the X11 part of my modified system_info.py
> 
> [x11]
> library_dirs = /usr/X11R6/lib:/usr/X11R6/lib64
> include_dirs = /usr/X11R6/include

This is example in the header of system_info.py, it has no effect.
Please modify the lists starting at line #146.

Pearu



From nwagner at iam.uni-stuttgart.de  Thu Sep 21 05:18:19 2006
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Sep 2006 11:18:19 +0200
Subject: [SciPy-dev] sandbox xplt
In-Reply-To: <Pine.LNX.4.21.0609211211110.30462-100000@cens.kybi>
References: <Pine.LNX.4.21.0609211211110.30462-100000@cens.kybi>
Message-ID: <451258DB.1060109@iam.uni-stuttgart.de>

pearu at cens.ioc.ee wrote:
> On Thu, 21 Sep 2006, Nils Wagner wrote:
>
>   
>>> You need to add /usr/X11R6/lib64 directory to default_x11_lib_dirs list in
>>> system_info.py, and also update default_x11_include_dirs accordingly.
>>>
>>> HTH,
>>> Pearu
>>>   
>>>       
>> This is the X11 part of my modified system_info.py
>>
>> [x11]
>> library_dirs = /usr/X11R6/lib:/usr/X11R6/lib64
>> include_dirs = /usr/X11R6/include
>>     
>
> This is example in the header of system_info.py, it has no effect.
> Please modify the lists starting at line #146.
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   
OK - but is the order important ? I mean

default_x11_lib_dirs =
['/usr/X11R6/lib','/usr/X11/lib','/usr/lib','/usr/X11R6/lib64']

default_x11_lib_dirs =
['/usr/X11R6/lib64','/usr/X11R6/lib','/usr/X11/lib','/usr/lib']


Nils



From pearu at cens.ioc.ee  Thu Sep 21 05:23:00 2006
From: pearu at cens.ioc.ee (pearu at cens.ioc.ee)
Date: Thu, 21 Sep 2006 12:23:00 +0300 (EEST)
Subject: [SciPy-dev] sandbox xplt
In-Reply-To: <451258DB.1060109@iam.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.21.0609211221170.30462-100000@cens.kybi>


On Thu, 21 Sep 2006, Nils Wagner wrote:

> pearu at cens.ioc.ee wrote:
> > On Thu, 21 Sep 2006, Nils Wagner wrote:
> >
> >   
> >>> You need to add /usr/X11R6/lib64 directory to default_x11_lib_dirs list in
> >>> system_info.py, and also update default_x11_include_dirs accordingly.
> >>>
> >>> HTH,
> >>> Pearu
> >>>   
> >>>       
> >> This is the X11 part of my modified system_info.py
> >>
> >> [x11]
> >> library_dirs = /usr/X11R6/lib:/usr/X11R6/lib64
> >> include_dirs = /usr/X11R6/include
> >>     
> >
> > This is example in the header of system_info.py, it has no effect.
> > Please modify the lists starting at line #146.
> >
> > Pearu
> >
> > _______________________________________________
> > Scipy-dev mailing list
> > Scipy-dev at scipy.org
> > http://projects.scipy.org/mailman/listinfo/scipy-dev
> >   
> OK - but is the order important ? I mean
> 
> default_x11_lib_dirs =
> ['/usr/X11R6/lib','/usr/X11/lib','/usr/lib','/usr/X11R6/lib64']
> 
> default_x11_lib_dirs =
> ['/usr/X11R6/lib64','/usr/X11R6/lib','/usr/X11/lib','/usr/lib']

The order is only important if /usr/X11R6/lib contains libX11.a file.
In general, if you know where the desired library is then put its
location first in the list. So, I would use the second version.

Pearu



From nwagner at iam.uni-stuttgart.de  Thu Sep 21 05:30:30 2006
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Sep 2006 11:30:30 +0200
Subject: [SciPy-dev] sandbox xplt
In-Reply-To: <Pine.LNX.4.21.0609211221170.30462-100000@cens.kybi>
References: <Pine.LNX.4.21.0609211221170.30462-100000@cens.kybi>
Message-ID: <45125BB6.4090904@iam.uni-stuttgart.de>

pearu at cens.ioc.ee wrote:
> On Thu, 21 Sep 2006, Nils Wagner wrote:
>
>   
>> pearu at cens.ioc.ee wrote:
>>     
>>> On Thu, 21 Sep 2006, Nils Wagner wrote:
>>>
>>>   
>>>       
>>>>> You need to add /usr/X11R6/lib64 directory to default_x11_lib_dirs list in
>>>>> system_info.py, and also update default_x11_include_dirs accordingly.
>>>>>
>>>>> HTH,
>>>>> Pearu
>>>>>   
>>>>>       
>>>>>           
>>>> This is the X11 part of my modified system_info.py
>>>>
>>>> [x11]
>>>> library_dirs = /usr/X11R6/lib:/usr/X11R6/lib64
>>>> include_dirs = /usr/X11R6/include
>>>>     
>>>>         
>>> This is example in the header of system_info.py, it has no effect.
>>> Please modify the lists starting at line #146.
>>>
>>> Pearu
>>>
>>> _______________________________________________
>>> Scipy-dev mailing list
>>> Scipy-dev at scipy.org
>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>   
>>>       
>> OK - but is the order important ? I mean
>>
>> default_x11_lib_dirs =
>> ['/usr/X11R6/lib','/usr/X11/lib','/usr/lib','/usr/X11R6/lib64']
>>
>> default_x11_lib_dirs =
>> ['/usr/X11R6/lib64','/usr/X11R6/lib','/usr/X11/lib','/usr/lib']
>>     
>
> The order is only important if /usr/X11R6/lib contains libX11.a file.
> In general, if you know where the desired library is then put its
> location first in the list. So, I would use the second version.
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>   

Thank you very much - now the installation works fine but if I try to
import xplt I get

>>> from scipy.sandbox import xplt
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/__init__.py",
line 48, in ?
    from Mplot import *
  File "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/Mplot.py",
line 13, in ?
    import numpy.lib.mlab as MLab
ImportError: No module named mlab

Should I file a ticket ?

Nils



From nwagner at iam.uni-stuttgart.de  Thu Sep 21 06:56:01 2006
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Sep 2006 12:56:01 +0200
Subject: [SciPy-dev] slice3.py and xplt
Message-ID: <45126FC1.50603@iam.uni-stuttgart.de>

Hi all,

Meanwhile I have replaced numpy.lib.mlab by numpy.oldnumeric.mlab in
Mplot.py

The nexr problem is

>>> from scipy.sandbox import xplt
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/__init__.py",
line 48, in ?
    from Mplot import *
  File "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/Mplot.py",
line 1013, in ?
    import colorbar
  File
"/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/colorbar.py",
line 11, in ?
    from slice3 import *
  File
"/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/slice3.py", line
1585, in ?
    _poly_permutations4 = _construct3 (0)
  File
"/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/slice3.py", line
1579, in _construct3
    mask = find_mask (below, _node_edges3 [itype])
TypeError: array cannot be safely cast to required type

How can I resolve this problem ?


Nils



From oliphant.travis at ieee.org  Thu Sep 21 12:34:14 2006
From: oliphant.travis at ieee.org (Travis Oliphant)
Date: Thu, 21 Sep 2006 10:34:14 -0600
Subject: [SciPy-dev] slice3.py and xplt
In-Reply-To: <45126FC1.50603@iam.uni-stuttgart.de>
References: <45126FC1.50603@iam.uni-stuttgart.de>
Message-ID: <4512BF06.4040903@ieee.org>

Nils Wagner wrote:
> Hi all,
>
> Meanwhile I have replaced numpy.lib.mlab by numpy.oldnumeric.mlab in
> Mplot.py
>
> The nexr problem is
>
>   
>>>> from scipy.sandbox import xplt
>>>>         
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File
> "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/__init__.py",
> line 48, in ?
>     from Mplot import *
>   File "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/Mplot.py",
> line 1013, in ?
>     import colorbar
>   File
> "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/colorbar.py",
> line 11, in ?
>     from slice3 import *
>   File
> "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/slice3.py", line
> 1585, in ?
>     _poly_permutations4 = _construct3 (0)
>   File
> "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/slice3.py", line
> 1579, in _construct3
>     mask = find_mask (below, _node_edges3 [itype])
> TypeError: array cannot be safely cast to required type
>
> How can I resolve this problem ?
>
>   
There may be several 64-bit issues with xplt.   There was a lot of heavy 
use of the "int" type interchanged with the "long" type.  On 32-bit 
platforms this is not a problem, but trying to "automatically" 
converting from "long" to "int" on a 64-bit platform will give you this 
kind of error.  

-Travis



From nwagner at iam.uni-stuttgart.de  Thu Sep 21 13:13:03 2006
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Thu, 21 Sep 2006 19:13:03 +0200
Subject: [SciPy-dev] slice3.py and xplt
In-Reply-To: <4512BF06.4040903@ieee.org>
References: <45126FC1.50603@iam.uni-stuttgart.de> <4512BF06.4040903@ieee.org>
Message-ID: <web-57190868@uni-stuttgart.de>

On Thu, 21 Sep 2006 10:34:14 -0600
  Travis Oliphant <oliphant.travis at ieee.org> wrote:
> Nils Wagner wrote:
>> Hi all,
>>
>> Meanwhile I have replaced numpy.lib.mlab by 
>>numpy.oldnumeric.mlab in
>> Mplot.py
>>
>> The nexr problem is
>>
>>   
>>>>> from scipy.sandbox import xplt
>>>>>         
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>>   File
>> "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/__init__.py",
>> line 48, in ?
>>     from Mplot import *
>>   File 
>>"/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/Mplot.py",
>> line 1013, in ?
>>     import colorbar
>>   File
>> "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/colorbar.py",
>> line 11, in ?
>>     from slice3 import *
>>   File
>> "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/slice3.py", 
>>line
>> 1585, in ?
>>     _poly_permutations4 = _construct3 (0)
>>   File
>> "/usr/lib64/python2.4/site-packages/scipy/sandbox/xplt/slice3.py", 
>>line
>> 1579, in _construct3
>>     mask = find_mask (below, _node_edges3 [itype])
>> TypeError: array cannot be safely cast to required type
>>
>> How can I resolve this problem ?
>>
>>   
> There may be several 64-bit issues with xplt.   There 
>was a lot of heavy 
> use of the "int" type interchanged with the "long" type. 
> On 32-bit 
> platforms this is not a problem, but trying to 
>"automatically" 
> converting from "long" to "int" on a 64-bit platform 
>will give you this 
> kind of error.  
> 
Travis,

Is there a chance that these problems will be fixed in
a couple of weeks ?

The bug tracker has no entry for sandbox packages.
Is this intentional ?

Nils

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

  


From robert.kern at gmail.com  Thu Sep 21 13:50:48 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 21 Sep 2006 12:50:48 -0500
Subject: [SciPy-dev] slice3.py and xplt
In-Reply-To: <web-57190868@uni-stuttgart.de>
References: <45126FC1.50603@iam.uni-stuttgart.de> <4512BF06.4040903@ieee.org>
	<web-57190868@uni-stuttgart.de>
Message-ID: <4512D0F8.2030908@gmail.com>

Nils Wagner wrote:

> Travis,
> 
> Is there a chance that these problems will be fixed in
> a couple of weeks ?

Not from any of us, I don't think. xplt is unmaintained.

> The bug tracker has no entry for sandbox packages.
> Is this intentional ?

Use "Other".

-- 
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


From stefan at sun.ac.za  Thu Sep 21 13:56:57 2006
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 21 Sep 2006 19:56:57 +0200
Subject: [SciPy-dev] slice3.py and xplt
In-Reply-To: <web-57190868@uni-stuttgart.de>
References: <45126FC1.50603@iam.uni-stuttgart.de> <4512BF06.4040903@ieee.org>
	<web-57190868@uni-stuttgart.de>
Message-ID: <20060921175657.GA12845@mentat.za.net>

On Thu, Sep 21, 2006 at 07:13:03PM +0200, Nils Wagner wrote:
> On Thu, 21 Sep 2006 10:34:14 -0600
> > There may be several 64-bit issues with xplt.   There 
> >was a lot of heavy 
> > use of the "int" type interchanged with the "long" type. 
> > On 32-bit 
> > platforms this is not a problem, but trying to 
> >"automatically" 
> > converting from "long" to "int" on a 64-bit platform 
> >will give you this 
> > kind of error.  
> > 
> Travis,
> 
> Is there a chance that these problems will be fixed in
> a couple of weeks ?

There is an excellent chance, if you provide a patch.  Otherwise, it
usually depends on whether any of the developers a) has the time and
b) sees your problem as a priority.

In the meanwhile, why don't you use matplotlib?

Regards
St?fan


From cookedm at physics.mcmaster.ca  Thu Sep 21 18:34:03 2006
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Thu, 21 Sep 2006 18:34:03 -0400
Subject: [SciPy-dev] patches for Intel MKL fft support (complex only)
In-Reply-To: <3a1077e70609201507k5b9576f4q14736f1eef432f0d@mail.gmail.com>
References: <3a1077e70609201025g11449154x873106554b27355e@mail.gmail.com>
	<E1GQ8xx-0005xo-P1@mail2.sun.ac.za>
	<3a1077e70609201507k5b9576f4q14736f1eef432f0d@mail.gmail.com>
Message-ID: <20060921183403.6e6fbe4b@arbutus.physics.mcmaster.ca>

On Wed, 20 Sep 2006 23:07:39 +0100
"John Travers" <jtravs at gmail.com> wrote:

> Thanks, I have done as you suggested.
> This topic can now be followed with scipy Trac ticket #268
> Best regards,
> John

I applied the scipy one; I don't want to apply the numpy one until 1.0 is
released and we've done a scipy release to go along with it.

> > > -----Original Message-----
> > > From: scipy-dev-bounces at scipy.org [mailto:scipy-dev-bounces at scipy.org]
> > > On Behalf Of John Travers
> > > Sent: 20 September 2006 19:25
> > > To: scipy-dev at scipy.org
> > > Subject: [SciPy-dev] patches for Intel MKL fft support (complex only)
> > >
> > > Hi all,
> > >
> > > Attached are two patches that combined will enable support for the use
> > > of Intel MKL fft library calls in scipy.fftpack. At the moment only
> > > complex transforms zfft and zfftnd and their inverses are supported.
> > > Convolution and real transforms are in progress.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca


From cookedm at physics.mcmaster.ca  Thu Sep 21 18:35:44 2006
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Thu, 21 Sep 2006 18:35:44 -0400
Subject: [SciPy-dev] Include patch in ticket {1} (slow fft when using
 fftw3) ?
In-Reply-To: <45092FD0.3040600@ar.media.kyoto-u.ac.jp>
References: <45092FD0.3040600@ar.media.kyoto-u.ac.jp>
Message-ID: <20060921183544.236ae451@arbutus.physics.mcmaster.ca>

On Thu, 14 Sep 2006 19:32:48 +0900
David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:

> Hi,
> 
>     I would like to know if it would be possible to include the patch I 
> posted to solve the slow fft in scipy problem (scipy ticket 1). I am 
> using it myself for some time, never failed on me, and have a dramatic 
> influence on speed (between 2 and 5 for complex input 1d fft),

Sorry about the delay; but I've applied it now.

I'm going to continue looking at splitting support for the different fft
packages out into separate files (especially now that support for the Intel
MKL library has been added).

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca


From jtravs at gmail.com  Fri Sep 22 13:41:21 2006
From: jtravs at gmail.com (John Travers)
Date: Fri, 22 Sep 2006 18:41:21 +0100
Subject: [SciPy-dev] Include patch in ticket {1} (slow fft when using
	fftw3) ?
In-Reply-To: <20060921183544.236ae451@arbutus.physics.mcmaster.ca>
References: <45092FD0.3040600@ar.media.kyoto-u.ac.jp>
	<20060921183544.236ae451@arbutus.physics.mcmaster.ca>
Message-ID: <3a1077e70609221041l26dd1b74pe708699fd4d3adef@mail.gmail.com>

On 21/09/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:

> I'm going to continue looking at splitting support for the different fft
> packages out into separate files (especially now that support for the Intel
> MKL library has been added).

After recently hacking at the fftpack code the idea of reorganising
the fftpack files seems like a good one. I'm offering my services to
help! (esp. for MKL/fftw3).

I think you have posted before about this, but to get a better idea of
what your plan is, are you thinking of:

1. Exposing access to the underlying libraries in an advanced
interface? So that people who really care can control things more
easily (such as detailed fftw3 plans etc, saving fftw wisdom etc.)

2. Enabling the user to select which backend is used at runtime
(should be simple to implement if the above is covered), while
providing a reasonable default.

Some points about the above:

a. I think the first item would take some thought to get right due to
the size of the interfaces to these libraries. Simplifying it into a
reasonable python implementation could be done incrementally though I
guess.

b. We should make sure that performance isn't compromised in any way
and the generic (current) interface always works with at least current
performance.

c. We shouldn't try to add functionality just for the sake of it. For
me, access to the guru interface of fftw is very useful in my work as
I need very large numbers of ffts on the same data, but this could be
my minority case and the resulting interface may end up being too
bloated.

d. It would certainly be easier to maintain the code if the basic
library functionality was separated (and all compiled if available -
getting rid of all those #idefs) - and then the high level generic
interface were in python only and selected the relevant library.

David, how far have you got with your efforts, and can I help in any way?
Anybody else have any comments or suggestions?

Regards,
John Travers


From jtravs at gmail.com  Fri Sep 22 13:55:21 2006
From: jtravs at gmail.com (John Travers)
Date: Fri, 22 Sep 2006 18:55:21 +0100
Subject: [SciPy-dev] patches for Intel MKL fft support (complex only)
In-Reply-To: <20060921183403.6e6fbe4b@arbutus.physics.mcmaster.ca>
References: <3a1077e70609201025g11449154x873106554b27355e@mail.gmail.com>
	<E1GQ8xx-0005xo-P1@mail2.sun.ac.za>
	<3a1077e70609201507k5b9576f4q14736f1eef432f0d@mail.gmail.com>
	<20060921183403.6e6fbe4b@arbutus.physics.mcmaster.ca>
Message-ID: <3a1077e70609221055o2fc8a401w74324d6bb73988c6@mail.gmail.com>

OK, thanks for doing that.

Attached is another patch that slightly enhances ifft performance with
MKL by doing the normalisation with the ifft calculation. Patches for
real data ffts are being prepared.

I'm still slightly concerned that I might not have got the numpy patch
quite right - any chance that someone who is a distutils guru could
run their eye over it?

Thanks
John

On 21/09/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:
> On Wed, 20 Sep 2006 23:07:39 +0100
> "John Travers" <jtravs at gmail.com> wrote:
>
> > Thanks, I have done as you suggested.
> > This topic can now be followed with scipy Trac ticket #268
> > Best regards,
> > John
>
> I applied the scipy one; I don't want to apply the numpy one until 1.0 is
> released and we've done a scipy release to go along with it.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkl_fft_scipy2.patch
Type: application/octet-stream
Size: 1019 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20060922/bbd73590/attachment.obj>

From fperez.net at gmail.com  Wed Sep 27 21:57:20 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 27 Sep 2006 19:57:20 -0600
Subject: [SciPy-dev] A question about the moin site
Message-ID: <451B2C00.9070608@gmail.com>

Hi all,

we've just 'officially moved' ipython to a moin site similar to the scipy one,
but I have a few questoins our site gurus may help with:

1. Figures: the scipy pages use for figures code like:

{{{
#!figure
...
}}}

I tried that but it doesn't work out of the box.  Is there something I can do
on my side, or install in the wiki/ directory, for this to work?  I'm sure
it's something very simple, but googling hasn't revealed the magical
incantation so far.

2. reST: is there an easy way to have moin link to reST documents and render
them into HTML?  Some of the new ipython docs (README, etc) are in reST and it
would be great to show them nicely formatted on the site.

3. Latex: this parser seems very nice:

http://johannes.sipsolutions.net/Projects/new-moinmoin-latex

I'm currently testing it on the ipython moin, but perhaps the python process
hasn't been reloaded, because so far it doesn't seem to work yet.  I'll give
it a bit more time (is there any signal one can send to some process to force
a reload of moin when changes like this are being tested?).

I was thinking it would be very nice to have reST and Latex support on the
Scipy wiki as well, as I hope that in the long term, the scipy wiki should
grow pages with detailed algorithmic and mathematical discussions, and for
such, latex is necessary.

Thanks for any help!

Best,

f



From robert.kern at gmail.com  Wed Sep 27 23:23:52 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 27 Sep 2006 22:23:52 -0500
Subject: [SciPy-dev] A question about the moin site
In-Reply-To: <451B2C00.9070608@gmail.com>
References: <451B2C00.9070608@gmail.com>
Message-ID: <451B4048.4010303@gmail.com>

Fernando Perez wrote:

> 2. reST: is there an easy way to have moin link to reST documents and render
> them into HTML?  Some of the new ipython docs (README, etc) are in reST and it
> would be great to show them nicely formatted on the site.

{{{#!rst
reStructuredText
----------------

Paragraph.

* bullet

   + another bullet
}}}

It works on www.scipy.org . However, some permissions seem to be wrong for 
ipython.scipy.org. mod_python can't read the CSS file inside the docutils 
package. Go ahead and bug Jeff about that.

-- 
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


From david at ar.media.kyoto-u.ac.jp  Thu Sep 28 00:17:12 2006
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Thu, 28 Sep 2006 13:17:12 +0900
Subject: [SciPy-dev] packages inside and outside scipy distribution
Message-ID: <451B4CC8.7060105@ar.media.kyoto-u.ac.jp>

Hi,

    I would like to know what is the preferred approach to format a 
package for numpy/scipy, developed outside scipy (but eventually to be 
included in scipy), particularly the meta-files. I have already a 
working package, but I would like it to conform to scipy 'standards' for 
packaging (doc, tests, etc...). For now, the structure of the package is:

root_dir/ where there are files such as README, LICENSE, Changelog, etc...
root_dir/pkg_name where the implementation is (eventually in 
sub-directories)

For now, the setup.py is in root_dir, because I don't want to 'pollute' 
root_dir/pkg_name with files which are not a part of the "binary" 
distribution (by binary, I mean here all the files required by the 
package to work, including the doc). If I understand correctly, a scipy 
package should not have a root_dir, but everything, including the 
setup.py in the root_dir/pkg_name. Is there a way to do that without 
polluting the directory with files produced by setup.py, such as dist 
dir, MANIFEST, etc... ?

    More fundamentally, what would be a sensible approach to develop a 
package 'outside scipy', with the goal to propose it for inclusion into 
scipy later ?

    cheers,

    David


From kamrik at gmail.com  Thu Sep 28 03:28:04 2006
From: kamrik at gmail.com (Mark Koudritsky)
Date: Thu, 28 Sep 2006 10:28:04 +0300
Subject: [SciPy-dev] A question about the moin site
In-Reply-To: <451B2C00.9070608@gmail.com>
References: <451B2C00.9070608@gmail.com>
Message-ID: <d28cf58e0609280028x5d1335achc256f085cb575e78@mail.gmail.com>

>
> 1. Figures: the scipy pages use for figures code like:
>
> {{{
> #!figure
> ...
> }}}

For this syntax to work the sections parser needs to be installed.
http://moinmoin.wikiwikiweb.de/SectionParser



> 3. Latex:

An alternative would be to use ASCIIMathML for formulae, it also
understands LaTeX syntax, and there is an _almost_  WYSWYG editor for
it here: http://www1.chapman.edu/~jipsen/mathml/asciimathdemo.html

The page about integration of ASCIIMathML into moin is here:
http://moinmoin.wikiwikiweb.de/MathMlSupport
the page is a bit messy but the process as actually very simple, I
have it implemented on our student wiki
http://www.weizmann.ac.il/student-wiki/HelpOnMath
so I can help with somewhat clearer instructions if you decide to use
ASCIIMathML.


Regards
  - Mark


From fperez.net at gmail.com  Thu Sep 28 16:39:37 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 28 Sep 2006 14:39:37 -0600
Subject: [SciPy-dev] A question about the moin site
In-Reply-To: <d28cf58e0609280028x5d1335achc256f085cb575e78@mail.gmail.com>
References: <451B2C00.9070608@gmail.com>
	<d28cf58e0609280028x5d1335achc256f085cb575e78@mail.gmail.com>
Message-ID: <db6b5ecc0609281339k32e25cftec2a5ec25e4e659d@mail.gmail.com>

On 9/28/06, Mark Koudritsky <kamrik at gmail.com> wrote:
> >
> > 1. Figures: the scipy pages use for figures code like:
> >
> > {{{
> > #!figure
> > ...
> > }}}
>
> For this syntax to work the sections parser needs to be installed.
> http://moinmoin.wikiwikiweb.de/SectionParser

[...]

Thanks to both for the info.  I'll add the necessary parsers, and will
bug Joe about the permissions issues.

Regards,

f


From lars.bittrich at googlemail.com  Fri Sep 29 12:11:36 2006
From: lars.bittrich at googlemail.com (Lars Bittrich)
Date: Fri, 29 Sep 2006 18:11:36 +0200
Subject: [SciPy-dev] from scipy import maxentropy fails with Python 2.5
Message-ID: <200609291811.36818.lars.bittrich@googlemail.com>

Hi all,

I tried to compile scipy with Python 2.5 and Intel C++/Fortran compiler. The 
first import failed:

In [1]:from scipy import *
------------------------------------------------------------
? ?File "[...]/lib/python2.5/site-packages/scipy/maxentropy/maxentropy.py", 
line 69
? ? ?from __future__ import division
<type 'exceptions.SyntaxError'>: from __future__ imports must occur at the 
beginning of the file

That problem was easy to fix just by following the instructions of that 
message in 2 files:

scipy/maxentropy/maxentropy.py ?
scipy/maxentropy/maxentutils.py

Is that import necessary with Python 2.5 or even Python 2.4?

Best regards,

Lars


From robert.kern at gmail.com  Fri Sep 29 12:47:57 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 29 Sep 2006 11:47:57 -0500
Subject: [SciPy-dev] from scipy import maxentropy fails with Python 2.5
In-Reply-To: <200609291811.36818.lars.bittrich@googlemail.com>
References: <200609291811.36818.lars.bittrich@googlemail.com>
Message-ID: <451D4E3D.4090709@gmail.com>

Lars Bittrich wrote:
> Hi all,
> 
> I tried to compile scipy with Python 2.5 and Intel C++/Fortran compiler. The 
> first import failed:
> 
> In [1]:from scipy import *
> ------------------------------------------------------------
>    File "[...]/lib/python2.5/site-packages/scipy/maxentropy/maxentropy.py", 
> line 69
>      from __future__ import division
> <type 'exceptions.SyntaxError'>: from __future__ imports must occur at the 
> beginning of the file
> 
> That problem was easy to fix just by following the instructions of that 
> message in 2 files:
> 
> scipy/maxentropy/maxentropy.py  
> scipy/maxentropy/maxentutils.py
> 
> Is that import necessary with Python 2.5 or even Python 2.4?

Yes. Integer division will not be changing in the 2.x releases.

I'm checking in a change that moves those statements up, but not before 
docstrings. I don't have a 2.5 interpreter to check this out with, and I can see 
no reference to it in the "What's New" documentation, so please let me know if 
it works for you.

-- 
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


From cookedm at physics.mcmaster.ca  Fri Sep 29 14:53:52 2006
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Fri, 29 Sep 2006 14:53:52 -0400
Subject: [SciPy-dev] from scipy import maxentropy fails with Python 2.5
In-Reply-To: <451D4E3D.4090709@gmail.com>
References: <200609291811.36818.lars.bittrich@googlemail.com>
	<451D4E3D.4090709@gmail.com>
Message-ID: <20060929145352.56a3d7ac@arbutus.physics.mcmaster.ca>

On Fri, 29 Sep 2006 11:47:57 -0500
Robert Kern <robert.kern at gmail.com> wrote:

> Lars Bittrich wrote:
> > Hi all,
> > 
> > I tried to compile scipy with Python 2.5 and Intel C++/Fortran compiler.
> > The first import failed:
> > 
> > In [1]:from scipy import *
> > ------------------------------------------------------------
> >    File
> > "[...]/lib/python2.5/site-packages/scipy/maxentropy/maxentropy.py", line
> > 69 from __future__ import division
> > <type 'exceptions.SyntaxError'>: from __future__ imports must occur at
> > the beginning of the file
> > 
> > That problem was easy to fix just by following the instructions of that 
> > message in 2 files:
> > 
> > scipy/maxentropy/maxentropy.py  
> > scipy/maxentropy/maxentutils.py
> > 
> > Is that import necessary with Python 2.5 or even Python 2.4?
> 
> Yes. Integer division will not be changing in the 2.x releases.
> 
> I'm checking in a change that moves those statements up, but not before 
> docstrings. I don't have a 2.5 interpreter to check this out with, and I
> can see no reference to it in the "What's New" documentation, so please let
> me know if it works for you.

FWIW, it's been true since 2.1, that __future__ statements have to be
the first bit of code in the module (excluding docstrings); see PEP 236
(http://www.python.org/dev/peps/pep-0236/).

Looks like that hasn't been enforced for < 2.5 for features that the
interpreter supports (although for non-supported features, like "from
__future__ import blah", all the versions I have complain).

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca


From oliphant at ee.byu.edu  Fri Sep 29 20:28:29 2006
From: oliphant at ee.byu.edu (Travis Oliphant)
Date: Fri, 29 Sep 2006 18:28:29 -0600
Subject: [SciPy-dev] Online SciPy Journal
Message-ID: <451DBA2D.3070104@ee.byu.edu>

As most of you know, I'm at an academic institution and have a strong 
belief that open source should mesh better with the academic world then 
it currently does.  One of the problems, is that it is not easy to just 
point to open source software as a "publication" which is one of the 
areas that most tenure-granting boards look at when deciding on a 
candidate.

To help with that a little-bit,  I'd really like to get a peer-reviewed 
on-line journal for code contributed to SciPy started.  Not to implicate 
him if he no longer thinks it's a good idea, but I first started 
thinking seriously about this at SciPy 2006 when Fernando Perez 
mentioned he had seen this model with a math-related software package 
and thought we could try something similar.

Exactly what form that will take is worth some discussion.  Most 
"publications" are viewed highly because they are "peer-reviewed".   It 
seems to me, that we have all the makings of a community that could 
peer-review code contributed to SciPy.  I'd like to see two parts to 
"the journal" (maybe they are separate).  One is the code itself.  Not 
all of the code currently in SciPy is "journal" quality (I look no 
further than many of my own contributions...)

We would need a way to specify what is "published" SciPy and what is not 
(besides the sandbox mechansim).    The other aspect to the SciPy 
Journal is an "article" that goes into detail about some particular code 
contributed to SciPy.  Not all code will need this, but many 
contributions will.  This is where the design decisions are discussed 
and recorded. 

Such a project needs many associate editors who would help find 
reviewers and make decisions about publication.  If this project works, 
it is one means that would allow me to spend more time on SciPy and 
"have it count" toward academic rank and status.   I have not thought it 
through well enough to have the details ironed out, but I'm soliciting 
feedback from you who would likely be involved.

Besides your comments, I would like a response on at least two 
questions:  +1, -1, +0, -0  voting.


1) Do you like the idea ?

2) Could you help (i.e. as an editor, reviewer, etc.)? 




From robert.kern at gmail.com  Fri Sep 29 20:42:41 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 29 Sep 2006 19:42:41 -0500
Subject: [SciPy-dev] Online SciPy Journal
In-Reply-To: <451DBA2D.3070104@ee.byu.edu>
References: <451DBA2D.3070104@ee.byu.edu>
Message-ID: <451DBD81.2010808@gmail.com>

Travis Oliphant wrote:
> As most of you know, I'm at an academic institution and have a strong 
> belief that open source should mesh better with the academic world then 
> it currently does.  One of the problems, is that it is not easy to just 
> point to open source software as a "publication" which is one of the 
> areas that most tenure-granting boards look at when deciding on a 
> candidate.
> 
> To help with that a little-bit,  I'd really like to get a peer-reviewed 
> on-line journal for code contributed to SciPy started.  Not to implicate 
> him if he no longer thinks it's a good idea, but I first started 
> thinking seriously about this at SciPy 2006 when Fernando Perez 
> mentioned he had seen this model with a math-related software package 
> and thought we could try something similar.

Indeed! Another example is the _Journal of Statistical Software_ which is a 
free, online, peer-reviewed journal focused on statistical software. Looking at 
the articles, I sometimes wonder if it just should have been called the _Journal 
of R_, but I digress. It seems to be well-done.

> 1) Do you like the idea ?

+1!

> 2) Could you help (i.e. as an editor, reviewer, etc.)? 

+1

-- 
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


From gregwillden at gmail.com  Fri Sep 29 23:54:47 2006
From: gregwillden at gmail.com (Greg Willden)
Date: Fri, 29 Sep 2006 22:54:47 -0500
Subject: [SciPy-dev] Intro / Docstrings
Message-ID: <903323ff0609292054v3d5457d5w16cabd5dad25615@mail.gmail.com>

Hello all,

The FAQ says if you want to help out drop you line.  Here is my line:

I'm pretty new to numpy/scipy but I've been using Python for a while now.
I have a long history of Matlab use but I'm gradually weaning myself.

I would like to contribute to this project by adding a few things to the
docstrings that will help new people like myself get their bearings.  I love
Python and would really like to get really good with numpy/scipy/matplotlib.

I want to see more "See also:" portions on the end of the docstrings.   This
is something that Matlab does well that makes it easy to learn about new,
related functions.

What is the best way for me to contribute?
Whom would I submit patches to?  This list or an individual?


Thanks
Greg
-- 
Linux.  Because rebooting is for adding hardware.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20060929/8079c202/attachment.html>

From robert.kern at gmail.com  Sat Sep 30 00:19:28 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 29 Sep 2006 23:19:28 -0500
Subject: [SciPy-dev] Intro / Docstrings
In-Reply-To: <903323ff0609292054v3d5457d5w16cabd5dad25615@mail.gmail.com>
References: <903323ff0609292054v3d5457d5w16cabd5dad25615@mail.gmail.com>
Message-ID: <451DF050.7050307@gmail.com>

Greg Willden wrote:
> Hello all,
> 
> The FAQ says if you want to help out drop you line.  Here is my line:
> 
> I'm pretty new to numpy/scipy but I've been using Python for a while now.
> I have a long history of Matlab use but I'm gradually weaning myself.
> 
> I would like to contribute to this project by adding a few things to the 
> docstrings that will help new people like myself get their bearings.  I 
> love Python and would really like to get really good with 
> numpy/scipy/matplotlib.

Wonderful! Welcome!

> I want to see more "See also:" portions on the end of the docstrings.   
> This is something that Matlab does well that makes it easy to learn 
> about new, related functions.
> 
> What is the best way for me to contribute? 

This is a good way to start. If you want to start with actual code, we still 
have quite a ways to go with the "Statistics Review" that I started too long ago.

   http://projects.scipy.org/scipy/scipy/wiki/StatisticsReview

There are plenty of bite-sized things to do in cleaning up scipy.stats .

> Whom would I submit patches to?  This list or an individual?

We use the Trac bug-tracking system for numpy and scipy. You will need to 
register accounts for them due to spammers.

   http://projects.scipy.org/scipy/numpy/register
   http://projects.scipy.org/scipy/scipy/register

After you do that, click on "New Ticket" in the upper right-hand corner. 
Describe your changes and submit the ticket. After the ticket is created, there 
will be an "Attach file" button which you can use to add your patch.

-- 
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


From wbaxter at gmail.com  Sat Sep 30 03:42:03 2006
From: wbaxter at gmail.com (Bill Baxter)
Date: Sat, 30 Sep 2006 16:42:03 +0900
Subject: [SciPy-dev] Online SciPy Journal
In-Reply-To: <451DBA2D.3070104@ee.byu.edu>
References: <451DBA2D.3070104@ee.byu.edu>
Message-ID: <e86a5fd00609300042j39086cc8r88fe6472df0844bd@mail.gmail.com>

On 9/30/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:
> Besides your comments, I would like a response on at least two
> questions:  +1, -1, +0, -0  voting.
>
>
> 1) Do you like the idea ?

+1

I like the idea, but at least in the world of computer graphics
research, writing about the implementation of some software is not
usually considered a topic for a publication.  At least I don't know
of any mainstream journals or conferences that have this kind of
slant.   Journal of Graphics Tools is probably the closest, but those
papers usually present a clever new algorithm of some sort, or useful
twist on an old one.  Novelty is always one of the main criteria for
reviewing anywhere I've sent papers.  So something like "implementing
an FFT module for SciPy" wouldn't go over well with any of the venues
I'm familiar with.  "There's nothing novel about the FFT" would be the
rejection.

The idea is pretty devious though..  I like it.  Excellent software
infrastructure really does lead to increased scientific progress, and
it doesn't happen by itself.  So a way for academics to get the kudos
they need to continue such efforts would be great.

> 2) Could you help (i.e. as an editor, reviewer, etc.)?

+1

--bb


From stefan at sun.ac.za  Sat Sep 30 03:42:34 2006
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Sat, 30 Sep 2006 09:42:34 +0200
Subject: [SciPy-dev] Intro / Docstrings
In-Reply-To: <451DF050.7050307@gmail.com>
References: <903323ff0609292054v3d5457d5w16cabd5dad25615@mail.gmail.com>
	<451DF050.7050307@gmail.com>
Message-ID: <20060930074234.GB1607@mentat.za.net>

Hi Robert

On Fri, Sep 29, 2006 at 11:19:28PM -0500, Robert Kern wrote:
> This is a good way to start. If you want to start with actual code, we still 
> have quite a ways to go with the "Statistics Review" that I started too long ago.
> 
>    http://projects.scipy.org/scipy/scipy/wiki/StatisticsReview
> 
> There are plenty of bite-sized things to do in cleaning up
> scipy.stats .

I've been tempted to help with this, but I'm not sure I understand
what "review" means exactly.  When is a function sufficiently
"reviewed" to close the ticket?  Must it conform to new style numpy,
must it be functionally accurate, functionally complete, or all of the
above?

Cheers
St?fan


From lars.bittrich at googlemail.com  Sat Sep 30 08:10:10 2006
From: lars.bittrich at googlemail.com (Lars Bittrich)
Date: Sat, 30 Sep 2006 14:10:10 +0200
Subject: [SciPy-dev] from scipy import maxentropy fails with Python 2.5
In-Reply-To: <451D4E3D.4090709@gmail.com>
References: <200609291811.36818.lars.bittrich@googlemail.com>
	<451D4E3D.4090709@gmail.com>
Message-ID: <200609301410.10958.lars.bittrich@googlemail.com>

On Friday 29 September 2006 18:47, Robert Kern wrote:
> Lars Bittrich wrote:
> > Hi all,
> >
> > I tried to compile scipy with Python 2.5 and Intel C++/Fortran compiler.
> > The first import failed:
> >
> > In [1]:from scipy import *
> > ------------------------------------------------------------
> >    File
> > "[...]/lib/python2.5/site-packages/scipy/maxentropy/maxentropy.py", line
> > 69
> >      from __future__ import division
> > <type 'exceptions.SyntaxError'>: from __future__ imports must occur at
> > the beginning of the file
> >
> > That problem was easy to fix just by following the instructions of that
> > message in 2 files:
> >
> > scipy/maxentropy/maxentropy.py
> > scipy/maxentropy/maxentutils.py
> >
> > Is that import necessary with Python 2.5 or even Python 2.4?
>
> Yes. Integer division will not be changing in the 2.x releases.
>
> I'm checking in a change that moves those statements up, but not before
> docstrings. I don't have a 2.5 interpreter to check this out with, and I
> can see no reference to it in the "What's New" documentation, so please let
> me know if it works for you.

Many thanks, that works fine now.

Best regards,

Lars


From david at ar.media.kyoto-u.ac.jp  Sat Sep 30 08:31:18 2006
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 30 Sep 2006 21:31:18 +0900
Subject: [SciPy-dev] Online SciPy Journal
In-Reply-To: <451DBA2D.3070104@ee.byu.edu>
References: <451DBA2D.3070104@ee.byu.edu>
Message-ID: <451E6396.7070401@ar.media.kyoto-u.ac.jp>

Travis Oliphant wrote:
> As most of you know, I'm at an academic institution and have a strong 
> belief that open source should mesh better with the academic world then 
> it currently does.  One of the problems, is that it is not easy to just 
> point to open source software as a "publication" which is one of the 
> areas that most tenure-granting boards look at when deciding on a 
> candidate.
>
> To help with that a little-bit,  I'd really like to get a peer-reviewed 
> on-line journal for code contributed to SciPy started.  Not to implicate 
> him if he no longer thinks it's a good idea, but I first started 
> thinking seriously about this at SciPy 2006 when Fernando Perez 
> mentioned he had seen this model with a math-related software package 
> and thought we could try something similar.
>
> Exactly what form that will take is worth some discussion.  Most 
> "publications" are viewed highly because they are "peer-reviewed".   It 
> seems to me, that we have all the makings of a community that could 
> peer-review code contributed to SciPy.  I'd like to see two parts to 
> "the journal" (maybe they are separate).  One is the code itself.  Not 
> all of the code currently in SciPy is "journal" quality (I look no 
> further than many of my own contributions...)
>   
I like the peer-review idea for contributing code. I am kind of new in 
the academic research environment (just started my PhD a few months 
ago), so I am not very familiar with some of the constraints of a 
journal (that is quality requirement, expectation on the scientific 
level, etc...). Reading other responses to this email, I will take a 
look at mentioned publications.

So as much as I am not 'experienced enough' on the whole academic 
publication thing, I like it.
> 1) Do you like the idea ?
>   
+1
> 2) Could you help (i.e. as an editor, reviewer, etc.)? 
>   
+1 if I can help (What would be the requirements to be a reviewer, etc... ?)

David


From guyer at nist.gov  Sat Sep 30 10:21:13 2006
From: guyer at nist.gov (Jonathan Guyer)
Date: Sat, 30 Sep 2006 10:21:13 -0400
Subject: [SciPy-dev] Online SciPy Journal
In-Reply-To: <e86a5fd00609300042j39086cc8r88fe6472df0844bd@mail.gmail.com>
References: <451DBA2D.3070104@ee.byu.edu>
	<e86a5fd00609300042j39086cc8r88fe6472df0844bd@mail.gmail.com>
Message-ID: <E31EB165-282D-495C-8275-EE4744B5BBB3@nist.gov>


On Sep 30, 2006, at 3:42 AM, Bill Baxter wrote:

> Novelty is always one of the main criteria for
> reviewing anywhere I've sent papers.  So something like "implementing
> an FFT module for SciPy" wouldn't go over well with any of the venues
> I'm familiar with.  "There's nothing novel about the FFT" would be the
> rejection.

Which is a shame, because I've encountered several instances lately  
of "nothing novel algorithms" that don't work as published. When you  
finally dig up somebody's code that "works", you discover that  
there's some little hack needed, or just some branch of the algorithm  
that they forgot to publish. This isn't unique to computational  
science, of course; the experimental world is full of results that  
can only be obtained by their "discoverers" (code fusion, anybody?);  
but I think it's particular inexcusable in the computational realm,  
since it's entirely feasible to hand your entire "experimental  
apparatus" to anybody that wants it.

I think it would be a wonderful thing for the reproducibility of  
scientific results if authors were required to publish their code and  
their data instead of just a description of their code and plots of  
their data.

Nonetheless, I understand there needs to be some sort of distinction  
between "yet another implementation of a very well understood and  
accepted algorithm" (FFT is arguably in this category) and "here's a  
way to do something novel along with how I actually did it". Taking a  
bunch of accepted algorithms and putting them together in a way that  
they can talk to each other and are reliable and the whole thing  
makes sense *should* be interesting to the scientific community.


From steve at shrogers.com  Sat Sep 30 11:04:54 2006
From: steve at shrogers.com (Steven H. Rogers)
Date: Sat, 30 Sep 2006 09:04:54 -0600
Subject: [SciPy-dev] Online SciPy Journal
In-Reply-To: <451DBA2D.3070104@ee.byu.edu>
References: <451DBA2D.3070104@ee.byu.edu>
Message-ID: <451E8796.1080102@shrogers.com>



Travis Oliphant wrote:
> ...
> 
> Besides your comments, I would like a response on at least two 
> questions:  +1, -1, +0, -0  voting.
> 
> 
> 1) Do you like the idea ?
+1
> 
> 2) Could you help (i.e. as an editor, reviewer, etc.)? 
+1
> 


-- 
Steven H. Rogers, Ph.D., steve at shrogers.com
Weblog: http://shrogers.com/weblog
"He who refuses to do arithmetic is doomed to talk nonsense."
-- John McCarthy



From jonas at mwl.mit.edu  Sat Sep 30 11:52:01 2006
From: jonas at mwl.mit.edu (Eric Jonas)
Date: Sat, 30 Sep 2006 11:52:01 -0400
Subject: [SciPy-dev] Online SciPy Journal
In-Reply-To: <451DBA2D.3070104@ee.byu.edu>
References: <451DBA2D.3070104@ee.byu.edu>
Message-ID: <1159631522.9806.11.camel@convolution.mit.edu>

> Besides your comments, I would like a response on at least two 
> questions:  +1, -1, +0, -0  voting.
> 
> 
> 1) Do you like the idea ?
> 
+1 

> 2) Could you help (i.e. as an editor, reviewer, etc.)? 
> 
+1 

Those of you in the C++ community might be familiar with boost
(www.boost.org) a peer-reviewed set of STL-like libraries that has
gained a great following in the C++ community. A large part of their
review process is focused on the API -- is it STL-like, does it make
sense, will it grow, etc. A lot of scipy areas are loose wrappers around
existing fortran code, and so have APIs that are somewhat un-pythoninc.
It would be nice if part of the review process for libraries /
publications could involve API feedback as well. 
	...Eric




From robert.kern at gmail.com  Sat Sep 30 15:37:20 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Sat, 30 Sep 2006 14:37:20 -0500
Subject: [SciPy-dev] Intro / Docstrings
In-Reply-To: <20060930074234.GB1607@mentat.za.net>
References: <903323ff0609292054v3d5457d5w16cabd5dad25615@mail.gmail.com>	<451DF050.7050307@gmail.com>
	<20060930074234.GB1607@mentat.za.net>
Message-ID: <451EC770.8090606@gmail.com>

Stefan van der Walt wrote:
> Hi Robert
> 
> On Fri, Sep 29, 2006 at 11:19:28PM -0500, Robert Kern wrote:
>> This is a good way to start. If you want to start with actual code, we still 
>> have quite a ways to go with the "Statistics Review" that I started too long ago.
>>
>>    http://projects.scipy.org/scipy/scipy/wiki/StatisticsReview
>>
>> There are plenty of bite-sized things to do in cleaning up
>> scipy.stats .
> 
> I've been tempted to help with this, but I'm not sure I understand
> what "review" means exactly.  When is a function sufficiently
> "reviewed" to close the ticket?  Must it conform to new style numpy,
> must it be functionally accurate, functionally complete, or all of the
> above?

There is a checklist on that page that details the requirements for a function 
passing review.

-- 
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


From robert.kern at gmail.com  Sat Sep 30 16:34:46 2006
From: robert.kern at gmail.com (Robert Kern)
Date: Sat, 30 Sep 2006 15:34:46 -0500
Subject: [SciPy-dev] Online SciPy Journal
In-Reply-To: <1159631522.9806.11.camel@convolution.mit.edu>
References: <451DBA2D.3070104@ee.byu.edu>
	<1159631522.9806.11.camel@convolution.mit.edu>
Message-ID: <451ED4E6.90301@gmail.com>

Eric Jonas wrote:

> Those of you in the C++ community might be familiar with boost
> (www.boost.org) a peer-reviewed set of STL-like libraries that has
> gained a great following in the C++ community. A large part of their
> review process is focused on the API -- is it STL-like, does it make
> sense, will it grow, etc. A lot of scipy areas are loose wrappers around
> existing fortran code, and so have APIs that are somewhat un-pythoninc.
> It would be nice if part of the review process for libraries /
> publications could involve API feedback as well. 

The example that I believe Fernando was referring to is the GAP Council which, 
formally and informally, reviews contributions to the GAP computational group 
theory software.

   http://www-gap.mcs.st-and.ac.uk/Contacts/People/Council/council.html
   http://www-gap.mcs.st-and.ac.uk/Contacts/submit.html

Both of us heard a talk by Steve Linton at the SAGE Days 2006 workshop where he 
talked about this.

-- 
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