
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

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

On 6/28/06, Arnd Baecker <arnd.baecker@web.de> 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@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev

Tim Leslie wrote:
On 6/28/06, Arnd Baecker <arnd.baecker@web.de> 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

Tim Leslie wrote:
On 6/28/06, Arnd Baecker <arnd.baecker@web.de> 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

On Wed, Jun 28, 2006 at 12:55:22AM -0600, Travis Oliphant wrote:
Tim Leslie wrote:
On 6/28/06, Arnd Baecker <arnd.baecker@web.de> 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

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@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) <unittest.TextTestRunner object at 0xb1fe912c>
scipy.__version__ '0.5.0.2012' numpy.__version__ '0.9.9.2696'

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

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

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

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

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

|| || > || > 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@scipy.net || http://www.scipy.net/mailman/listinfo/scipy-dev ||

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
participants (8)
-
Arnd Baecker
-
Nils Wagner
-
Pearu Peterson
-
Robert Kern
-
Stefan van der Walt
-
Tim Leslie
-
Travis Oliphant
-
Uwe Schmitt