From pearu at scipy.org Thu Jun 1 04:46:59 2006 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 1 Jun 2006 03:46:59 -0500 (CDT) Subject: [SciPy-dev] Wrapping band matrices In-Reply-To: References: Message-ID: Hi Arnd, Could you set up a scipy ticket for your request and assign it to me? At the moment I don't have time for testing your wrappers but I'm interested integrating them to scipy/lib/lapack (the plan is to get rid of lapack wrappers from linalg module as other scipy packages might use lapack wrappers as well). Thanks, Pearu On Wed, 31 May 2006, Arnd Baecker wrote: > Hi, > > I would like to contribute f2py generated > wrappers for the LAPACK routines > dgbrfs, dgbtrf, dgbtrs, dsbev, dsbevd, dsbevx > which deal with symmetric band matrices. > > Originally they were developed with Numeric > and the old f2py. > > At this point I have two questions: > > a) before the function signature looked like: > > dsbev - Function signature: > w,z,info = dsbev(ab,[compute_v,lower,ldab,overwrite_ab]) > > but now it is > > dsbev - Function signature: > w,z,info = dsbev(ab,[compute_v,lower,ldab]) > > I.e.: `overwrite_ab` is missing. > > What has to be done to get this again? > > b) What would be the best approach for the integration > into scipy? > > The present status is at > http://www.physik.tu-dresden.de/~baecker/python/band.zip > > The routines work "stand-alone" > python setup.py build > python tests/test_band.py > and (after more clean-up/documentation)_ > might_ be a good example/framework > for others to add further LAPACK routines. > In particular I think it is easier to test new stuff separately > than to directly integrate it into > scipy/Lib/linalg/generic_flapack.pyf > > Would it make sense to add this to the scipy sandbox at some point? > (I would prefer to leave the final integration > into scipy/Lib/linalg/* to a real expert...) > > In any case, before this, the next steps are: > - do the sbev stuff for all routines > in generic_band.pyf > - address FIXMEs in generic_band.pyf > - add unit tests for all routines > (only one example is given at the moment) > > Many thanks, > > Arnd > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > From arnd.baecker at web.de Thu Jun 1 05:05:45 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 1 Jun 2006 11:05:45 +0200 (CEST) Subject: [SciPy-dev] Wrapping band matrices In-Reply-To: References: Message-ID: Hi Pearu, On Thu, 1 Jun 2006, Pearu Peterson wrote: > > Hi Arnd, > Could you set up a scipy ticket for your request and assign it to me? ok, I will. > At the moment I don't have time for testing your wrappers That's fine - actually, before you really start looking into them, it would be better that we do some of the things in the TODO file before ( stuff and add some more unit tests) - I will let you know when we managed to do that. At this point it would be great if could give me a pointer why I don't have the `overwrite_ab` option anymore - does one have to change the wrapper somehow? Many thanks, Arnd > but I'm > interested integrating them to scipy/lib/lapack (the plan is to get rid > of lapack wrappers from linalg module as other scipy packages might use > lapack wrappers as well). > Thanks, > Pearu > > On Wed, 31 May 2006, Arnd Baecker wrote: > > > Hi, > > > > I would like to contribute f2py generated > > wrappers for the LAPACK routines > > dgbrfs, dgbtrf, dgbtrs, dsbev, dsbevd, dsbevx > > which deal with symmetric band matrices. > > > > Originally they were developed with Numeric > > and the old f2py. > > > > At this point I have two questions: > > > > a) before the function signature looked like: > > > > dsbev - Function signature: > > w,z,info = dsbev(ab,[compute_v,lower,ldab,overwrite_ab]) > > > > but now it is > > > > dsbev - Function signature: > > w,z,info = dsbev(ab,[compute_v,lower,ldab]) > > > > I.e.: `overwrite_ab` is missing. > > > > What has to be done to get this again? > > > > b) What would be the best approach for the integration > > into scipy? > > > > The present status is at > > http://www.physik.tu-dresden.de/~baecker/python/band.zip > > > > The routines work "stand-alone" > > python setup.py build > > python tests/test_band.py > > and (after more clean-up/documentation)_ > > might_ be a good example/framework > > for others to add further LAPACK routines. > > In particular I think it is easier to test new stuff separately > > than to directly integrate it into > > scipy/Lib/linalg/generic_flapack.pyf > > > > Would it make sense to add this to the scipy sandbox at some point? > > (I would prefer to leave the final integration > > into scipy/Lib/linalg/* to a real expert...) > > > > In any case, before this, the next steps are: > > - do the sbev stuff for all routines > > in generic_band.pyf > > - address FIXMEs in generic_band.pyf > > - add unit tests for all routines > > (only one example is given at the moment) > > > > Many thanks, > > > > Arnd > > > > _______________________________________________ > > Scipy-dev mailing list > > Scipy-dev at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-dev > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > > From pearu at scipy.org Thu Jun 1 05:32:40 2006 From: pearu at scipy.org (Pearu Peterson) Date: Thu, 1 Jun 2006 04:32:40 -0500 (CDT) Subject: [SciPy-dev] Wrapping band matrices In-Reply-To: References: Message-ID: On Thu, 1 Jun 2006, Arnd Baecker wrote: > At this point it would be great if could give me a pointer why > I don't have the `overwrite_ab` option anymore - does one have to > change the wrapper somehow? Adding overwrite to ab intent list will give the overwrite_ab option. HTH, Pearu From arnd.baecker at web.de Thu Jun 1 11:05:30 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 1 Jun 2006 17:05:30 +0200 (CEST) Subject: [SciPy-dev] Wrapping band matrices In-Reply-To: References: Message-ID: On Thu, 1 Jun 2006, Pearu Peterson wrote: > > > On Thu, 1 Jun 2006, Arnd Baecker wrote: > > > At this point it would be great if could give me a pointer why > > I don't have the `overwrite_ab` option anymore - does one have to > > change the wrapper somehow? > > Adding overwrite to ab intent list will give the overwrite_ab option. > > HTH, Yes - perfect - many thanks! Just one more question - I tried to use -DF2PY_REPORT_ON_ARRAY_COPY=1 -DF2PY_REPORT_ATEXIT for testing purposes by the following construct (in various variants) in setup.py: f2py_options = [] f2py_options.append("-c -DF2PY_REPORT_ON_ARRAY_COPY=1 -DF2PY_REPORT_ATEXIT") config.add_extension('band', sources = [generate_pyf], depends = ['generic_band.pyf', 'interface_gen.py'], extra_info = lapack_opt, f2py_options = f2py_options ) However, I get f2py options: ['-c -DF2PY_REPORT_ON_ARRAY_COPY=1 -DF2PY_REPORT_ATEXIT'] f2py: build/src/band/band.pyf Unknown option '-c -DF2PY_REPORT_ON_ARRAY_COPY=1 -DF2PY_REPORT_ATEXIT' I also tried python setup.py build_src --f2pyflags="-DF2PY_REPORT_ON_ARRAY_COPY=1 -DF2PY_REPORT_ATEXIT" giving Unknown option '-DF2PY_REPORT_ON_ARRAY_COPY=1' As you can see, I am clearly lost, any pointers are appreciated! (the above attempts were after reading http://www.ifi.uio.no/in228/scripting/doc/python/fc/f2py.html#scipy-distutils-0-2-2-and-up but obviously I did not get the right magic words ...) Many thanks, Arnd From nwagner at iam.uni-stuttgart.de Fri Jun 2 05:06:33 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 02 Jun 2006 11:06:33 +0200 Subject: [SciPy-dev] A persistent failure with latest svn Message-ID: <447FFF99.9080500@iam.uni-stuttgart.de> ====================================================================== FAIL: check_variation (scipy.stats.tests.test_stats.test_moments) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/stats/tests/test_stats.py", line 801, in check_variation assert_approx_equal(y,0.44721359549996, 10) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 184, in assert_approx_equal assert math.fabs(sc_desired - sc_actual) < pow(10.,-1*significant), msg AssertionError: Items are not equal to 10 significant digits: DESIRED: 0.44721359549995998 ACTUAL: 0.3872983346207417 ---------------------------------------------------------------------- Ran 1518 tests in 7.017s FAILED (failures=1) From bhendrix at enthought.com Tue Jun 6 14:43:37 2006 From: bhendrix at enthought.com (Bryce Hendrix) Date: Tue, 06 Jun 2006 13:43:37 -0500 Subject: [SciPy-dev] ANN: Python Enthought Edition Version 0.9.7 Released Message-ID: <4485CCD9.7050907@enthought.com> Enthought is pleased to announce the release of Python Enthought Edition Version 0.9.7 (http://code.enthought.com/enthon/) -- a python distribution for Windows. 0.9.7 Release Notes: -------------------- Version 0.9.7 of Python Enthought Edition includes an update to version 1.0.7 of the Enthought Tool Suite (ETS) Package and bug fixes-- you can look at the release notes for this ETS version here: http://svn.enthought.com/downloads/enthought/changelog-release.1.0.7.html About Python Enthought Edition: ------------------------------- Python 2.3.5, Enthought Edition is a kitchen-sink-included Python distribution for Windows including the following packages out of the box: Numeric SciPy IPython Enthought Tool Suite wxPython PIL mingw f2py MayaVi Scientific Python VTK and many more... More information is available about all Open Source code written and released by Enthought, Inc. at http://code.enthought.com From bhendrix at enthought.com Tue Jun 6 14:43:37 2006 From: bhendrix at enthought.com (Bryce Hendrix) Date: Tue, 06 Jun 2006 13:43:37 -0500 Subject: [SciPy-dev] ANN: Python Enthought Edition Version 0.9.7 Released Message-ID: Enthought is pleased to announce the release of Python Enthought Edition Version 0.9.7 (http://code.enthought.com/enthon/) -- a python distribution for Windows. 0.9.7 Release Notes: -------------------- Version 0.9.7 of Python Enthought Edition includes an update to version 1.0.7 of the Enthought Tool Suite (ETS) Package and bug fixes-- you can look at the release notes for this ETS version here: http://svn.enthought.com/downloads/enthought/changelog-release.1.0.7.html About Python Enthought Edition: ------------------------------- Python 2.3.5, Enthought Edition is a kitchen-sink-included Python distribution for Windows including the following packages out of the box: Numeric SciPy IPython Enthought Tool Suite wxPython PIL mingw f2py MayaVi Scientific Python VTK and many more... More information is available about all Open Source code written and released by Enthought, Inc. at http://code.enthought.com From arnd.baecker at web.de Thu Jun 8 04:39:09 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 8 Jun 2006 10:39:09 +0200 (CEST) Subject: [SciPy-dev] test_lstsq failure Message-ID: Hi, on a 64 Bit opteron I get with current svn: ====================================================================== FAIL: check_random_complex_overdet (scipy.linalg.tests.test_basic.test_lstsq) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/scipy/linalg/tests/test_basic.py", line 413, in check_random_complex_overdet assert_array_almost_equal(x,direct_lstsq(a,b),3) File "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/testing/utils.py", line 233, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 77.7777777778%): Array 1: [[-0.0137+0.0173j 0.0037-0.0173j -0.0114+0.0119j] [ 0.0029-0.0356j 0.0086-0.034j 0.033 -0.0879j] [ 0.0041-0.0097j ... Array 2: [[-0.016 +0.0162j 0.003 -0.0171j -0.0148+0.009j ] [-0.0017-0.0405j 0.003 -0.036j 0.0256-0.0977j] [ 0.0038-0.0112j ... Best, Arnd From nwagner at iam.uni-stuttgart.de Thu Jun 8 04:42:48 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Thu, 08 Jun 2006 10:42:48 +0200 Subject: [SciPy-dev] test_lstsq failure In-Reply-To: References: Message-ID: <4487E308.8080609@iam.uni-stuttgart.de> Arnd Baecker wrote: > Hi, > > on a 64 Bit opteron I get with current svn: > > ====================================================================== > FAIL: check_random_complex_overdet > (scipy.linalg.tests.test_basic.test_lstsq) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/scipy/linalg/tests/test_basic.py", > line 413, in check_random_complex_overdet > assert_array_almost_equal(x,direct_lstsq(a,b),3) > File > "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/testing/utils.py", > line 233, in assert_array_almost_equal > assert cond,\ > AssertionError: > Arrays are not almost equal (mismatch 77.7777777778%): > Array 1: [[-0.0137+0.0173j 0.0037-0.0173j -0.0114+0.0119j] > [ 0.0029-0.0356j 0.0086-0.034j 0.033 -0.0879j] > [ 0.0041-0.0097j ... > Array 2: [[-0.016 +0.0162j 0.003 -0.0171j -0.0148+0.009j ] > [-0.0017-0.0405j 0.003 -0.036j 0.0256-0.0977j] > [ 0.0038-0.0112j ... > > Best, Arnd > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > r1934 | cookedm | 2006-06-08 05:12:30 +0200 (Thu, 08 Jun 2006) | 4 lines Fix scipy.linalg.tests.test_basic.test_lstsq.check_random_complex_overdet to use # of decimals, not a tolerance, as argument to assert_array_almost_equal. This exposes the bug again. From arnd.baecker at web.de Thu Jun 8 04:53:14 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 8 Jun 2006 10:53:14 +0200 (CEST) Subject: [SciPy-dev] test_lstsq failure In-Reply-To: <4487E308.8080609@iam.uni-stuttgart.de> References: <4487E308.8080609@iam.uni-stuttgart.de> Message-ID: On Thu, 8 Jun 2006, Nils Wagner wrote: > Arnd Baecker wrote: > > Hi, > > > > on a 64 Bit opteron I get with current svn: > > > > ====================================================================== > > FAIL: check_random_complex_overdet > > (scipy.linalg.tests.test_basic.test_lstsq) > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File > > "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/scipy/linalg/tests/test_basic.py", > > line 413, in check_random_complex_overdet > > assert_array_almost_equal(x,direct_lstsq(a,b),3) > > File > > "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/testing/utils.py", > > line 233, in assert_array_almost_equal > > assert cond,\ > > AssertionError: > > Arrays are not almost equal (mismatch 77.7777777778%): > > Array 1: [[-0.0137+0.0173j 0.0037-0.0173j -0.0114+0.0119j] > > [ 0.0029-0.0356j 0.0086-0.034j 0.033 -0.0879j] > > [ 0.0041-0.0097j ... > > Array 2: [[-0.016 +0.0162j 0.003 -0.0171j -0.0148+0.009j ] > > [-0.0017-0.0405j 0.003 -0.036j 0.0256-0.0977j] > > [ 0.0038-0.0112j ... > > > > Best, Arnd > > > > _______________________________________________ > > Scipy-dev mailing list > > Scipy-dev at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-dev > > > r1934 | cookedm | 2006-06-08 05:12:30 +0200 (Thu, 08 Jun 2006) | 4 lines > > Fix scipy.linalg.tests.test_basic.test_lstsq.check_random_complex_overdet > to use # of decimals, not a tolerance, as argument to > assert_array_almost_equal. > This exposes the bug again. does "the bug" refer to the error above? If so, then David knows about it and it is in good hands ;-) (BTW the time-stamp above is different from the one at http://projects.scipy.org/scipy/scipy/changeset/1934) Arnd From cookedm at physics.mcmaster.ca Thu Jun 8 10:44:19 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Thu, 8 Jun 2006 10:44:19 -0400 Subject: [SciPy-dev] test_lstsq failure In-Reply-To: References: <4487E308.8080609@iam.uni-stuttgart.de> Message-ID: <20060608144419.GA29985@arbutus.physics.mcmaster.ca> On Thu, Jun 08, 2006 at 10:53:14AM +0200, Arnd Baecker wrote: > On Thu, 8 Jun 2006, Nils Wagner wrote: > > > Arnd Baecker wrote: > > > Hi, > > > > > > on a 64 Bit opteron I get with current svn: > > > > > > ====================================================================== > > > FAIL: check_random_complex_overdet > > > (scipy.linalg.tests.test_basic.test_lstsq) > > > ---------------------------------------------------------------------- > > > Traceback (most recent call last): > > > File > > > "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/scipy/linalg/tests/test_basic.py", > > > line 413, in check_random_complex_overdet > > > assert_array_almost_equal(x,direct_lstsq(a,b),3) > > > File > > > "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/testing/utils.py", > > > line 233, in assert_array_almost_equal > > > assert cond,\ > > > AssertionError: > > > Arrays are not almost equal (mismatch 77.7777777778%): > > > Array 1: [[-0.0137+0.0173j 0.0037-0.0173j -0.0114+0.0119j] > > > [ 0.0029-0.0356j 0.0086-0.034j 0.033 -0.0879j] > > > [ 0.0041-0.0097j ... > > > Array 2: [[-0.016 +0.0162j 0.003 -0.0171j -0.0148+0.009j ] > > > [-0.0017-0.0405j 0.003 -0.036j 0.0256-0.0977j] > > > [ 0.0038-0.0112j ... > > > > > > Best, Arnd > > > > > > _______________________________________________ > > > Scipy-dev mailing list > > > Scipy-dev at scipy.net > > > http://www.scipy.net/mailman/listinfo/scipy-dev > > > > > r1934 | cookedm | 2006-06-08 05:12:30 +0200 (Thu, 08 Jun 2006) | 4 lines > > > > Fix scipy.linalg.tests.test_basic.test_lstsq.check_random_complex_overdet > > to use # of decimals, not a tolerance, as argument to > > assert_array_almost_equal. > > This exposes the bug again. > > does "the bug" refer to the error above? > > If so, then David knows about it and it is in good hands ;-) > (BTW the time-stamp above is different from the one at > http://projects.scipy.org/scipy/scipy/changeset/1934) Well, I don't know what's wrong with it: I was tracking down a DeprecationWarning, and it looks like the test case added above was done incorrectly in such a way that it was masking the error (it was rounding everything to 0 decimal digits :-) btw, the time stamp is right once you correct for the time zone: I'm currently in -0400, but Trac is showing times in -0500. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From a.u.r.e.l.i.a.n at gmx.net Fri Jun 9 06:07:23 2006 From: a.u.r.e.l.i.a.n at gmx.net (Johannes Loehnert) Date: Fri, 9 Jun 2006 12:07:23 +0200 Subject: [SciPy-dev] Docstring of eigh Message-ID: <200606091207.23299.a.u.r.e.l.i.a.n@gmx.net> Hi, in the docstring of eigh (Lib/linalg/decomp.py, around line 180): """ [...] Outputs: w,v -- w: eigenvalues, v: eigenvectors [for eigvals_only == False] w -- eigenvalues [for eigvals_only == True (default)]. [...] """ but the default is eigvals_only == False. cu, Johannes From arnd.baecker at web.de Fri Jun 9 06:36:21 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 9 Jun 2006 12:36:21 +0200 (CEST) Subject: [SciPy-dev] weave Message-ID: Hi, for some reason one of our code, which should have been fully converted to numpy, lead to the inclusion of Numeric in sys.modules. We tracked this down to the following minimal example from weave import inline import sys print sys.modules["Numeric"] In the end this is caused by scipy/weave/accelerate_tools.py which does an import weave at the beginning. When both new scipy and old scipy (at a different place) are installed, the above line fetches the weave from old scipy and therefore a bunch of Numeric stuff. It seems that a from scipy.weave import weave in scipy/weave/accelerate_tools.py fixes the problem. I could commit the change, but before that I would like to make sure that I am not messing up anything with the above change. Any comments? Best, Arnd P.S.: In case you wonder why a non-existing weave does not not lead an error: the reason is that in scipy/weave/__init__.py the construct try: from accelerate_tools import accelerate except: pass is used. From jstrunk at enthought.com Mon Jun 12 10:58:14 2006 From: jstrunk at enthought.com (Jeff Strunk) Date: Mon, 12 Jun 2006 09:58:14 -0500 Subject: [SciPy-dev] Mailing list is back Message-ID: <200606120958.14794.jstrunk@enthought.com> Good morning, On Friday, the /home partition on old.scipy.org(this still handles mail.) filled up. Since that is where Mailman was storing messages, some messages sent over the weekend may need to be resent. Sorry for the inconvenience, Jeff Strunk IT Administrator Enthought Inc. From a.u.r.e.l.i.a.n at gmx.net Mon Jun 12 11:01:31 2006 From: a.u.r.e.l.i.a.n at gmx.net (Johannes Loehnert) Date: Mon, 12 Jun 2006 17:01:31 +0200 Subject: [SciPy-dev] Handling of float96 and complex192 in linalg Message-ID: <200606121701.31894.a.u.r.e.l.i.a.n@gmx.net> Hi, I was looking through the code of the linalg module last week. I noticed that several of the functions use ``get_lapack_funcs`` from ``Lib/linalg/lapack.py`` in order to find the appropriate lapack routine for a given data type. However, ``get_lapack_funcs`` fails on arrays with dtype.char=='g' (float96) and dtype.char=='G' (complex 2*96). In both cases the double precision routine is given back. (I know there are no float96/complex192 routines in lapack). While this somewhat acceptable for float96 (precision suffers), it is not very nice if complex192 is silently cast to float64 by simply throwing the imaginary part away. (See below for a "fatal" example.) The "lazy" solution would be to let get_lapack_funcs raise an error for 'g' and 'G' typechar. Alternatively, complex192 could be treated by double precision complex routines ('z' prefix). For this approach, some kind of warning would be nice if float96 or complex192 arrays are cast to a lower precision. Johannes Loehnert Example: In [1]: from numpy import * In [2]: re = rand(10,10) In [3]: im = rand(10,10) In [4]: x = (re + 1j*im).astype('G') # create random complex192 matrix In [5]: from scipy.linalg import eig In [6]: e1, dummy = eig(x) # x is cast to float64, yielding wrong eigenvalues In [7]: e2, dummy = eig(x.astype('D')) # cast to complex128 -> correct values In [8]: print e1 [ 4.99532769+0.j 1.33254924+0.j -0.08283794+0.76930589j -0.08283794-0.76930589j -0.47488469+0.24342446j -0.47488469-0.24342446j 0.33556027+0.15301716j 0.33556027-0.15301716j -0.02890708+0.31652241j -0.02890708-0.31652241j] In [9]: print e2 [ 5.02636564+5.37963067j 1.50114472-0.01585185j 0.60033384-1.06642284j -0.46327973-0.84463702j -0.62357122-0.20919303j -0.65416101+0.66355244j -0.47412464+0.7726915j 0.37856415+0.8177398j 0.15827675-0.07332642j 0.37618956+0.34544957j] From david.huard at gmail.com Mon Jun 12 17:12:07 2006 From: david.huard at gmail.com (David Huard) Date: Mon, 12 Jun 2006 17:12:07 -0400 Subject: [SciPy-dev] Status of interpolate.interp2d Message-ID: <91cf711d0606121412m7e6d8cc6g7f2f04e7b8e9060d@mail.gmail.com> Hi, Line 41 in interpolate.py should read if rank(self.x) > 2 or rank(self.y) > 2: instead of if self.x > 2 or rank(self.y) > 2: When this is fixed and I call it to evaluate z at some point x,y, it complains that it has no attribute tck. In fact, it seems that the spline is not evaluated during __init__. Should I understand that interp2d is getting a rehaul and is currently broken ? If so, I'd like to help since I need it. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From cookedm at physics.mcmaster.ca Mon Jun 12 17:20:03 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Mon, 12 Jun 2006 17:20:03 -0400 Subject: [SciPy-dev] Docstring of eigh In-Reply-To: <200606091207.23299.a.u.r.e.l.i.a.n@gmx.net> References: <200606091207.23299.a.u.r.e.l.i.a.n@gmx.net> Message-ID: <20060612172003.1e4cf78b@arbutus.physics.mcmaster.ca> On Fri, 9 Jun 2006 12:07:23 +0200 Johannes Loehnert wrote: > Hi, > > in the docstring of eigh (Lib/linalg/decomp.py, around line 180): > """ > [...] > Outputs: > > w,v -- w: eigenvalues, v: eigenvectors [for eigvals_only == False] > w -- eigenvalues [for eigvals_only == True (default)]. > [...] > """ > > but the default is eigvals_only == False. > > cu, Johannes Fixed in svn. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From cookedm at physics.mcmaster.ca Mon Jun 12 17:22:09 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Mon, 12 Jun 2006 17:22:09 -0400 Subject: [SciPy-dev] weave In-Reply-To: References: Message-ID: <20060612172209.228696e2@arbutus.physics.mcmaster.ca> On Fri, 9 Jun 2006 12:36:21 +0200 (CEST) Arnd Baecker wrote: > Hi, > > for some reason one of our code, which should have > been fully converted to numpy, lead to the inclusion of Numeric > in sys.modules. > > We tracked this down to the following minimal example > from weave import inline > import sys > print sys.modules["Numeric"] > > In the end this is caused by > scipy/weave/accelerate_tools.py > which does an > import weave > at the beginning. > When both new scipy and old scipy (at a different place) > are installed, the above line fetches the weave from old > scipy and therefore a bunch of Numeric stuff. > It seems that a > from scipy.weave import weave > in scipy/weave/accelerate_tools.py > fixes the problem. > > I could commit the change, but before that I would like > to make sure that I am not messing up anything with the above change. Go for it. (Relative imports like this are a pain) -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From cookedm at physics.mcmaster.ca Mon Jun 12 17:37:53 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Mon, 12 Jun 2006 17:37:53 -0400 Subject: [SciPy-dev] Status of interpolate.interp2d In-Reply-To: <91cf711d0606121412m7e6d8cc6g7f2f04e7b8e9060d@mail.gmail.com> References: <91cf711d0606121412m7e6d8cc6g7f2f04e7b8e9060d@mail.gmail.com> Message-ID: <20060612173753.46ef3e42@arbutus.physics.mcmaster.ca> On Mon, 12 Jun 2006 17:12:07 -0400 "David Huard" wrote: > Hi, > Line 41 in interpolate.py should read > > if rank(self.x) > 2 or rank(self.y) > 2: > > instead of > if self.x > 2 or rank(self.y) > 2: > > When this is fixed and I call it to evaluate z at some point x,y, it > complains that it has no attribute tck. In fact, it seems that the spline is > not evaluated during __init__. Should I understand that interp2d is getting > a rehaul and is currently broken ? If so, I'd like to help since I need it. Looks like interp2d was broken. I fiddled with it until calls to stuff matched the docstrings of other stuff (yes, I don't really know how to use it :-). From the log, Travis touched it at the end of May, so he may have broken it. There's no test case for it, so that's quite possible. So it may work now. If it does, send us a test case, then we can make sure it doesn't break again :D -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From cookedm at physics.mcmaster.ca Mon Jun 12 18:16:13 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Mon, 12 Jun 2006 18:16:13 -0400 Subject: [SciPy-dev] Handling of float96 and complex192 in linalg In-Reply-To: <200606121701.31894.a.u.r.e.l.i.a.n@gmx.net> References: <200606121701.31894.a.u.r.e.l.i.a.n@gmx.net> Message-ID: <20060612181613.1fe698c5@arbutus.physics.mcmaster.ca> On Mon, 12 Jun 2006 17:01:31 +0200 Johannes Loehnert wrote: > Hi, > > I was looking through the code of the linalg module last week. I noticed > that several of the functions use ``get_lapack_funcs`` from > ``Lib/linalg/lapack.py`` in order to find the appropriate lapack routine > for a given data type. > > However, ``get_lapack_funcs`` fails on arrays with > dtype.char=='g' (float96) and dtype.char=='G' (complex 2*96). In both cases > the double precision routine is given back. (I know there are no > float96/complex192 routines in lapack). > > While this somewhat acceptable for float96 (precision suffers), it is not > very nice if complex192 is silently cast to float64 by simply throwing the > imaginary part away. (See below for a "fatal" example.) > > The "lazy" solution would be to let get_lapack_funcs raise an error for 'g' > and 'G' typechar. > > Alternatively, complex192 could be treated by double precision complex > routines ('z' prefix). For this approach, some kind of warning would be > nice if float96 or complex192 arrays are cast to a lower precision. I've implemented downcasting of longdouble to double ('d' prefix) and clongdouble to cdouble ('z' prefix), and rewritten get_lapack_funcs to use dtype instead of typecodes. No warning, though. [I'd urge you to use longdouble/clongdouble instead of float96/complex192: the later aren't portable. On the Mac, you get float128 and complex256 as longdouble and clongdouble instead, for instance, and there is no float96/complex192.] -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From nwagner at iam.uni-stuttgart.de Tue Jun 13 09:18:56 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Tue, 13 Jun 2006 15:18:56 +0200 Subject: [SciPy-dev] Sporadic failure using scipy.test(1,10) several times Message-ID: <448EBB40.9030808@iam.uni-stuttgart.de> If I run scipy.test(1,10) several times I get a second failure (besides the persistent one FAIL: check_random_complex_overdet (scipy.linalg.tests.test_basic.test_lstsq) ====================================================================== FAIL: check_y_stride_transpose (scipy.lib.blas.tests.test_fblas.test_cgemv) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/scipy/lib/blas/tests/test_fblas.py", line 373, in check_y_stride_transpose assert_array_almost_equal(desired_y,y) File "/usr/lib64/python2.4/site-packages/numpy/testing/utils.py", line 233, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 16.6666666667%): Array 1: [ 5.9724813 -5.9724813j 1. +1.j -1.0957168 +5.095717j 3. +3.j -9.5781755+17.5781746j 5. ... Array 2: [ 5.9724813 -5.9724813j 1. +1.j -1.0957168 +5.095717j 3. +3.j -9.5781755+17.5781765j 5. ... ---------------------------------------------------------------------- >>> numpy.__version__ '0.9.9.2613' >>> scipy.__version__ '0.5.0.1955' Can someone reproduce this sporadic failure ? Nils From Bernhard.Hoefle at uibk.ac.at Wed Jun 14 06:10:02 2006 From: Bernhard.Hoefle at uibk.ac.at (Bernhard Reimar Hoefle) Date: Wed, 14 Jun 2006 12:10:02 +0200 Subject: [SciPy-dev] Compiling error fftpack In-Reply-To: References: Message-ID: <1150279802.448fe07aa14f4@web-mail2.uibk.ac.at> Hi! I have the following compilers on FC5: gcc-gnat-4.1.1-1.fc5 compat-libgcc-296-2.96-135 compat-gcc-32-g77-3.2.3-55.fc5 gcc-c++-4.1.1-1.fc5 compat-gcc-32-3.2.3-55.fc5 compat-gcc-32-c++-3.2.3-55.fc5 libgcc-4.1.1-1.fc5 gcc-4.1.1-1.fc5 gcc-objc-4.1.1-1.fc5 gcc-gfortran-4.1.1-1.fc5 gcc-java-4.1.1-1.fc5 and these packages: atlas-3.6.0-10.fc5 atlas-devel-3.6.0-10.fc5 lapack-devel-3.0-37.fc5 lapack-3.0-37.fc5 blas-3.0-37.fc5 blas-devel-3.0-37.fc5 I also installed gcc-2.95.3 as it is mentioned on: http://pong.tamu.edu/tiki/tiki-view_blog_post.php?blogId=6&postId=97 I tried to compile scipy-0.4.9 and scipy svn and got the same error message. I get stuck here: ... building extension "scipy.ndimage._nd_image" sources building data_files sources running build_py copying build/src.linux-i686-2.4/scipy/__config__.py -> build/lib.linux-i686-2.4/scipy running build_clib customize UnixCCompiler customize UnixCCompiler using build_clib customize GnuFCompiler customize GnuFCompiler customize GnuFCompiler using build_clib building 'dfftpack' library compiling Fortran sources Fortran f77 compiler: /usr/bin/g77 -g -Wall -fno-second-underscore -fPIC -O2 -funroll-loops -march=i686 -mmmx -msse2 -msse -fomit-frame-pointer -malign-double compile options: '-c' g77:f77: Lib/fftpack/dfftpack/zfftf1.f /tmp/ccQtTXdW.s: Assembler messages: /tmp/ccQtTXdW.s:598: Error: suffix or operands invalid for `movd' /tmp/ccQtTXdW.s:2994: Error: suffix or operands invalid for `movd' /tmp/ccQtTXdW.s: Assembler messages: /tmp/ccQtTXdW.s:598: Error: suffix or operands invalid for `movd' /tmp/ccQtTXdW.s:2994: Error: suffix or operands invalid for `movd' error: Command "/usr/bin/g77 -g -Wall -fno-second-underscore -fPIC -O2 -funroll-loops -march=i686 -mmmx -msse2 -msse -fomit-frame-pointer -malign-double -c -c Lib/fftpack/dfftpack/zfftf1.f -o build/temp.linux-i686-2.4/Lib/fftpack/dfftpack/zfftf1.o" failed with exit status 1 Any ideas? Thanks, Bernhard From david.huard at gmail.com Wed Jun 14 11:57:59 2006 From: david.huard at gmail.com (David Huard) Date: Wed, 14 Jun 2006 11:57:59 -0400 Subject: [SciPy-dev] Status of interpolate.interp2d In-Reply-To: <20060612173753.46ef3e42@arbutus.physics.mcmaster.ca> References: <91cf711d0606121412m7e6d8cc6g7f2f04e7b8e9060d@mail.gmail.com> <20060612173753.46ef3e42@arbutus.physics.mcmaster.ca> Message-ID: <91cf711d0606140857k27b335f0i5f4ae4080d584aca@mail.gmail.com> Hi David, There were (and are) still a couple of problems with interp2d. A patch is attached for the problems I've able to solve. It now works for evaluating the spline at one location, but not for arrays. However, I don't have time to fiddle with it right now. Cheers, David Here is a simple test case that works, with an example of what ought to work in the future. # Example of the use of interp2 from scipy import * x,y = mgrid[0:pi:20j, 0:pi:21j] z = sin(x*y) I = interpolate.interp2d(x,y,z) # Now it should be possible to interpolate anywhere inside the x,y grid. # The answer should be around sin(1) = .84 print I(1.,1.) # This should eventually work (but it still doesn't) #1. I(ravel(x), ravel(y)) #2. I(x,y) 2006/6/12, David M. Cooke : > > On Mon, 12 Jun 2006 17:12:07 -0400 > "David Huard" wrote: > > > Hi, > > Line 41 in interpolate.py should read > > > > if rank(self.x) > 2 or rank(self.y) > 2: > > > > instead of > > if self.x > 2 or rank(self.y) > 2: > > > > When this is fixed and I call it to evaluate z at some point x,y, it > > complains that it has no attribute tck. In fact, it seems that the > spline is > > not evaluated during __init__. Should I understand that interp2d is > getting > > a rehaul and is currently broken ? If so, I'd like to help since I need > it. > > Looks like interp2d was broken. I fiddled with it until calls to stuff > matched the docstrings of other stuff (yes, I don't really know how to use > it :-). > > From the log, Travis touched it at the end of May, so he may have broken > it. > There's no test case for it, so that's quite possible. > > So it may work now. If it does, send us a test case, then we can make sure > it > doesn't break again :D > > -- > |>|\/|< > > /--------------------------------------------------------------------------\ > |David M. Cooke > http://arbutus.physics.mcmaster.ca/dmc/ > |cookedm at physics.mcmaster.ca > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: interpolate.patch Type: text/x-patch Size: 753 bytes Desc: not available URL: From arnd.baecker at web.de Fri Jun 16 06:03:54 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 16 Jun 2006 12:03:54 +0200 (CEST) Subject: [SciPy-dev] band matrix wrapping ready for inclusion Message-ID: Hi, thanks to Johannes Loehnert and Waltraut Wustmann the previous f2py wrappers have been supplied with many more unit-tests, documentation and wrappers for hermitian band matrices. The wrappers deals with: sbev sbevd sbevx hbevd hbevx gbtrf gbtrs lamch In addition front-end routines `eig_banded`, `eigvals_banded` for inclusion in Lib/linalg/decomp.py are provided. The current version is at http://www.physik.tu-dresden.de/~baecker/python/band.zip Pearu, it would be nice if you could have a look at the wrappers and let us know whether anything needs to be done/improved. If you prefer I can do a commit (after following the steps in the TODO), but I would like to get your ok first (I also don't mind if you prefer to make the corresponding changes ;-). Hope the result is useful not just for us but also to others. In addition, the contents of band.zip might be helpful as an example on how to provide wrappers for other LAPACK routines. Best, Arnd P.S.: In the long run one could also think of adding code for performing inverse iteration, but this might also fit into the sparse matrix department. From nwagner at iam.uni-stuttgart.de Fri Jun 16 09:39:39 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 16 Jun 2006 15:39:39 +0200 Subject: [SciPy-dev] abs return the absolute value of the argument (and this should be real) Message-ID: <4492B49B.3020803@iam.uni-stuttgart.de> >>> a=rand(3,3) >>> w=linalg.eigvals(a) >>> w array([ 1.28249999+0.j, -0.29921706+0.j, 0.01819573+0.j]) >>> abs(w) array([ 1.28249999, 0.29921706, 0.01819573]) >>> abs(w[0]) (1.2824999903657521+0j) abs return the absolute value of the argument and this should be real. BTW, I am using >>> numpy.__version__ '0.9.9.2628' >>> scipy.__version__ '0.5.0.1977' From nmarais at sun.ac.za Fri Jun 16 17:47:11 2006 From: nmarais at sun.ac.za (Neilen Marais) Date: Fri, 16 Jun 2006 23:47:11 +0200 Subject: [SciPy-dev] Email subsription to Trac tickets? Message-ID: <1150494431.5814.66.camel@localhost.localdomain> Hi! I've registered on the numpy and scipy Trac instances so I can log tickets, but it did not seem to ask for my email address. Is there some way I can subscribe to track tickets via email? Thanks Neilen From robert.kern at gmail.com Fri Jun 16 17:57:37 2006 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 16 Jun 2006 16:57:37 -0500 Subject: [SciPy-dev] Email subsription to Trac tickets? In-Reply-To: <1150494431.5814.66.camel@localhost.localdomain> References: <1150494431.5814.66.camel@localhost.localdomain> Message-ID: <44932951.8050708@gmail.com> Neilen Marais wrote: > Hi! > > I've registered on the numpy and scipy Trac instances so I can log > tickets, but it did not seem to ask for my email address. Is there some > way I can subscribe to track tickets via email? We're fiddling with the email notification at the moment. You can add your email address to your account by clicking on "Settings" at the top of the page. Then you ought to be receiving ticket emails by adding your username to the Cc: field of the ticket. You can use this ticket to test, if you like: http://projects.scipy.org/scipy/scipy/ticket/212 We are working on a tickets list and a checkins list for numpy and scipy, but they do not seem to be operational at the moment. -- 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 travis at enthought.com Wed Jun 21 11:20:38 2006 From: travis at enthought.com (Travis N. Vaught) Date: Wed, 21 Jun 2006 10:20:38 -0500 Subject: [SciPy-dev] SciPy 2006 Tutorials Message-ID: <449963C6.3070203@enthought.com> All, As part of this year's SciPy 2006 Conference, we've planned Coding Sprints on Monday and Tuesday (August 14-15) and a Tutorial Day Wednesday (August 16)--the normal conference presentations follow on Thursday and Friday (August 17-18). For this year at least, the Tutorials (and Sprints) are no additional charge (you're on your own for food on those days, though). With regard to Tutorial topics, we've settled on the following: "3D visualization in Python using tvtk and MayaVi" "Scientific Data Analysis and Visualization using IPython and Matplotlib." "Building Scientific Applications using the Enthought Tool Suite (Envisage, Traits, Chaco, etc.)" "NumPy (migration from Numarray & Numeric, overview of NumPy)" These will be in two tracks with two three hour sessions in each track. If you plan to attend, please send an email to tutorials at scipy.org with the two sessions you'd most like to hear and we'll build the schedule with a minimum of conflict. We'll post the schedule of the tracks on the Wiki here: http://www.scipy.org/SciPy2006/TutorialSessions Also, if you haven't registered already, the deadline for early registration is July 14. The abstract submission deadline is July 7. More information is here: http://www.scipy.org/SciPy2006 Thanks, Travis From jstrunk at enthought.com Wed Jun 21 14:29:45 2006 From: jstrunk at enthought.com (Jeff Strunk) Date: Wed, 21 Jun 2006 13:29:45 -0500 Subject: [SciPy-dev] old.scipy.org -> new.scipy.org migration Message-ID: <200606211329.45538.jstrunk@enthought.com> Good afternoon, I need to finish the server migration. Does anybody know what remains to be moved from old.scipy.org to new.scipy.org? I know of the following things: -DNS -smtp,pop,imap -mailman Anything else? Thanks, Jeff Strunk IT Administrator Enthought Inc From stefan at sun.ac.za Thu Jun 22 08:58:29 2006 From: stefan at sun.ac.za (Stefan van der Walt) Date: Thu, 22 Jun 2006 14:58:29 +0200 Subject: [SciPy-dev] default axes for ndimage.rotate Message-ID: <20060622125829.GA12662@mentat.za.net> Hi, Can anyone explain to me why the default 'axes' parameter to ndimage.rotate is (-1,-2)? This works for grey-scale images, but not for colour images (MxNx3). Would there be any objection to changing it to (0,1) or (1,0) instead? St?fan From oliphant.travis at ieee.org Thu Jun 22 14:57:27 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 22 Jun 2006 12:57:27 -0600 Subject: [SciPy-dev] Recent SVN of NumPy has issues with SciPy Message-ID: <449AE817.1020700@ieee.org> There are still some issues with my recent check-in for NumPy (r2663). But, it does build and run the numpy.tests cleanly. (It's failing on SciPy tests...) You may want to hold off for a few hours until I can straighten it out. -Travis From loredo at astro.cornell.edu Thu Jun 22 16:37:40 2006 From: loredo at astro.cornell.edu (Tom Loredo) Date: Thu, 22 Jun 2006 16:37:40 -0400 Subject: [SciPy-dev] Numpy tests crash on FC3, Py-2.4.3 Message-ID: <1151008660.449aff94229a9@astrosun2.astro.cornell.edu> Hi folks, Doing housecleaning today---updating to Py 2.4.3 and the latest numpy/scipy/mpl on a linux (FC3) box. Alas, numpy-0.9.8 tests give a segfault: >>> import numpy >>> numpy.__version__ '0.9.8' >>> numpy.test(1,1) Found 5 tests for numpy.distutils.misc_util Found 3 tests for numpy.lib.getlimits Found 30 tests for numpy.core.numerictypes Found 13 tests for numpy.core.umath Found 1 tests for numpy.core.scalarmath Found 8 tests for numpy.lib.arraysetops Found 42 tests for numpy.lib.type_check Found 95 tests for numpy.core.multiarray Found 3 tests for numpy.dft.helper Found 36 tests for numpy.core.ma Found 9 tests for numpy.lib.twodim_base Found 2 tests for numpy.core.oldnumeric Found 9 tests for numpy.core.defmatrix Found 1 tests for numpy.lib.ufunclike Found 35 tests for numpy.lib.function_base Found 1 tests for numpy.lib.polynomial Found 6 tests for numpy.core.records Found 19 tests for numpy.core.numeric Found 4 tests for numpy.lib.index_tricks Found 46 tests for numpy.lib.shape_base Found 0 tests for __main__ ..................................................Segmentation fault More verbosely: >>> numpy.test(10,10) Found 5 tests for numpy.distutils.misc_util Warning: No test file found in /usr/local/lib/python2.4/site-packages/numpy/core/tests for module [snip] Found 0 tests for __main__ check_1 (numpy.distutils.tests.test_misc_util.test_appendpath) ... ok check_2 (numpy.distutils.tests.test_misc_util.test_appendpath) ... ok check_3 (numpy.distutils.tests.test_misc_util.test_appendpath) ... ok [snip] test_priority (numpy.core.tests.test_umath.test_special_methods) ... ok test_wrap (numpy.core.tests.test_umath.test_special_methods) ... ok check_types (numpy.core.tests.test_scalarmath.test_types)Segmentation fault I'm guessing that since this is a release (and not from SVN), that not all Fedora users are having this problem. If anyone can suggest something that may be wrong on my end that I could fix, please let me know. I'm reporting it here in case it's a real bug. I've seen a few test failure reports in recent digests, but not on FC3. I thought I'd next try SVN, but the latest digest message has encouraged me to hold off a day.... -Tom ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From fperez.net at gmail.com Thu Jun 22 18:02:50 2006 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 22 Jun 2006 16:02:50 -0600 Subject: [SciPy-dev] weave and 64-bit platforms Message-ID: <449B138A.3060204@gmail.com> Hi all, the following little script planck[~]> cat weavebug.py #!/usr/bin/env python import numpy as N from scipy.weave import inline vec = N.rand(100) code = """ double sum = 0.0; int npts = Nvec[0]; for (int i=0;i /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp: In function `PyObject* compiled_func(PyObject*, PyObject*)': /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp:662: error: cannot convert `intp*' to `int*' in initialization /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp:663: error: cannot convert `intp*' to `int*' in initialization /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp: In function `PyObject* compiled_func(PyObject*, PyObject*)': /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp:662: error: cannot convert `intp*' to `int*' in initialization /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp:663: error: cannot convert `intp*' to `int*' in initialization the relevant python numbers are: Python 2.3.4 (#1, Feb 2 2005, 11:44:13) [GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> from scipy import weave >>> numpy.__version__ '0.9.9.2635' >>> weave.__version__ '0.4.9' >>> import scipy >>> scipy.__version__ '0.5.0.1982' Now, looking at the generated cpp files shows stuff like: /* argument conversion code */ py_vec = get_variable("vec",raw_locals,raw_globals); PyArrayObject* vec_array = convert_to_numpy(py_vec,"vec"); conversion_numpy_check_type(vec_array,PyArray_DOUBLE,"vec"); int* Nvec = vec_array->dimensions; int* Svec = vec_array->strides; and those last two lines are probably not kosher on a 64-bit system. Is anyone comfortable enough with 64-bit issues to know how to fix this one? Unfortunately the problem is happening on a collaborator's machine to which I don't have direct access, so it's not easy for me to test anything if I make changes to the source. And given that I'm not very experienced with how numpy handles 64-bit cleanness, I'm really afraid I'd break something if I tried. If nobody can tackle this one, but is at least willing to provide some pointers, I'd be very grateful. It's critical enough for me that I'll fix it myself if need be. Cheers, f From robert.kern at gmail.com Thu Jun 22 18:08:32 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 22 Jun 2006 17:08:32 -0500 Subject: [SciPy-dev] weave and 64-bit platforms In-Reply-To: <449B138A.3060204@gmail.com> References: <449B138A.3060204@gmail.com> Message-ID: <449B14E0.8@gmail.com> Fernando Perez wrote: > Hi all, > > the following little script > > planck[~]> cat weavebug.py > #!/usr/bin/env python > import numpy as N > from scipy.weave import inline > > vec = N.rand(100) > > code = """ > double sum = 0.0; > int npts = Nvec[0]; > for (int i=0;i sum += vec[i]; > } > return_val = sum; > """ > > print inline(code,['vec']) > print vec.sum() > > # EOF > > works just fine on my 32-bit desktop, but is failing on a 64-bit install with: > > [mjm at infinite private]$ python weavebug.py > > /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp: > In function `PyObject* compiled_func(PyObject*, PyObject*)': > /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp:662: > error: cannot convert `intp*' to `int*' in initialization > /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp:663: > error: cannot convert `intp*' to `int*' in initialization > /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp: > In function `PyObject* compiled_func(PyObject*, PyObject*)': > /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp:662: > error: cannot convert `intp*' to `int*' in initialization > /home/mjm/.python23_compiled/sc_117c9bd1cecd5efd70827f0f4991867b1.cpp:663: > error: cannot convert `intp*' to `int*' in initialization > > the relevant python numbers are: > > Python 2.3.4 (#1, Feb 2 2005, 11:44:13) > [GCC 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import numpy > >>> from scipy import weave > >>> numpy.__version__ > '0.9.9.2635' > >>> weave.__version__ > '0.4.9' > >>> import scipy > >>> scipy.__version__ > '0.5.0.1982' > > > Now, looking at the generated cpp files shows stuff like: > > /* argument conversion code */ > py_vec = get_variable("vec",raw_locals,raw_globals); > PyArrayObject* vec_array = convert_to_numpy(py_vec,"vec"); > conversion_numpy_check_type(vec_array,PyArray_DOUBLE,"vec"); > int* Nvec = vec_array->dimensions; > int* Svec = vec_array->strides; > > and those last two lines are probably not kosher on a 64-bit system. > > Is anyone comfortable enough with 64-bit issues to know how to fix this one? > Unfortunately the problem is happening on a collaborator's machine to which I > don't have direct access, so it's not easy for me to test anything if I make > changes to the source. And given that I'm not very experienced with how numpy > handles 64-bit cleanness, I'm really afraid I'd break something if I tried. > > If nobody can tackle this one, but is at least willing to provide some > pointers, I'd be very grateful. It's critical enough for me that I'll fix it > myself if need be. That segment of code is in standard_array_spec.py . I think those int*s should be intp*s. I think I made that modification in my checkout copy, but I never tested it on 32-bit so I didn't check it in. If you can provide an example for me to try without thinking, I'll test it on my machine with that change and you test it on your 32-bit machine. -- 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 fperez.net at gmail.com Thu Jun 22 18:13:26 2006 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 22 Jun 2006 16:13:26 -0600 Subject: [SciPy-dev] weave and 64-bit platforms In-Reply-To: <449B14E0.8@gmail.com> References: <449B138A.3060204@gmail.com> <449B14E0.8@gmail.com> Message-ID: On 6/22/06, Robert Kern wrote: > That segment of code is in standard_array_spec.py . I think those int*s should > be intp*s. I think I made that modification in my checkout copy, but I never > tested it on 32-bit so I didn't check it in. > > If you can provide an example for me to try without thinking, I'll test it on my > machine with that change and you test it on your 32-bit machine. Mmh, is the script I included in the previous mail not enough? It passes on 32-bits but fails on 64. Here it is again (let me know if you want something different): #!/usr/bin/env python import numpy as N from scipy.weave import inline vec = N.rand(100) code = """ double sum = 0.0; int npts = Nvec[0]; for (int i=0;i References: <449B138A.3060204@gmail.com> <449B14E0.8@gmail.com> Message-ID: <449B1836.5010603@gmail.com> Fernando Perez wrote: > On 6/22/06, Robert Kern wrote: > >> That segment of code is in standard_array_spec.py . I think those int*s should >> be intp*s. I think I made that modification in my checkout copy, but I never >> tested it on 32-bit so I didn't check it in. >> >> If you can provide an example for me to try without thinking, I'll test it on my >> machine with that change and you test it on your 32-bit machine. > > Mmh, is the script I included in the previous mail not enough? Sorry, not thinking. > It > passes on 32-bits but fails on 64. Here it is again (let me know if > you want something different): Can you try it after you make the change I suggested? -- 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 Thu Jun 22 18:26:51 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 22 Jun 2006 17:26:51 -0500 Subject: [SciPy-dev] weave and 64-bit platforms In-Reply-To: References: <449B138A.3060204@gmail.com> <449B14E0.8@gmail.com> Message-ID: <449B192B.7060904@gmail.com> Fernando Perez wrote: > On 6/22/06, Robert Kern wrote: > >> That segment of code is in standard_array_spec.py . I think those int*s should >> be intp*s. I think I made that modification in my checkout copy, but I never >> tested it on 32-bit so I didn't check it in. >> >> If you can provide an example for me to try without thinking, I'll test it on my >> machine with that change and you test it on your 32-bit machine. > > Mmh, is the script I included in the previous mail not enough? It > passes on 32-bits but fails on 64. It works for me after changing int* to intp*. -- 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 fperez.net at gmail.com Thu Jun 22 18:34:35 2006 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 22 Jun 2006 16:34:35 -0600 Subject: [SciPy-dev] weave and 64-bit platforms In-Reply-To: <449B192B.7060904@gmail.com> References: <449B138A.3060204@gmail.com> <449B14E0.8@gmail.com> <449B192B.7060904@gmail.com> Message-ID: On 6/22/06, Robert Kern wrote: > Fernando Perez wrote: > > On 6/22/06, Robert Kern wrote: > > > >> That segment of code is in standard_array_spec.py . I think those int*s should > >> be intp*s. I think I made that modification in my checkout copy, but I never > >> tested it on 32-bit so I didn't check it in. > >> > >> If you can provide an example for me to try without thinking, I'll test it on my > >> machine with that change and you test it on your 32-bit machine. > > > > Mmh, is the script I included in the previous mail not enough? It > > passes on 32-bits but fails on 64. > > It works for me after changing int* to intp*. Works on 32-bit Fedora3, python2.3. Thanks! Let me know if you commit it, else I can do it and inform my colleagues to update. Regards, f From oliphant.travis at ieee.org Thu Jun 22 19:46:29 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 22 Jun 2006 17:46:29 -0600 Subject: [SciPy-dev] [Numpy-discussion] Recent SVN of NumPy has issues with SciPy In-Reply-To: <449AE817.1020700@ieee.org> References: <449AE817.1020700@ieee.org> Message-ID: <449B2BD5.1000401@ieee.org> Travis Oliphant wrote: > There are still some issues with my recent check-in for NumPy (r2663). > But, it does build and run the numpy.tests cleanly. (It's failing on > SciPy tests...) > These issues are now fixed (it was a brain-dead optimization that just doesn't work and was only exposed when converting between C- and Fortran- arrays during a cast.. Feel free to use SVN again... I do like to keep SVN so that it works. -Travis From stephen.walton at csun.edu Sat Jun 24 18:02:06 2006 From: stephen.walton at csun.edu (Stephen Walton) Date: Sat, 24 Jun 2006 15:02:06 -0700 Subject: [SciPy-dev] Numpy tests crash on FC3, Py-2.4.3 In-Reply-To: <1151008660.449aff94229a9@astrosun2.astro.cornell.edu> References: <1151008660.449aff94229a9@astrosun2.astro.cornell.edu> Message-ID: <449DB65E.50904@csun.edu> Tom Loredo wrote: > Doing housecleaning today---updating to Py 2.4.3 and the latest > numpy/scipy/mpl on a linux (FC3) box. Alas, numpy-0.9.8 tests > give a segfault: > > test_priority (numpy.core.tests.test_umath.test_special_methods) ... ok > test_wrap (numpy.core.tests.test_umath.test_special_methods) ... ok > check_types (numpy.core.tests.test_scalarmath.test_types)Segmentation fault > See http://article.gmane.org/gmane.comp.python.numeric.general/6189. From kwgoodman at gmail.com Sat Jun 24 22:36:44 2006 From: kwgoodman at gmail.com (Keith Goodman) Date: Sat, 24 Jun 2006 19:36:44 -0700 Subject: [SciPy-dev] Typo in numpy README.txt Message-ID: I noticed a typo in the numpy README file. Instead of http://svn.numpy.org/svn/numpy/trunk it should be http://svn.scipy.org/svn/numpy/trunk From robert.kern at gmail.com Sun Jun 25 00:08:46 2006 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 24 Jun 2006 23:08:46 -0500 Subject: [SciPy-dev] Typo in numpy README.txt In-Reply-To: References: Message-ID: <449E0C4E.8010007@gmail.com> Keith Goodman wrote: > I noticed a typo in the numpy README file. Fixed in SVN. -- 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 karol.langner at kn.pl Sun Jun 25 13:38:40 2006 From: karol.langner at kn.pl (Karol Langner) Date: Sun, 25 Jun 2006 19:38:40 +0200 Subject: [SciPy-dev] basearray Message-ID: <200606251938.40507.karol.langner@kn.pl> Dear all, Some of you might be aware that a project has been granted to me for this year's Google's Summer of Code, which aims at preparing a base multidimensional array type for Python. While I had a late start at it, I would like to go through with the project. The focus is on preparing a minimal type, that basically only defines how memory is alllocated for the array, and which can be used by other, more sophisticated types. Later during the project, the type may be enhanced, depending on how using it in practice (also part of the project) works out. Wiki page about the project: http://scipy.org/BaseArray SVN repository: http://svn.scipy.org/svn/PEP/ In order to make this a potential success, I definately need feedback from all you out there interested in pushing such a base type towards Python core. So any comments and opinions are welcome! I will keep you informed on my progress and ask about things that may need concensus (although I'm not sure which lists will be the most interested in this). Please note that I am still in the phase of completing the minimal type, so the svn repository does not contain a working example, yet. Regards, Karol Langner -- written by Karol Langner nie cze 25 19:18:45 CEST 2006 From arnd.baecker at web.de Mon Jun 26 04:53:34 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Mon, 26 Jun 2006 10:53:34 +0200 (CEST) Subject: [SciPy-dev] cgemv test failure Message-ID: Hi, on 64 Bit I get with 0.5.0.2000: ====================================================================== FAIL: check_x_stride_transpose (scipy.linalg.tests.test_fblas.test_cgemv) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/scipy/linalg/tests/test_fblas.py", line 348, in check_x_stride_transpose assert_array_almost_equal(desired_y,y) File "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/testing/utils.py", line 222, in assert_array_almost_equal header='Arrays are not almost equal') File "/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/testing/utils.py", line 207, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 33.3333333333%) x: array([ 12.88130569-12.88130569j, -13.69222832+15.69222832j, -12.8252039 +16.82520294j], dtyp y: array([ 12.88130569-12.88130569j, -13.69222832+15.69222832j, -12.8252039 +16.82520485j], dtyp The only warnings related to cgemv during the build were: gcc: Lib/linsolve/SuperLU/SRC/cpanel_bmod.c Lib/linsolve/SuperLU/SRC/cpanel_bmod.c:31: warning: function declaration isn't a prototype Lib/linsolve/SuperLU/SRC/cpanel_bmod.c: In function `cpanel_bmod': Lib/linsolve/SuperLU/SRC/cpanel_bmod.c:229: warning: implicit declaration of function `ctrsv_' Lib/linsolve/SuperLU/SRC/cpanel_bmod.c:276: warning: implicit declaration of function `cgemv_' gcc: Lib/linsolve/SuperLU/SRC/csnode_bmod.c The only pointer warnings during the build were: compile options: '-DATLAS_INFO="\"3.7.11\"" -I/scr/python/include -Ibuild/src.linux-x86_64-2.4 -I/home/abaecker/BUILDS3/BuildDir/inst_numpy/lib/python2.4/site-packages/numpy/core/include -I/scr/python/include/python2.4 -c' gcc: build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c: In function `f2py_rout_flapack_cheev': build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c:9761: warning: passing arg 6 of pointer to function from incompatible pointer type build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c: In function `f2py_rout_flapack_zheev': build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.c:9945: warning: passing arg 6 of pointer to function from incompatible pointer type /scr/python/bin/g77 -shared build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/build/src.linux-x86_64-2.4/scipy/linalg/flapackmodule.o build/temp.linux-x86_64-2.4/build/src.linux-x86_64-2.4/fortranobject.o -L/scr/python/lib64 -Lbuild/temp.linux-x86_64-2.4 -llapack -lptf77blas -lptcblas -latlas -lg2c -o build/lib.linux-x86_64-2.4/scipy/linalg/flapack.so building 'scipy.linalg.clapack' extension compiling C sources C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -fPIC Best, Arnd From arnd.baecker at web.de Tue Jun 27 02:23:21 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Tue, 27 Jun 2006 08:23:21 +0200 (CEST) Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: References: Message-ID: Hi, as I have not recieved any feedback, would anyone mind if we just do the changes and commit the code to svn? Best, Arnd On Fri, 16 Jun 2006, Arnd Baecker wrote: > Hi, > > thanks to Johannes Loehnert and Waltraut Wustmann > the previous f2py wrappers have been supplied with many > more unit-tests, documentation and wrappers > for hermitian band matrices. > The wrappers deals with: > sbev sbevd sbevx > hbevd hbevx > gbtrf gbtrs > lamch > In addition front-end routines `eig_banded`, `eigvals_banded` > for inclusion in Lib/linalg/decomp.py are provided. > > The current version is at > http://www.physik.tu-dresden.de/~baecker/python/band.zip > > Pearu, it would be nice if you could have a look > at the wrappers and let us know whether anything needs to > be done/improved. > If you prefer I can do a commit (after following the steps in the TODO), > but I would like to get your ok first > (I also don't mind if you prefer to make the corresponding > changes ;-). > > Hope the result is useful not just for us but also to others. > In addition, the contents of band.zip might be helpful > as an example on how to provide wrappers > for other LAPACK routines. > > Best, Arnd > > > P.S.: In the long run one could also think of adding code > for performing inverse iteration, but this might also fit > into the sparse matrix department. > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > > From nwagner at iam.uni-stuttgart.de Tue Jun 27 03:23:45 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Tue, 27 Jun 2006 09:23:45 +0200 Subject: [SciPy-dev] check_random_complex_overdet (scipy.linalg.tests.test_basic.test_lstsq) Message-ID: <44A0DD01.8040302@iam.uni-stuttgart.de> Hi all, Please correct me but you will need a.transpose().conjugate() instead of a.transpose() in direct_lstsq(a,b) for c o m p l e x overdeternined systems. Am I missing something ? Nils def check_random_overdet(self): n = 20 m = 15 a = random([n,m]) for i in range(m): a[i,i] = 20*(.1+a[i,i]) for i in range(4): b = random([n,3]) x,res,r,s = lstsq(a,b) assert r==m,'unexpected efficient rank' #XXX: check definition of res assert_array_almost_equal(x,direct_lstsq(a,b)) def direct_lstsq(a,b): a1 = numpy.dot(numpy.transpose(a),a) b1 = numpy.dot(numpy.transpose(a),b) return solve(a1,b1) From Bernhard.Hoefle at uibk.ac.at Tue Jun 27 07:37:07 2006 From: Bernhard.Hoefle at uibk.ac.at (Bernhard Reimar Hoefle) Date: Tue, 27 Jun 2006 13:37:07 +0200 Subject: [SciPy-dev] basearray In-Reply-To: References: Message-ID: <1151408227.44a118631606e@web-mail2.uibk.ac.at> Hi! I'm looking forward to the new array type. I'm working with large datasets (LIDAR point clouds) and would welcome an array type that gives back memory when the variable is deleted. I still run into "out of memory" when looping and calculating derivative arrays. Bernhard From nmarais at sun.ac.za Tue Jun 27 18:19:31 2006 From: nmarais at sun.ac.za (Neilen Marais) Date: Wed, 28 Jun 2006 00:19:31 +0200 Subject: [SciPy-dev] dot() and the fate of matrixmultiply() Message-ID: <1151446771.5814.166.camel@localhost.localdomain> Hi With the recent API cleanup in numpy SVN, it seems matrixmultiply() has been removed. I know that dot() does the same thing, but I prefer to use matrixmultiply() since it makes my code easier to understand. Whenever I read dot() I think only of the inner product of two vectors. Also, I'd expect dot() to be a commutative operation, which matrix multiplication is not. Can I make an appeal for matrixmultiply()'s life? I can offer some anecdotal evidence in support for matrixmultiply()'s life: I was a tutor at the recent Py4Science workshop held at Stellenbosch (http://mentat.za.net/py4science/). It was fairly well attended by mathematicians and applied mathematicians, and while they were for the most part well impressed with Python/NumPy/SciPy I heard several of them mutter: "But it's not dot! Dot is for vectors!" when we were doing an example that involved matrix multiplication. I rather identify with them :) Regards Neilen From arnd.baecker at web.de Wed Jun 28 02:29:00 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Wed, 28 Jun 2006 08:29:00 +0200 (CEST) Subject: [SciPy-dev] cgemv test failure In-Reply-To: References: Message-ID: just to report something positive with my (almost;-) daily build on 64Bit: With '0.5.0.2012' **all** tests pass on 64 Bit (apart from the well-known ndimage one). Best, Arnd From tim.leslie at gmail.com Wed Jun 28 02:45:15 2006 From: tim.leslie at gmail.com (Tim Leslie) Date: Wed, 28 Jun 2006 16:45:15 +1000 Subject: [SciPy-dev] cgemv test failure In-Reply-To: References: Message-ID: On 6/28/06, Arnd Baecker wrote: > just to report something positive with > my (almost;-) daily build on 64Bit: > > With '0.5.0.2012' **all** tests pass on 64 Bit > (apart from the well-known ndimage one). Just on the 64 bit ndimage problem, is this something that's being actively worked on, or has it been put on the too-hard backburner until someone with more of a need for it comes along to take another stab at it? Just curious. Cheers, Tim > > Best, Arnd > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > From robert.kern at gmail.com Wed Jun 28 02:52:48 2006 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 28 Jun 2006 01:52:48 -0500 Subject: [SciPy-dev] cgemv test failure In-Reply-To: References: Message-ID: <44A22740.6000401@gmail.com> Tim Leslie wrote: > On 6/28/06, Arnd Baecker wrote: >> just to report something positive with >> my (almost;-) daily build on 64Bit: >> >> With '0.5.0.2012' **all** tests pass on 64 Bit >> (apart from the well-known ndimage one). > > Just on the 64 bit ndimage problem, is this something that's being > actively worked on, or has it been put on the too-hard backburner > until someone with more of a need for it comes along to take another > stab at it? Just curious. I'm pretty sure it's on the "no one with a 64-bit development environment has taken an interest" backburner rather than the "too-hard" backburner. -- 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 oliphant.travis at ieee.org Wed Jun 28 02:55:22 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Wed, 28 Jun 2006 00:55:22 -0600 Subject: [SciPy-dev] cgemv test failure In-Reply-To: References: Message-ID: <44A227DA.6010909@ieee.org> Tim Leslie wrote: > On 6/28/06, Arnd Baecker wrote: > >> just to report something positive with >> my (almost;-) daily build on 64Bit: >> >> With '0.5.0.2012' **all** tests pass on 64 Bit >> (apart from the well-known ndimage one). >> > > Just on the 64 bit ndimage problem, is this something that's being > actively worked on, or has it been put on the too-hard backburner > until someone with more of a need for it comes along to take another > stab at it? Just curious. > Nobody with a 64-bit system has been willing or had the time to fix it, yet (I'm not sure who has access to one). I suspect that when more people start using 64-bit systems it will get solved. It may take a bit of detective work and you really need a 64-bit system to find the problem. -Travis From nwagner at iam.uni-stuttgart.de Wed Jun 28 03:05:36 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Wed, 28 Jun 2006 09:05:36 +0200 Subject: [SciPy-dev] cgemv test failure In-Reply-To: References: Message-ID: <44A22A40.6060605@iam.uni-stuttgart.de> Arnd Baecker wrote: > just to report something positive with > my (almost;-) daily build on 64Bit: > > With '0.5.0.2012' **all** tests pass on 64 Bit > (apart from the well-known ndimage one). > > Best, Arnd > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > On 32 bit there is still one failure but I cannot reproduce it on a 64 bit system. Why ? ====================================================================== FAIL: check_simple (scipy.optimize.tests.test_cobyla.test_cobyla) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/scipy/optimize/tests/test_cobyla.py", line 20, in check_simple assert_almost_equal(x, [x0, x1], decimal=5) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 152, in assert_almost_equal return assert_array_almost_equal(actual, desired, decimal, err_msg) File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 222, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/lib/python2.4/site-packages/numpy/testing/utils.py", line 207, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 100.0%) x: array([ 4.957975 , 0.64690335]) y: array([ 4.95535625, 0.66666667]) ---------------------------------------------------------------------- Ran 1541 tests in 14.704s FAILED (failures=1) >>> scipy.__version__ '0.5.0.2012' >>> numpy.__version__ '0.9.9.2696' From oliphant.travis at ieee.org Wed Jun 28 03:14:21 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Wed, 28 Jun 2006 01:14:21 -0600 Subject: [SciPy-dev] cgemv test failure In-Reply-To: <44A22A40.6060605@iam.uni-stuttgart.de> References: <44A22A40.6060605@iam.uni-stuttgart.de> Message-ID: <44A22C4D.4050309@ieee.org> Nils Wagner wrote: > Arnd Baecker wrote: > >> just to report something positive with >> my (almost;-) daily build on 64Bit: >> >> With '0.5.0.2012' **all** tests pass on 64 Bit >> (apart from the well-known ndimage one). >> >> Best, Arnd >> >> _______________________________________________ >> Scipy-dev mailing list >> Scipy-dev at scipy.net >> http://www.scipy.net/mailman/listinfo/scipy-dev >> >> > > > On 32 bit there is still one failure but I cannot reproduce it on a 64 > bit system. Why ? > I don't know. I looked at it a bit, but couldn't see anything obvious. But, since you have access to both systems you are in a great position to figure out why it is failing on 32-bit systems. Insert some print-statements in the fmin_cobyla code (the calcfc function might be a good place) and compare the outputs on the two systems when you run just that test. It would be great if you could help track it down. -Travis From nwagner at iam.uni-stuttgart.de Wed Jun 28 03:28:41 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Wed, 28 Jun 2006 09:28:41 +0200 Subject: [SciPy-dev] cgemv test failure In-Reply-To: <44A22C4D.4050309@ieee.org> References: <44A22A40.6060605@iam.uni-stuttgart.de> <44A22C4D.4050309@ieee.org> Message-ID: <44A22FA9.30102@iam.uni-stuttgart.de> Travis Oliphant wrote: > Nils Wagner wrote: > >> Arnd Baecker wrote: >> >> >>> just to report something positive with >>> my (almost;-) daily build on 64Bit: >>> >>> With '0.5.0.2012' **all** tests pass on 64 Bit >>> (apart from the well-known ndimage one). >>> >>> Best, Arnd >>> >>> _______________________________________________ >>> Scipy-dev mailing list >>> Scipy-dev at scipy.net >>> http://www.scipy.net/mailman/listinfo/scipy-dev >>> >>> >>> >> On 32 bit there is still one failure but I cannot reproduce it on a 64 >> bit system. Why ? >> >> > > I don't know. I looked at it a bit, but couldn't see anything obvious. > > But, since you have access to both systems you are in a great position > to figure out why it is failing on 32-bit systems. Insert some > print-statements in the fmin_cobyla code (the calcfc function might be a > good place) and compare the outputs on the two systems when you run just > that test. > > It would be great if you could help track it down. > > -Travis > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > Let's start with the example in test_cobyla.py function = lambda x: x[0]**2 + abs(x[1])**3 con1 = lambda x: x[0]**2 + x[1]**2 - 25 con2 = lambda x: -con1(x) I guess it is taken from a book on optimization. Is that true ? A reference would be fine. cons -- a sequence of functions that all must be >=0 (a single function if only 1 constraint) The first constraint reads x^2 + y^2 -25 \ge 0 The second constraint is -x^2-y^2+25 \ge 0 or x^2+y^2 -25 \le 0 Does that mean that we can combine both inequality constraints to one equality constraint - a circle with radius 5 and center in (x=0,y=0)? Nils From nwagner at iam.uni-stuttgart.de Wed Jun 28 04:41:25 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Wed, 28 Jun 2006 10:41:25 +0200 Subject: [SciPy-dev] cgemv test failure In-Reply-To: <44A22C4D.4050309@ieee.org> References: <44A22A40.6060605@iam.uni-stuttgart.de> <44A22C4D.4050309@ieee.org> Message-ID: <44A240B5.8010801@iam.uni-stuttgart.de> Travis Oliphant wrote: > Nils Wagner wrote: > >> Arnd Baecker wrote: >> >> >>> just to report something positive with >>> my (almost;-) daily build on 64Bit: >>> >>> With '0.5.0.2012' **all** tests pass on 64 Bit >>> (apart from the well-known ndimage one). >>> >>> Best, Arnd >>> >>> _______________________________________________ >>> Scipy-dev mailing list >>> Scipy-dev at scipy.net >>> http://www.scipy.net/mailman/listinfo/scipy-dev >>> >>> >>> >> On 32 bit there is still one failure but I cannot reproduce it on a 64 >> bit system. Why ? >> >> > > I don't know. I looked at it a bit, but couldn't see anything obvious. > > But, since you have access to both systems you are in a great position > to figure out why it is failing on 32-bit systems. Insert some > print-statements in the fmin_cobyla code (the calcfc function might be a > good place) and compare the outputs on the two systems when you run just > that test. > > It would be great if you could help track it down. > > -Travis > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > Travis, Here is the output of mycobyla.py 32bit: Linux amanda 2.6.11.4-21.12-default #1 Wed May 10 09:38:20 UTC 2006 i686 athlon i386 GNU/Linux Result by cobyla with one constraint [ 4.95535574 0.66667043] Result by cobyla with two constraints [ 4.957975 0.64690335] Exact results [ 4.95535625 0.66666667] 64bit: Linux lisa 2.6.13-15.10-default #1 Fri May 12 16:13:03 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux Result by cobyla with one constraint [ 4.95535574 0.66667043] Result by cobyla with two constraints [ 4.95535778 0.6666553 ] Exact results [ 4.95535625 0.66666667] So, the difference in the results is associated with the constraints. Do you agree ? Nils -------------- next part -------------- A non-text attachment was scrubbed... Name: mycobyla.py Type: text/x-python Size: 839 bytes Desc: not available URL: From stefan at sun.ac.za Wed Jun 28 05:20:33 2006 From: stefan at sun.ac.za (Stefan van der Walt) Date: Wed, 28 Jun 2006 11:20:33 +0200 Subject: [SciPy-dev] cgemv test failure In-Reply-To: <44A227DA.6010909@ieee.org> References: <44A227DA.6010909@ieee.org> Message-ID: <20060628092033.GA21955@mentat.za.net> On Wed, Jun 28, 2006 at 12:55:22AM -0600, Travis Oliphant wrote: > Tim Leslie wrote: > > On 6/28/06, Arnd Baecker wrote: > > > >> just to report something positive with > >> my (almost;-) daily build on 64Bit: > >> > >> With '0.5.0.2012' **all** tests pass on 64 Bit > >> (apart from the well-known ndimage one). > >> > > > > Just on the 64 bit ndimage problem, is this something that's being > > actively worked on, or has it been put on the too-hard backburner > > until someone with more of a need for it comes along to take another > > stab at it? Just curious. > > > Nobody with a 64-bit system has been willing or had the time to fix it, > yet (I'm not sure who has access to one). I suspect that when more > people start using 64-bit systems it will get solved. > > It may take a bit of detective work and you really need a 64-bit system > to find the problem. I see no ticket on the subject. Can anyone elaborate on the problem? I just compiled ndimage on a friend's 64-bit machine, and, at random, tested geometric_transform, which works fine. Should we enable ndimage and take the tickets as they come in? Regards St?fan From schmitt at num.uni-sb.de Wed Jun 28 05:44:11 2006 From: schmitt at num.uni-sb.de (Uwe Schmitt) Date: Wed, 28 Jun 2006 11:44:11 +0200 Subject: [SciPy-dev] want to contribute bvp-solver In-Reply-To: <44A22C4D.4050309@ieee.org> Message-ID: <200606280944.k5S9iBna23615023@justus.rz.uni-saarland.de> Hello, I wrapped MUSL from www.netlib.org/ode/mus.doc using f2py. It works fine, but I do not know how to contribute my code to SciPy. I read the DEVELOPERS.txt but I still have questions. The structure is as follows: - musl.f, musl.pyf generate _musl.pyd - mus.py imports _musl.pyd and provides a wrapper consisting of a single function. How do I have to setup setup.py ? Greetings, Uwe From pearu at scipy.org Wed Jun 28 05:53:48 2006 From: pearu at scipy.org (Pearu Peterson) Date: Wed, 28 Jun 2006 04:53:48 -0500 (CDT) Subject: [SciPy-dev] want to contribute bvp-solver In-Reply-To: <200606280944.k5S9iBna23615023@justus.rz.uni-saarland.de> References: <200606280944.k5S9iBna23615023@justus.rz.uni-saarland.de> Message-ID: On Wed, 28 Jun 2006, Uwe Schmitt wrote: > > Hello, > > I wrapped MUSL from www.netlib.org/ode/mus.doc > using f2py. It works fine, but I do not know > how to contribute my code to SciPy. > I read the DEVELOPERS.txt but I still have questions. > > The structure is as follows: > > - musl.f, musl.pyf generate _musl.pyd > - mus.py imports _musl.pyd and provides a > wrapper consisting of a single function. > > How do I have to setup setup.py ? Read http://scipy.org/NumPyDistutils I suggest letting musl.pyf to generate musl.pyd (so that the name of entension module will match the name of signature file) or rename musl.pyf to _musl.pyf. Here follows the content of the corresponding setup.py file using the renamed musl.pyf and assuming that all files are under musl/ directory (in scipy svn tree it should be under the sandbox/ directory): #!/usr/bin/env python def configuration(parent_package='',top_path=None): from numpy.distutils.misc_util import Configuration config = Configuration('musl',parent_package,top_path) config.add_extension('_musl', sources = ['_musl.pyf', 'musl.f']) return config if __name__ == "__main__": from numpy.distutils.core import setup setup(configuration=configuration) HTH, Pearu From schmitt at num.uni-sb.de Wed Jun 28 10:55:11 2006 From: schmitt at num.uni-sb.de (Uwe Schmitt) Date: Wed, 28 Jun 2006 16:55:11 +0200 Subject: [SciPy-dev] [mailinglist] Re: want to contribute bvp-solver In-Reply-To: Message-ID: <200606281455.k5SEtBfC16505059@triton.rz.uni-saarland.de> || || > || > Hello, || > || > I wrapped MUSL from www.netlib.org/ode/mus.doc || > using f2py. It works fine, but I do not know || > how to contribute my code to SciPy. || > I read the DEVELOPERS.txt but I still have questions. || > || > The structure is as follows: || > || > - musl.f, musl.pyf generate _musl.pyd || > - mus.py imports _musl.pyd and provides a || > wrapper consisting of a single function. || > || > How do I have to setup setup.py ? || || Read http://scipy.org/NumPyDistutils || || I suggest letting musl.pyf to generate musl.pyd (so that the name of || entension module will match the name of signature file) or || rename musl.pyf || to _musl.pyf. || || Here follows the content of the corresponding setup.py file || using the || renamed musl.pyf and assuming that all files are under musl/ || directory || (in scipy svn tree it should be under the sandbox/ directory): I do not find mus.py below: mus.py now imports _musl.pyd, ( later _musn.pyd ) and provides functions mus.musl() and mus.musn() as wrappers of _mus?.pyd. Greetings, Uwe || || #!/usr/bin/env python || def configuration(parent_package='',top_path=None): || from numpy.distutils.misc_util import Configuration || config = Configuration('musl',parent_package,top_path) || config.add_extension('_musl', sources = ['_musl.pyf', 'musl.f']) || return config || || if __name__ == "__main__": || from numpy.distutils.core import setup || setup(configuration=configuration) || || HTH, || Pearu || || _______________________________________________ || Scipy-dev mailing list || Scipy-dev at scipy.net || http://www.scipy.net/mailman/listinfo/scipy-dev || From robert.kern at gmail.com Wed Jun 28 12:34:16 2006 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 28 Jun 2006 11:34:16 -0500 Subject: [SciPy-dev] [mailinglist] Re: want to contribute bvp-solver In-Reply-To: <200606281455.k5SEtBfC16505059@triton.rz.uni-saarland.de> References: <200606281455.k5SEtBfC16505059@triton.rz.uni-saarland.de> Message-ID: <44A2AF88.3020402@gmail.com> Uwe Schmitt wrote: > || > || > > || > Hello, > || > > || > I wrapped MUSL from www.netlib.org/ode/mus.doc > || > using f2py. It works fine, but I do not know > || > how to contribute my code to SciPy. > || > I read the DEVELOPERS.txt but I still have questions. I do not see a license on that code. I'm afraid we cannot accept contributions which do not have a license compatible with the Scipy license. Could you please contact the authors of the code for a statement as to who owns the copyright on the code and the license under which they are releasing the code? Thanks. > I do not find mus.py below: > mus.py now imports _musl.pyd, ( later _musn.pyd ) and provides > functions mus.musl() and mus.musn() as wrappers of _mus?.pyd. .py files will automatically get picked up. [Pearu Peterson wrote:] > || #!/usr/bin/env python > || def configuration(parent_package='',top_path=None): > || from numpy.distutils.misc_util import Configuration > || config = Configuration('musl',parent_package,top_path) > || config.add_extension('_musl', sources = ['_musl.pyf', 'musl.f']) > || return config > || > || if __name__ == "__main__": > || from numpy.distutils.core import setup > || setup(configuration=configuration) -- 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 Wed Jun 28 18:03:15 2006 From: jstrunk at enthought.com (Jeff Strunk) Date: Wed, 28 Jun 2006 17:03:15 -0500 Subject: [SciPy-dev] Mail and mailing list migration Message-ID: <200606281703.15385.jstrunk@enthought.com> Good Afternoon, Tomorrow morning at about 10:00am Central time I will migrate the Mailman mailing lists from old.scipy.org to new.scipy.org. Any mail sent to mail.scipy.org after that time will end up at new.scipy.org. This will cause a short delay in mailing list delivery in the morning. Thank you, Jeff Strunk IT Administrator Enthought Inc. From arnd.baecker at web.de Thu Jun 29 01:57:12 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Thu, 29 Jun 2006 07:57:12 +0200 (CEST) Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: References: Message-ID: Hi, sorry for asking again, but I would really be happy to get this finished... Travis, Robert or Pearu: may I go ahead with integrating the band matrix wrappers into scipy svn? Best, Arnd On Tue, 27 Jun 2006, Arnd Baecker wrote: > Hi, > > as I have not recieved any feedback, would anyone mind > if we just do the changes and commit the code to svn? > > Best, Arnd > > > > On Fri, 16 Jun 2006, Arnd Baecker wrote: > > > Hi, > > > > thanks to Johannes Loehnert and Waltraut Wustmann > > the previous f2py wrappers have been supplied with many > > more unit-tests, documentation and wrappers > > for hermitian band matrices. > > The wrappers deals with: > > sbev sbevd sbevx > > hbevd hbevx > > gbtrf gbtrs > > lamch > > In addition front-end routines `eig_banded`, `eigvals_banded` > > for inclusion in Lib/linalg/decomp.py are provided. > > > > The current version is at > > http://www.physik.tu-dresden.de/~baecker/python/band.zip > > > > Pearu, it would be nice if you could have a look > > at the wrappers and let us know whether anything needs to > > be done/improved. > > If you prefer I can do a commit (after following the steps in the TODO), > > but I would like to get your ok first > > (I also don't mind if you prefer to make the corresponding > > changes ;-). > > > > Hope the result is useful not just for us but also to others. > > In addition, the contents of band.zip might be helpful > > as an example on how to provide wrappers > > for other LAPACK routines. > > > > Best, Arnd > > > > > > P.S.: In the long run one could also think of adding code > > for performing inverse iteration, but this might also fit > > into the sparse matrix department. > > > > _______________________________________________ > > Scipy-dev mailing list > > Scipy-dev at scipy.net > > http://www.scipy.net/mailman/listinfo/scipy-dev > > > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > > From oliphant.travis at ieee.org Thu Jun 29 02:21:07 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 29 Jun 2006 00:21:07 -0600 Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: References: Message-ID: <44A37153.5010200@ieee.org> Arnd Baecker wrote: > Hi, > > sorry for asking again, but I would really be happy > to get this finished... > > Travis, Robert or Pearu: may I go ahead with integrating > the band matrix wrappers into scipy svn? > I say go ahead. It looks like an additional feature with a reasonable interface that should not affect other code. -Travis From jstrunk at enthought.com Thu Jun 29 12:47:41 2006 From: jstrunk at enthought.com (Jeff Strunk) Date: Thu, 29 Jun 2006 11:47:41 -0500 Subject: [SciPy-dev] Mail and mailing list migration In-Reply-To: <200606281703.15385.jstrunk@enthought.com> References: <200606281703.15385.jstrunk@enthought.com> Message-ID: <200606291147.41677.jstrunk@enthought.com> Good morning, I have completed the mailing list migration from old.scipy.org to new.scipy.org. If you have any questions or problems, please let me know. Thank you, Jeff Strunk IT Administrator Enthought Inc On Wednesday 28 June 2006 5:03 pm, Jeff Strunk wrote: > Good Afternoon, > > Tomorrow morning at about 10:00am Central time I will migrate the Mailman > mailing lists from old.scipy.org to new.scipy.org. Any mail sent to > mail.scipy.org after that time will end up at new.scipy.org. > > This will cause a short delay in mailing list delivery in the morning. > > Thank you, > Jeff Strunk > IT Administrator > Enthought Inc. > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From oliphant.travis at ieee.org Thu Jun 29 16:44:26 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 29 Jun 2006 14:44:26 -0600 Subject: [SciPy-dev] Anyone know how to get SciPy on MacBook Pro Intel Message-ID: <44A43BAA.4010201@ieee.org> I just got a nice shiny MacBook Pro with the Intel chip. It looks like a nice and slick piece of hardware. Besides the ugly issues of fat-binaries, fink vs. darwinports, etc. it looks like g77 has not been ported to the Mac Intel. I've heard reports that gfortran does not work for SciPy. I was able to get the sources to compile but then had linking errors on import (is that the usual behavior other people see). Anyway, I've played with it too long. I'd hate to see my macbook pro go under-utilized because I can't get SciPy working on it. -Travis From kwgoodman at gmail.com Thu Jun 29 16:50:33 2006 From: kwgoodman at gmail.com (Keith Goodman) Date: Thu, 29 Jun 2006 13:50:33 -0700 Subject: [SciPy-dev] Anyone know how to get SciPy on MacBook Pro Intel In-Reply-To: <44A43BAA.4010201@ieee.org> References: <44A43BAA.4010201@ieee.org> Message-ID: On 6/29/06, Travis Oliphant wrote: > > I just got a nice shiny MacBook Pro with the Intel chip. It looks like > a nice and slick piece of hardware. > > Besides the ugly issues of fat-binaries, fink vs. darwinports, etc. it > looks like g77 has not been ported to the Mac Intel. > > I've heard reports that gfortran does not work for SciPy. I was able to > get the sources to compile but then had linking errors on import (is > that the usual behavior other people see). > > Anyway, I've played with it too long. I'd hate to see my macbook pro go > under-utilized because I can't get SciPy working on it. Ubuntu From kwgoodman at gmail.com Thu Jun 29 16:50:33 2006 From: kwgoodman at gmail.com (Keith Goodman) Date: Thu, 29 Jun 2006 13:50:33 -0700 Subject: [SciPy-dev] Anyone know how to get SciPy on MacBook Pro Intel In-Reply-To: <44A43BAA.4010201@ieee.org> References: <44A43BAA.4010201@ieee.org> Message-ID: On 6/29/06, Travis Oliphant wrote: > > I just got a nice shiny MacBook Pro with the Intel chip. It looks like > a nice and slick piece of hardware. > > Besides the ugly issues of fat-binaries, fink vs. darwinports, etc. it > looks like g77 has not been ported to the Mac Intel. > > I've heard reports that gfortran does not work for SciPy. I was able to > get the sources to compile but then had linking errors on import (is > that the usual behavior other people see). > > Anyway, I've played with it too long. I'd hate to see my macbook pro go > under-utilized because I can't get SciPy working on it. Ubuntu From oliphant.travis at ieee.org Thu Jun 29 16:54:46 2006 From: oliphant.travis at ieee.org (Travis Oliphant) Date: Thu, 29 Jun 2006 14:54:46 -0600 Subject: [SciPy-dev] Anyone know how to get SciPy on MacBook Pro Intel In-Reply-To: References: <44A43BAA.4010201@ieee.org> Message-ID: <44A43E16.8050003@ieee.org> Keith Goodman wrote: > Ubuntu > Just to be clear. Are you suggesting dual booting? Yes, that is certainly a possibility (and may be what I end up doing). But, there are nice MAC applications that would be nice to run. -Travis From jswhit at fastmail.fm Thu Jun 29 17:02:18 2006 From: jswhit at fastmail.fm (Jeff Whitaker) Date: Thu, 29 Jun 2006 15:02:18 -0600 Subject: [SciPy-dev] Anyone know how to get SciPy on MacBook Pro Intel In-Reply-To: <44A43BAA.4010201@ieee.org> References: <44A43BAA.4010201@ieee.org> Message-ID: <44A43FDA.7030702@fastmail.fm> Travis Oliphant wrote: > I just got a nice shiny MacBook Pro with the Intel chip. It looks like > a nice and slick piece of hardware. > > Besides the ugly issues of fat-binaries, fink vs. darwinports, etc. it > looks like g77 has not been ported to the Mac Intel. > > I've heard reports that gfortran does not work for SciPy. I was able to > get the sources to compile but then had linking errors on import (is > that the usual behavior other people see). > > Anyway, I've played with it too long. I'd hate to see my macbook pro go > under-utilized because I can't get SciPy working on it. > > -Travis > Travis: One option is fink (http://fink.sf.net). 'fink install scipy-py24' will get you python 2.4 with numpy and scipy (built with g95). -Jeff p.s. If you go that route and have problems, let me know - I'm the maintainer of the fink scipy package. -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jeffrey.S.Whitaker at noaa.gov 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg From kwgoodman at gmail.com Thu Jun 29 17:06:35 2006 From: kwgoodman at gmail.com (Keith Goodman) Date: Thu, 29 Jun 2006 14:06:35 -0700 Subject: [SciPy-dev] Anyone know how to get SciPy on MacBook Pro Intel In-Reply-To: <44A43E16.8050003@ieee.org> References: <44A43BAA.4010201@ieee.org> <44A43E16.8050003@ieee.org> Message-ID: On 6/29/06, Travis Oliphant wrote: > Keith Goodman wrote: > > Ubuntu > > > Just to be clear. Are you suggesting dual booting? Yes, that is > certainly a possibility (and may be what I end up doing). But, there > are nice MAC applications that would be nice to run. Then it sounds like dual booting is best for you. (It is also possible to run both operating systems simultaneously.) Installation is still a bit of an earlier-adopter affair. Here are some resources: http://desrt.mcmaster.ca/macbook.xhtml http://www.mactel-linux.org/wiki/Main_Page (I plan to buy the low-end MacBook, so I haven't tried any of this yet.) From hazmat at objectrealms.net Thu Jun 29 17:58:05 2006 From: hazmat at objectrealms.net (Kapil Thangavelu) Date: Thu, 29 Jun 2006 14:58:05 -0700 Subject: [SciPy-dev] Anyone know how to get SciPy on MacBook Pro Intel In-Reply-To: <44A43E16.8050003@ieee.org> References: <44A43BAA.4010201@ieee.org> <44A43E16.8050003@ieee.org> Message-ID: <44A44CED.70003@objectrealms.net> i'd recommend using parallels instead of dual booting, i run ubuntu on a macbookpro for some linux specific development running ubuntu, it works well and is nicely performant, in fact it generates much nicer pystones then osx (49k vs. 36k), and its easy to manage, if you something like virtuedesktops, you can have it fullscreen and a keystroke away between switching from mac to linux. the one caveat as applies to some scipy visualization, is opengl performance is all going to be software. if thats a major factor, then dual booting is probably best. http://www.parallels.com/ http://virtuedesktops.info/ hth, kapil Travis Oliphant wrote: > Keith Goodman wrote: >> Ubuntu >> > Just to be clear. Are you suggesting dual booting? Yes, that is > certainly a possibility (and may be what I end up doing). But, there > are nice MAC applications that would be nice to run. > > -Travis > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev From tim.leslie at gmail.com Thu Jun 29 22:53:42 2006 From: tim.leslie at gmail.com (Tim Leslie) Date: Fri, 30 Jun 2006 12:53:42 +1000 Subject: [SciPy-dev] scipy.stats.zs Message-ID: The function scipy.stats.zs, which calculates the z-score of each element of an array, currently recalculates the mean and samplestd for each element, which leads to an O(n^2) running time. Writing the function as follows fixes this and brings it back to O(n) running time. def zs (a): """ Returns a 1D array of z-scores, one for each score in the passed array, computed relative to the passed array. """ mu = mean(a, None) sigma = samplestd(a) return array([(score - mu)/sigma for score in a]) I'm having a few issues with both svn and trac right now, so I can't provide a patch or lodge a ticket, but I'll try to do something about that when I get on to a less broken machine later tonight if noone's picked this up by then. Cheers, Tim Leslie From nwagner at iam.uni-stuttgart.de Fri Jun 30 02:51:03 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 30 Jun 2006 08:51:03 +0200 Subject: [SciPy-dev] author of test_cobyla.py Message-ID: <44A4C9D7.9040600@iam.uni-stuttgart.de> Hi all, Who is the author of test_cobyla.py ? I would like to know the origin of the example. function = lambda x: x[0]**2 + abs(x[1])**3 con1 = lambda x: x[0]**2 + x[1]**2 - 25 con2 = lambda x: -con1(x) Nils From stefan at sun.ac.za Fri Jun 30 04:33:15 2006 From: stefan at sun.ac.za (Stefan van der Walt) Date: Fri, 30 Jun 2006 10:33:15 +0200 Subject: [SciPy-dev] scipy.stats.zs In-Reply-To: References: Message-ID: <20060630083315.GE31219@mentat.za.net> Hi Tim On Fri, Jun 30, 2006 at 12:53:42PM +1000, Tim Leslie wrote: > The function scipy.stats.zs, which calculates the z-score of each > element of an array, currently recalculates the mean and samplestd for > each element, which leads to an O(n^2) running time. Writing the > function as follows fixes this and brings it back to O(n) running > time. Fixed in SVN. Used to be: In [50]: timeit stats.zs(N.random.random(1000)) 10 loops, best of 3: 123 ms per loop Now: In [4]: timeit stats.zs(N.random.random(1000)) 1000 loops, best of 3: 348 ?s per loop Cheers St?fan From arnd.baecker at web.de Fri Jun 30 08:09:49 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 30 Jun 2006 14:09:49 +0200 (CEST) Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: <44A37153.5010200@ieee.org> References: <44A37153.5010200@ieee.org> Message-ID: On Thu, 29 Jun 2006, Travis Oliphant wrote: > Arnd Baecker wrote: > > Hi, > > > > sorry for asking again, but I would really be happy > > to get this finished... > > > > Travis, Robert or Pearu: may I go ahead with integrating > > the band matrix wrappers into scipy svn? > > > I say go ahead. It looks like an additional feature with a reasonable > interface that should not affect other code. Many thanks, code is commited. All tests pass without problems. Best, Arnd From nwagner at iam.uni-stuttgart.de Fri Jun 30 08:19:59 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 30 Jun 2006 14:19:59 +0200 Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: References: <44A37153.5010200@ieee.org> Message-ID: <44A516EF.6080405@iam.uni-stuttgart.de> Arnd Baecker wrote: > On Thu, 29 Jun 2006, Travis Oliphant wrote: > > >> Arnd Baecker wrote: >> >>> Hi, >>> >>> sorry for asking again, but I would really be happy >>> to get this finished... >>> >>> Travis, Robert or Pearu: may I go ahead with integrating >>> the band matrix wrappers into scipy svn? >>> >>> >> I say go ahead. It looks like an additional feature with a reasonable >> interface that should not affect other code. >> > > Many thanks, code is commited. All tests pass without problems. > > Best, Arnd > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > Hi Arnd, Thank you very much for the support of band matrices in scipy. That is very useful. BTW, is it possible to convert full matrices to band matrices and vice versa ? Nils From nwagner at iam.uni-stuttgart.de Fri Jun 30 08:24:49 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 30 Jun 2006 14:24:49 +0200 Subject: [SciPy-dev] eig_banded Message-ID: <44A51811.2000003@iam.uni-stuttgart.de> Eigenvalues and Decompositions: eig --- Find the eigenvalues and vectors of a square matrix eigvals --- Find the eigenvalues of a square matrix lu --- LU decomposition of a matrix lu_factor --- LU decomposition returning unordered matrix and pivots lu_solve --- solve Ax=b using back substitution with output of lu_factor svd --- Singular value decomposition of a matrix svdvals --- Singular values of a matrix diagsvd --- construct matrix of singular values from output of svd orth --- construct orthonormal basis for range of A using svd cholesky --- Cholesky decomposition of a matrix cho_factor --- Cholesky decomposition for use in solving linear system cho_solve --- Solve previously factored linear system qr --- QR decomposition of a matrix schur --- Schur decomposition of a matrix rsf2csf --- Real to complex schur form hessenberg --- Hessenberg form of a matrix An entry for eig_banded is missing. Nils From arnd.baecker at web.de Fri Jun 30 08:58:47 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 30 Jun 2006 14:58:47 +0200 (CEST) Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: <44A516EF.6080405@iam.uni-stuttgart.de> References: <44A37153.5010200@ieee.org> <44A516EF.6080405@iam.uni-stuttgart.de> Message-ID: On Fri, 30 Jun 2006, Nils Wagner wrote: > Arnd Baecker wrote: > > On Thu, 29 Jun 2006, Travis Oliphant wrote: > > > > > >> Arnd Baecker wrote: > >> > >>> Hi, > >>> > >>> sorry for asking again, but I would really be happy > >>> to get this finished... > >>> > >>> Travis, Robert or Pearu: may I go ahead with integrating > >>> the band matrix wrappers into scipy svn? > >>> > >>> > >> I say go ahead. It looks like an additional feature with a reasonable > >> interface that should not affect other code. > >> > > > > Many thanks, code is commited. All tests pass without problems. > > > > Best, Arnd > > _______________________________________________ > > Scipy-dev mailing list > > Scipy-dev at scipy.org > > http://projects.scipy.org/mailman/listinfo/scipy-dev > > > Hi Arnd, > > Thank you very much for the support of band matrices in scipy. That is > very useful. > BTW, is it possible to convert full matrices to band matrices and vice > versa ? Yes. For an example of the conversion of a full matrix to band see Lib/linalg/tests/test_decomp.py where you find code blocks like # Extract upper bands from symmetric and hermitian band matrices # (for use in dsbevd, dsbevx, zhbevd, zhbevx # and their single precision versions) LDAB = self.KU + 1 self.bandmat_sym = zeros((LDAB, N), dtype=float) self.bandmat_herm = zeros((LDAB, N), dtype=complex) for i in xrange(LDAB): self.bandmat_sym[LDAB-i-1,i:N] = diag(self.sym_mat, i) self.bandmat_herm[LDAB-i-1,i:N] = diag(self.herm_mat, i) HTH, Arnd From arnd.baecker at web.de Fri Jun 30 09:06:37 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 30 Jun 2006 15:06:37 +0200 (CEST) Subject: [SciPy-dev] eig_banded In-Reply-To: <44A51811.2000003@iam.uni-stuttgart.de> References: <44A51811.2000003@iam.uni-stuttgart.de> Message-ID: On Fri, 30 Jun 2006, Nils Wagner wrote: > Eigenvalues and Decompositions: > > eig --- Find the eigenvalues and vectors of a square matrix > eigvals --- Find the eigenvalues of a square matrix > lu --- LU decomposition of a matrix > lu_factor --- LU decomposition returning unordered matrix and pivots > lu_solve --- solve Ax=b using back substitution with output of > lu_factor > svd --- Singular value decomposition of a matrix > svdvals --- Singular values of a matrix > diagsvd --- construct matrix of singular values from output of svd > orth --- construct orthonormal basis for range of A using svd > cholesky --- Cholesky decomposition of a matrix > cho_factor --- Cholesky decomposition for use in solving linear > system > cho_solve --- Solve previously factored linear system > qr --- QR decomposition of a matrix > schur --- Schur decomposition of a matrix > rsf2csf --- Real to complex schur form > hessenberg --- Hessenberg form of a matrix > > An entry for eig_banded is missing. I added: eig_banded --- Find the eigenvalues and vectors of a band matrix eigvals_banded --- Find the eigenvalues of a band matrix BTW:. what is the convention here about the formatting? eig_banded fits (same length as hessenberg), but eigvals_banded is too long? Best, Arnd From arnd.baecker at web.de Fri Jun 30 09:06:37 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 30 Jun 2006 15:06:37 +0200 (CEST) Subject: [SciPy-dev] eig_banded In-Reply-To: <44A51811.2000003@iam.uni-stuttgart.de> References: <44A51811.2000003@iam.uni-stuttgart.de> Message-ID: On Fri, 30 Jun 2006, Nils Wagner wrote: > Eigenvalues and Decompositions: > > eig --- Find the eigenvalues and vectors of a square matrix > eigvals --- Find the eigenvalues of a square matrix > lu --- LU decomposition of a matrix > lu_factor --- LU decomposition returning unordered matrix and pivots > lu_solve --- solve Ax=b using back substitution with output of > lu_factor > svd --- Singular value decomposition of a matrix > svdvals --- Singular values of a matrix > diagsvd --- construct matrix of singular values from output of svd > orth --- construct orthonormal basis for range of A using svd > cholesky --- Cholesky decomposition of a matrix > cho_factor --- Cholesky decomposition for use in solving linear > system > cho_solve --- Solve previously factored linear system > qr --- QR decomposition of a matrix > schur --- Schur decomposition of a matrix > rsf2csf --- Real to complex schur form > hessenberg --- Hessenberg form of a matrix > > An entry for eig_banded is missing. I added: eig_banded --- Find the eigenvalues and vectors of a band matrix eigvals_banded --- Find the eigenvalues of a band matrix BTW:. what is the convention here about the formatting? eig_banded fits (same length as hessenberg), but eigvals_banded is too long? Best, Arnd From nwagner at iam.uni-stuttgart.de Fri Jun 30 09:07:01 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 30 Jun 2006 15:07:01 +0200 Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: References: <44A37153.5010200@ieee.org> <44A516EF.6080405@iam.uni-stuttgart.de> Message-ID: <44A521F5.9030800@iam.uni-stuttgart.de> Arnd Baecker wrote: > On Fri, 30 Jun 2006, Nils Wagner wrote: > > >> Arnd Baecker wrote: >> >>> On Thu, 29 Jun 2006, Travis Oliphant wrote: >>> >>> >>> >>>> Arnd Baecker wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> sorry for asking again, but I would really be happy >>>>> to get this finished... >>>>> >>>>> Travis, Robert or Pearu: may I go ahead with integrating >>>>> the band matrix wrappers into scipy svn? >>>>> >>>>> >>>>> >>>> I say go ahead. It looks like an additional feature with a reasonable >>>> interface that should not affect other code. >>>> >>>> >>> Many thanks, code is commited. All tests pass without problems. >>> >>> Best, Arnd >>> _______________________________________________ >>> Scipy-dev mailing list >>> Scipy-dev at scipy.org >>> http://projects.scipy.org/mailman/listinfo/scipy-dev >>> >>> >> Hi Arnd, >> >> Thank you very much for the support of band matrices in scipy. That is >> very useful. >> BTW, is it possible to convert full matrices to band matrices and vice >> versa ? >> > > Yes. > For an example of the conversion of a full matrix to band > see Lib/linalg/tests/test_decomp.py > where you find code blocks like > > # Extract upper bands from symmetric and hermitian band matrices > # (for use in dsbevd, dsbevx, zhbevd, zhbevx > # and their single precision versions) > LDAB = self.KU + 1 > self.bandmat_sym = zeros((LDAB, N), dtype=float) > self.bandmat_herm = zeros((LDAB, N), dtype=complex) > for i in xrange(LDAB): > self.bandmat_sym[LDAB-i-1,i:N] = diag(self.sym_mat, i) > self.bandmat_herm[LDAB-i-1,i:N] = diag(self.herm_mat, i) > > HTH, > > Arnd > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > Did you check general band matrices ? If you need a test for real nonsymmetric band matrices from scipy import linalg, diag, arange, linspace, sort def sylvester(n): # # Sylvester matrix # tmp = diag(arange(1,n),1)+diag(arange(n-1,0,-1),-1) return tmp n = 9 A = sylvester(n) w1=linalg.eigvals(A) w1=sort(w1.real) # # Exact eigenvalues # w_ex = linspace(-(n-1),n-1,n,endpoint=True) print linalg.norm(w1-w_ex) Nils From arnd.baecker at web.de Fri Jun 30 09:25:24 2006 From: arnd.baecker at web.de (Arnd Baecker) Date: Fri, 30 Jun 2006 15:25:24 +0200 (CEST) Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: <44A521F5.9030800@iam.uni-stuttgart.de> References: <44A37153.5010200@ieee.org> <44A516EF.6080405@iam.uni-stuttgart.de> <44A521F5.9030800@iam.uni-stuttgart.de> Message-ID: On Fri, 30 Jun 2006, Nils Wagner wrote: [...] > Did you check general band matrices ? No. > If you need a test for real nonsymmetric band matrices Not this time - the wrapped routines are for symmetric or Hermetian routines only. > from scipy import linalg, diag, arange, linspace, sort > def sylvester(n): > # > # Sylvester matrix > # > tmp = diag(arange(1,n),1)+diag(arange(n-1,0,-1),-1) > return tmp > > n = 9 > A = sylvester(n) > w1=linalg.eigvals(A) > w1=sort(w1.real) > # > # Exact eigenvalues > # > w_ex = linspace(-(n-1),n-1,n,endpoint=True) > print linalg.norm(w1-w_ex) > > Nils > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > > From nwagner at iam.uni-stuttgart.de Fri Jun 30 09:36:17 2006 From: nwagner at iam.uni-stuttgart.de (Nils Wagner) Date: Fri, 30 Jun 2006 15:36:17 +0200 Subject: [SciPy-dev] band matrix wrapping ready for inclusion In-Reply-To: References: <44A37153.5010200@ieee.org> <44A516EF.6080405@iam.uni-stuttgart.de> <44A521F5.9030800@iam.uni-stuttgart.de> Message-ID: <44A528D1.40004@iam.uni-stuttgart.de> Arnd Baecker wrote: > On Fri, 30 Jun 2006, Nils Wagner wrote: > > [...] > > >> Did you check general band matrices ? >> > > No. > > >> If you need a test for real nonsymmetric band matrices >> > > Not this time - the wrapped routines are for symmetric or > Hermetian routines only. > > >> from scipy import linalg, diag, arange, linspace, sort >> def sylvester(n): >> # >> # Sylvester matrix >> # >> tmp = diag(arange(1,n),1)+diag(arange(n-1,0,-1),-1) >> return tmp >> >> n = 9 >> A = sylvester(n) >> w1=linalg.eigvals(A) >> w1=sort(w1.real) >> # >> # Exact eigenvalues >> # >> w_ex = linspace(-(n-1),n-1,n,endpoint=True) >> print linalg.norm(w1-w_ex) >> >> Nils >> >> _______________________________________________ >> Scipy-dev mailing list >> Scipy-dev at scipy.org >> http://projects.scipy.org/mailman/listinfo/scipy-dev >> >> >> > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > OK, do you intend to add support for non-hermitian matrices in the near future ? eig_banded(a_band, lower=0, eigvals_only=0, overwrite_a_band=0, select='a', select_range=None, max_ev=0) Solve real symmetric or complex hermetian band matrix problem. eigvals_banded(a_band, lower=0, overwrite_a_band=0, select='a', select_range=None) Return eigenvalues of hermitean or real symmetric matrix. It should be Hermitian instead of hermetian/hermitean ;-) http://en.wikipedia.org/wiki/Hermitian_matrix Nils From bart.vandereycken at cs.kuleuven.be Fri Jun 30 10:25:21 2006 From: bart.vandereycken at cs.kuleuven.be (Bart Vandereycken) Date: Fri, 30 Jun 2006 16:25:21 +0200 Subject: [SciPy-dev] QR factorization: modifications Message-ID: Hi all, I've modified the QR routine in scipy.linalg.qr in 3 ways, to make it faster and more compatible with Matlab. This is my first patch so any feedback is appreciated... you can find the files here: http://www.cs.kuleuven.be/~bartvde/scipy/ 1) The original method used only one LAPACK-routine (GEQRF) to compute the R factor, but NOT the (xORGQR and xUNGQR) to compute the Q factor. This is a huge efficiency loss, see the figure at my site for a comparison of the old and new qr method. I included the 2 LAPACK-wrappers in patch_flapack.diff and the new qr method in patch_qr.diff. (I don't use clapack, so I can't test this.) The old qr method is still available as qr_old in case you want to compare the results, use test_qr.py ;-) 2) You can compute economy-sized (as Matlab calls it) or skinny QR factorizations for tall matrices (more rows than cols). The performance gain should be obvious now. 3) If you only want the R factor and not the Q, the method stops early and is 2 times faster. Testing for test_decompy.py is included in patch_test.diff. There are 2 new parameters for scipy.decomp.qr: econ=False: economy size or not -> Matlab's qr(A,0) mode='qr': 'qr' or 'r' (or 'qre', qr with Givens rotations, maybe I'll do this later) -> Matlab's Q,R=qr(A) or R=qr(A) or Q,R,E=qr(A) Bart From kwgoodman at gmail.com Fri Jun 30 11:39:01 2006 From: kwgoodman at gmail.com (Keith Goodman) Date: Fri, 30 Jun 2006 08:39:01 -0700 Subject: [SciPy-dev] QR factorization: modifications In-Reply-To: References: Message-ID: On 6/30/06, Bart Vandereycken wrote: > I've modified the QR routine in scipy.linalg.qr in 3 ways, to make it > faster and more compatible with Matlab. > > This is my first patch so any feedback is appreciated... you can find > the files here: http://www.cs.kuleuven.be/~bartvde/scipy/ The plot of the speed up is impressive. From travis at enthought.com Fri Jun 30 16:59:20 2006 From: travis at enthought.com (Travis N. Vaught) Date: Fri, 30 Jun 2006 15:59:20 -0500 Subject: [SciPy-dev] ANN: SciPy 2006 Conference Reminder Message-ID: <44A590A8.5040705@enthought.com> The *SciPy 2006 Conference* is scheduled for Thursday and Friday, August 17-18, 2006 at CalTech with Sprints and Tutorials Monday-Wednesday, August 14-16. Conference details are at http://www.scipy.org/SciPy2006 The deadlines for submitting abstracts and early registration are approaching... Call for Presenters ------------------- If you are interested in presenting at the conference, you may submit an abstract in Plain Text, PDF or MS Word formats to abstracts at scipy.org -- the deadline for abstract submission is July 7, 2006. Papers and/or presentation slides are acceptable and are due by August 4, 2006. Registration: ------------- Early registration ($100.00) is still available through July 14. You may register online at http://www.enthought.com/scipy06. Registration includes breakfast and lunch Thursday & Friday and a very nice dinner Thursday night. After July 14, 2006, registration will cost $150.00. Tutorials and Sprints --------------------- This year the Sprints (Monday and Tuesday, August 14-15) and Tutorials (Wednesday, August 16) are no additional charge (you're on your own for food on those days, though). Remember to include these days in your travel plans. The following topics are presented as Tutorials Wednesday (more info here: http://www.scipy.org/SciPy2006/TutorialSessions): - "3D visualization in Python using tvtk and MayaVi" - "Scientific Data Analysis and Visualization using IPython and Matplotlib." - "Building Scientific Applications using the Enthought Tool Suite (Envisage, Traits, Chaco, etc.)" - "NumPy (migration from Numarray & Numeric, overview of NumPy)" The Sprint topics are under discussion here: http://www.scipy.org/SciPy2006/CodingSprints See you in August! Travis