Re: [Numpy-discussion] Calling routines from a Fortran library using python
On Mon, 22 Feb 2010 22:18:23 +0900
David Cournapeau courn...@gmail.com wrote:
On Mon, Feb 22, 2010 at 10:01 PM, Nils Wagner
nwag...@iam.uni-stuttgart.de wrote:
ar x test.a
gfortran -shared *.o -o libtest.so -lg2c
to build a shared library. The additional option -lg2c
was
necessary due to an undefined symbol: s_cmp
You should avoid the -lg2c option at any cost if
compiling with
gfortran. I am afraid that you got a library compiled
with g77. If
that's the case, you should use g77 and not gfortran.
You cannot mix
libraries built with one with libraries with another.
Now I am able to load the shared library
from ctypes import *
my_lib = CDLL('test.so')
What are the next steps to use the library functions
within python ?
You use it as you would use a C library:
http://python.net/crew/theller/ctypes/tutorial.html
But the fortran ABI, at least for code built with g77
and gfortran,
pass everything by reference. To make sure to pass the
right
arguments, I strongly suggest to double check with the
.h you
received.
cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Just to play it safe
Consider
extern void dsio(int* const,const char* const,
int* const,const size_t);
extern void dsrhed (const int* const,const int*
const,void* const,
const int* const,const int* const,int* const,
int* const,int* const,int* const,int* const,
int* const,int* const,int* const);
from ctypes import *
my_lib = CDLL('libtest.so')
How do I call the functions within python
I mean what arguments are needed ?
my_lib.dsio()
my_lib.dsrhed( )
Thank you very much for your help.
Cheers,
Nils
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] random.uniform documentation bug?
This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] double free or corruption after calling a Slicot routine wrapped with f2py
hello,
first of all, as i'm new here, i would like to greet everyone in the list and
thank the developers of numpy/scipy. i'm transitioning my work from matlab to
python and this software is very helpfull indeed.
the reason i'm writing is that i got to a stumbling block last week. i tried
wrote some wrappers of Slicot routines aided by f2py that i keep on github
(http://github.com/avventi/Slycot).
the latest routine i tried to wrap, SB02OD, make python to crash with the glibc
error double free or corruption. precisely i get this error if the wrapper
slycot.sb02od is called within a method, i.e
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
import slycot
slycot.examples.sb02od_example()
--- Example for sb01od ...
The solution X is
[[ 1. 0.]
[ 0. 2.]]
rcond = 0.632455532034
*** glibc detected *** python: double free or corruption (!prev): 0x082ec3b8 ***
as you can see the routine does indeed return the correct output but make
python crash afterwards. On the other hand if i type ieach step interactively
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
from numpy import *
import slycot
A = array([[0,1],[0,0]])
B = array([[0],[1]])
C = array([[1,0],[0,1],[0,0]])
Q = dot(C.T,C)
R = zeros((1,1))
L = zeros((2,1))
out = slycot.sb02od('D',2,1,3,A,B,Q,R,L)
out[1]
array([[ 1., 0.],
[ 0., 2.]])
out[0]
0.63245553203367577
out = slycot.sb02od('D',2,1,3,A,B,Q,R,L)
*** glibc detected *** python: double free or corruption (!prev): 0x0832b428 ***
it works the first time but not the second. i tried Debian lenny 32/64bit and a
virtualized Fedora 12 32bit and the error persists.
do you have any ideas why this happens or where should i look to start solving
it?
thanks in advance.
regards,
/Enrico
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] SciPy2010 Call for Papers
== SciPy 2010 Call for Papers == SciPy 2010, the 9th Python in Science Conference, will be held from June 28th - July 3rd, 2010 in Austin, Texas. At this conference, novel applications and breakthroughs made in the pursuit of science using Python are presented. Attended by leading figures from both academia and industry, it is an excellent opportunity to experience the cutting edge of scientific software development. The conference is preceded by two days of paid tutorials, during which community experts provide training on several scientific Python packages. We invite you to take part by submitting a talk abstract on the conference website at: http://conference.scipy.org Talk/Paper Submission = We solicit talks and accompanying papers (either formal academic or magazine-style articles) that discuss topics regarding scientific computing using Python, including applications, teaching, development and research. Papers are included in the peer-reviewed conference proceedings, published online. Please note that submissions primarily aimed at the promotion of a commercial product or service will not be considered. Important dates for authors include: * 11 April: Talk abstracts due * 20 April: Notification of acceptance * 13 June: Papers due * 15 August: Publication of proceedings Further detail will be made available on http://conference.scipy.org Conference Dates * Friday, 10 May: Early registration ends * Monday-Tuesday, 28-29 June: Tutorials * Wednesday-Thursday, June 30-July 1: Conference * Friday-Saturday, July 2-3: Coding Sprints Executive Committee === * Conference: Jarrod Millman Eric Jones * Program: Stefan van der Walt Ondrej Certik * Student Sponsorship: Travis Oliphant For more information on Python, visit http://www.python.org. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 6:21 AM, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is Why do you assume that? DG the documentation that is in error (for the case when high=low)? fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. Well, an exception isn't the only option (e.g., it could return NaN), but does everyone agree (or at least not block) that this is acceptable behavior? IMO, if this function is going to allow high low, then the doc should _also_ be _quite_ clear that if this feature might mess up the user's program in some way, then the user will have to implement their own safeguard against such parameters being fed to the monster. ;-) DG -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] distutils problem with NumPy-1.4 Py-2.7a3 (Snow Leopard)
Hi- I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will not install; it appears something has changed within distutils that breaks it: $ export MACOSX_DEPLOYMENT_TARGET=10.6 $ export CFLAGS=-arch x86_64 $ export FFLAGS=-m64 $ export LDFLAGS=-Wall -undefined dynamic_lookup -bundle -arch x86_64 $ time python setup.py build --fcompiler=gnu95 Running from numpy source directory. Traceback (most recent call last): File setup.py, line 187, in module setup_package() File setup.py, line 155, in setup_package from numpy.distutils.core import setup File /Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/__init__.py, line 6, in module import ccompiler File /Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/ccompiler.py, line 17, in module _old_init_posix = distutils.sysconfig._init_posix AttributeError: 'module' object has no attribute '_init_posix' I realize NumPy makes no claim to be compatible with 2.7(alpha); I'm reporting this as a heads-up. -Tom PS: For testing purposes: To get nose to install for 2.7a3, you need to use the current hg branch. The last release (including the out-of-date dev branch on PyPI) is not compatible with 2.7 changes to unittest internals. - This mail sent through IMP: http://horde.org/imp/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 13:05, David Goldsmith d.l.goldsm...@gmail.com wrote: On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. Well, an exception isn't the only option (e.g., it could return NaN), shudder but does everyone agree (or at least not block) that this is acceptable behavior? It's a useful feature. Whenever there is a low/high pair of arguments, a user frequently has to write code like so: low, high = min(a, b), max(a, b) just to satisfy the argument spec of the function. This function does not really require knowing which is which for its implementation, so requiring them to be one way is simply arbitrariness for the sake of arbitrariness. IMO, if this function is going to allow high low, then the doc should _also_ be _quite_ clear that if this feature might mess up the user's program in some way, then the user will have to implement their own safeguard against such parameters being fed to the monster. ;-) So do it. But please, don't use frightening terminology like you are here. Just state the fact clearly and succinctly as in the random.uniform() docs. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] distutils problem with NumPy-1.4 Py-2.7a3 (Snow Leopard)
On 02/23/2010 01:18 PM, Tom Loredo wrote: Hi- I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will not install; it appears something has changed within distutils that breaks it: $ export MACOSX_DEPLOYMENT_TARGET=10.6 $ export CFLAGS=-arch x86_64 $ export FFLAGS=-m64 $ export LDFLAGS=-Wall -undefined dynamic_lookup -bundle -arch x86_64 $ time python setup.py build --fcompiler=gnu95 Running from numpy source directory. Traceback (most recent call last): File setup.py, line 187, inmodule setup_package() File setup.py, line 155, in setup_package from numpy.distutils.core import setup File /Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/__init__.py, line 6, inmodule import ccompiler File /Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/ccompiler.py, line 17, inmodule _old_init_posix = distutils.sysconfig._init_posix AttributeError: 'module' object has no attribute '_init_posix' I realize NumPy makes no claim to be compatible with 2.7(alpha); I'm reporting this as a heads-up. -Tom PS: For testing purposes: To get nose to install for 2.7a3, you need to use the current hg branch. The last release (including the out-of-date dev branch on PyPI) is not compatible with 2.7 changes to unittest internals. - This mail sent through IMP: http://horde.org/imp/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Hi, I think it is Python related as I did a grep of my Python versions installed from source for this function and got: python2.5/distutils/sysconfig.py:def _init_posix(): python2.6/distutils/sysconfig.py:def _init_posix(): python2.7/sysconfig.py:def _init_posix(vars): python3.1/distutils/sysconfig.py:def _init_posix(): I have not had time to check why Python2.7 is different from the other versions (both location and call). Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 11:25 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 13:05, David Goldsmith d.l.goldsm...@gmail.com wrote: On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. Well, an exception isn't the only option (e.g., it could return NaN), shudder but does everyone agree (or at least not block) that this is acceptable behavior? It's a useful feature. Whenever there is a low/high pair of arguments, a user frequently has to write code like so: low, high = min(a, b), max(a, b) just to satisfy the argument spec of the function. This function does not really require knowing which is which for its implementation, so requiring them to be one way is simply arbitrariness for the sake of arbitrariness. OK. IMO, if this function is going to allow high low, then the doc should _also_ be _quite_ clear that if this feature might mess up the user's program in some way, then the user will have to implement their own safeguard against such parameters being fed to the monster. ;-) So do it. But please, don't use frightening terminology like you are here. Just state the fact clearly and succinctly as in the random.uniform() docs. Aw shucks, these docstrings are so dry. (Just kidding.) ;-) DG -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy + ubuntu 9.10 (karmic) + unladen swallow
Hi all, After getting the answers above on the maillist I palyed a bit more with building numpy. However without success. Nevertheless I've found the way to install it using unladen-swallow itself :) http://groups.google.com/group/unladen-swallow/browse_thread/thread/80f7ccb68a9dcea3#b015202752197989 So, the question is currently closed for me. Kind regards -- Valery ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
Why not rewriting the definition of uniform() to: def uniform(start, stop, low = None, high = None): if low is not None: start = low if high is not None: stop = high [and here what matters] This makes no trouble when a user uses either non-keyword or keyword specification. The second pair of keywords is just for backward compatibility. As after a keyword there is no positional argument allowed, the only call mixing keywords and non-keywords would be uniform(low, high = high), and this is also maintained. Friedrich 2010/2/23 David Goldsmith d.l.goldsm...@gmail.com: On Tue, Feb 23, 2010 at 11:25 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 13:05, David Goldsmith d.l.goldsm...@gmail.com wrote: On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. Well, an exception isn't the only option (e.g., it could return NaN), shudder but does everyone agree (or at least not block) that this is acceptable behavior? It's a useful feature. Whenever there is a low/high pair of arguments, a user frequently has to write code like so: low, high = min(a, b), max(a, b) just to satisfy the argument spec of the function. This function does not really require knowing which is which for its implementation, so requiring them to be one way is simply arbitrariness for the sake of arbitrariness. OK. IMO, if this function is going to allow high low, then the doc should _also_ be _quite_ clear that if this feature might mess up the user's program in some way, then the user will have to implement their own safeguard against such parameters being fed to the monster. ;-) So do it. But please, don't use frightening terminology like you are here. Just state the fact clearly and succinctly as in the random.uniform() docs. Aw shucks, these docstrings are so dry. (Just kidding.) ;-) DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] distutils problem with NumPy-1.4 Py-2.7a3 (Snow Leopard)
On Tue, Feb 23, 2010 at 13:32, Bruce Southey bsout...@gmail.com wrote: On 02/23/2010 01:18 PM, Tom Loredo wrote: Hi- I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will not install; it appears something has changed within distutils that breaks it: $ export MACOSX_DEPLOYMENT_TARGET=10.6 $ export CFLAGS=-arch x86_64 $ export FFLAGS=-m64 $ export LDFLAGS=-Wall -undefined dynamic_lookup -bundle -arch x86_64 $ time python setup.py build --fcompiler=gnu95 Running from numpy source directory. Traceback (most recent call last): File setup.py, line 187, inmodule setup_package() File setup.py, line 155, in setup_package from numpy.distutils.core import setup File /Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/__init__.py, line 6, inmodule import ccompiler File /Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/ccompiler.py, line 17, inmodule _old_init_posix = distutils.sysconfig._init_posix AttributeError: 'module' object has no attribute '_init_posix' I realize NumPy makes no claim to be compatible with 2.7(alpha); I'm reporting this as a heads-up. -Tom PS: For testing purposes: To get nose to install for 2.7a3, you need to use the current hg branch. The last release (including the out-of-date dev branch on PyPI) is not compatible with 2.7 changes to unittest internals. - This mail sent through IMP: http://horde.org/imp/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Hi, I think it is Python related as I did a grep of my Python versions installed from source for this function and got: python2.5/distutils/sysconfig.py:def _init_posix(): python2.6/distutils/sysconfig.py:def _init_posix(): python2.7/sysconfig.py:def _init_posix(vars): python3.1/distutils/sysconfig.py:def _init_posix(): I have not had time to check why Python2.7 is different from the other versions (both location and call). sysconfig was deemed useful outside of distutils and was promoted to the top level. Unfortunately, they didn't leave a backwards compatibility stub. Feel free to create a bug ticket on the Python bug tracker. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 14:04, Friedrich Romstedt friedrichromst...@gmail.com wrote: Why not rewriting the definition of uniform() to: def uniform(start, stop, low = None, high = None): if low is not None: start = low if high is not None: stop = high [and here what matters] This makes no trouble when a user uses either non-keyword or keyword specification. The second pair of keywords is just for backward compatibility. As after a keyword there is no positional argument allowed, the only call mixing keywords and non-keywords would be uniform(low, high = high), and this is also maintained. Except for someone calling uniform(low, high, size). In any case, why would you make this change? It doesn't seem to solve any problem or clear up any semantics. start and stop imply a stop start relationship, too, albeit not as strongly. If someone wants to pass in a high low, let them. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
Except for someone calling uniform(low, high, size). Ah, sorry, I didn't know about that. In that case, everything I wrote is superfluous and I apologise for a non-helping comment. But, one could incorporate SIZE simply in the calling convention. In any case, why would you make this change? It doesn't seem to solve any problem or clear up any semantics. start and stop imply a stop start relationship, too, albeit not as strongly. Hmm, I thought that start is where the thing starts, and stop where it stops, so it's in virtual time stop start, but it can travel downwards. I thought it would help making the semantics more clear. But I see it depends on interpretation. With low and high, my interpretation is on the contrary impossible. The ugly doubling was just intended for compatibility, resulting in a note for backward compatibility reasons, you can also pass ... or something like that. If someone wants to pass in a high low, let them. It's possible, of course. Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 14:26, Friedrich Romstedt friedrichromst...@gmail.com wrote: In any case, why would you make this change? It doesn't seem to solve any problem or clear up any semantics. start and stop imply a stop start relationship, too, albeit not as strongly. Hmm, I thought that start is where the thing starts, and stop where it stops, so it's in virtual time stop start, but it can travel downwards. I thought it would help making the semantics more clear. It helps a little, I agree, but not as much as simply changing the names to something neutral like (a, b) as in the standard library. The necessity for a backwards compatibility hack imposes additional costs to making any such change. I don't think those costs are warranted by the semantic confusion of allowing high low. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
2010/2/23 Robert Kern robert.k...@gmail.com: It helps a little, I agree, but not as much as simply changing the names to something neutral like (a, b) as in the standard library. The necessity for a backwards compatibility hack imposes additional costs to making any such change. I don't think those costs are warranted by the semantic confusion of allowing high low. I agree fully. The (a, b) thing is the most elegant. And I also agree that the overhead renders it nearly useless, when one focuses on speed. Sorry for making noise again with an unmature thought. It just came into my mind and looked so cute ... :-( Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 14:51, Friedrich Romstedt friedrichromst...@gmail.com wrote: 2010/2/23 Robert Kern robert.k...@gmail.com: It helps a little, I agree, but not as much as simply changing the names to something neutral like (a, b) as in the standard library. The necessity for a backwards compatibility hack imposes additional costs to making any such change. I don't think those costs are warranted by the semantic confusion of allowing high low. I agree fully. The (a, b) thing is the most elegant. And I also agree that the overhead renders it nearly useless, when one focuses on speed. Sorry for making noise again with an unmature thought. It just came into my mind and looked so cute ... :-( No worries! I'm not trying to discourage you from posting half-baked thoughts. They're often correct! -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
2010/2/23 Robert Kern robert.k...@gmail.com: No worries! I'm not trying to discourage you from posting half-baked thoughts. They're often correct! Thank you :-) *smiling and laughing* ! Friedrich P.S.: But my reply obviously does no longer belong to the mailing list ... ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 1:02 PM, Friedrich Romstedt friedrichromst...@gmail.com wrote: 2010/2/23 Robert Kern robert.k...@gmail.com: No worries! I'm not trying to discourage you from posting half-baked thoughts. They're often correct! Thank you :-) *smiling and laughing* ! Friedrich P.S.: But my reply obviously does no longer belong to the mailing list ... For better or worse, institutional memory, be it baked, half-baked, or raw, is best preserved. :-) DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
Incidentally, I noted the following in the discussion, but since those don't get as much viewership (and since I'm about to edit the docstring anyway): presently, the Example in uniform's docstring generates a plot using matplotlib.pyplot - is generating a plot really consistent w/ the spirit of wanting our examples to pass automated testing? DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
OK, fixed in Wiki. ( OK to apply set to Yes) DG On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] datetime uses API deprecated in python3.1
On Feb 23, 2010, at 1:03 AM, Charles R Harris wrote:
On Mon, Feb 22, 2010 at 2:06 PM, Pauli Virtanen p...@iki.fi wrote:
ma, 2010-02-22 kello 14:01 -0700, Charles R Harris kirjoitti:
On Mon, Feb 22, 2010 at 1:58 PM, Robert Kern robert.k...@gmail.com
wrote:
[clip]
Why? PyCObjects don't serialize at all. They would never show
up in
a pickle to begin with.
So what happens to them? I'm not that familiar with pickles
arraydescr_reduce pulls out the datetime info from the metadata dict,
and converts it to a tuple containing something pickleable. And
everything in reverse in *_setstate
Everything works except the import of the {ufunc, multiarray} api's
from the modules. If the api's are stored as PyCObjects then all the
tests pass. I'll try to get that last bit fixed up tomorrow.
Just back from PyCon. It is useful to know that the Python core team
feels that NumPy porting to 3k is a *big* deal.
Lots of people would be interested in your experiences with porting
NumPy to Python 3k. In particular, the fact that they removed APIs
and the extra pain that causes is useful information in their decision
making.
I'm not sure how big a deal it is that we have to change the API to
handle PyCapsules instead of PyCObjects, but if you have any feedback
to the python core dev team, they would be interested in hearing it
--- particularly right after PyCon.
-Travis
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
--
Travis Oliphant
Enthought Inc.
1-512-536-1057
http://www.enthought.com
oliph...@enthought.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] distutils problem with NumPy-1.4 Py-2.7a3 (Snow Leopard)
On Tue, Feb 23, 2010 at 13:18, Tom Loredo lor...@astro.cornell.edu wrote: Hi- I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will not install; it appears something has changed within distutils that breaks it: File /Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/ccompiler.py, line 17, in module _old_init_posix = distutils.sysconfig._init_posix AttributeError: 'module' object has no attribute '_init_posix' This line is actually unused. You may delete it. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] datetime uses API deprecated in python3.1
On Tue, Feb 23, 2010 at 3:40 PM, Travis Oliphant oliph...@enthought.comwrote:
On Feb 23, 2010, at 1:03 AM, Charles R Harris wrote:
On Mon, Feb 22, 2010 at 2:06 PM, Pauli Virtanen p...@iki.fi wrote:
ma, 2010-02-22 kello 14:01 -0700, Charles R Harris kirjoitti:
On Mon, Feb 22, 2010 at 1:58 PM, Robert Kern robert.k...@gmail.com
wrote:
[clip]
Why? PyCObjects don't serialize at all. They would never show up in
a pickle to begin with.
So what happens to them? I'm not that familiar with pickles
arraydescr_reduce pulls out the datetime info from the metadata dict,
and converts it to a tuple containing something pickleable. And
everything in reverse in *_setstate
Everything works except the import of the {ufunc, multiarray} api's from
the modules. If the api's are stored as PyCObjects then all the tests pass.
I'll try to get that last bit fixed up tomorrow.
Just back from PyCon. It is useful to know that the Python core team
feels that NumPy porting to 3k is a *big* deal.
Lots of people would be interested in your experiences with porting NumPy
to Python 3k. In particular, the fact that they removed APIs and the extra
pain that causes is useful information in their decision making.
I'm not sure how big a deal it is that we have to change the API to handle
PyCapsules instead of PyCObjects, but if you have any feedback to the python
core dev team, they would be interested in hearing it --- particularly right
after PyCon.
The PyCapsule transition is done, but needs some cleanup. I'm thinking about
the best approach to the latter. I put some functions in compat_py3k.h that
are drop in replacements for our needs, but they hide the improved error
handling of PyCapsule. I'm thinking a better approach might be to use the
replacement functions to bring the error support of PyCObject closer to
PyCapsule. Because the current fix is a bunch of #ifdefs in the code the
substitution could be made bit by bit, rewriting the surrounding code to
support the new error handling.
f2py still needs fixing.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Windows binaries on OS X
On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: Hi David, did you find time to put those Atlas binaries somewhere? I am putting them into numpy subversion as we speak (in vendor: http://svn.scipy.org/svn/numpy/vendor). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] distutils problem with NumPy-1.4 Py-2.7a3 (Snow Leopard)
On Tue, Feb 23, 2010 at 4:47 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 13:18, Tom Loredo lor...@astro.cornell.edu wrote: Hi- I've been testing Python-2.7a3 on Mac OS 10.6.2. NumPy-1.4.0 will not install; it appears something has changed within distutils that breaks it: File /Volumes/System/Users/loredo/Downloads/numpy-1.4.0-OSX/numpy/distutils/ccompiler.py, line 17, in module _old_init_posix = distutils.sysconfig._init_posix AttributeError: 'module' object has no attribute '_init_posix' This line is actually unused. You may delete it. -- Robert Kern Do you want this as a numpy bug report? Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] RHEL 5.3+ build?
Does anyone use/build this stuff on RHEL 5.3+ (x64)? :) Seems not so much. I'd like to use numpy (and PyTables) for a few tasks where it would be much more efficient to have much of the processing performed on the servers generating the data (about 400 systems) than backhauling the huge amount of input data across our WAN around the continent. However, the vast majority of these systems are 64-bit RedHat EL 5.3 and 5.4, and I'm having trouble building numpy 1.3.0 with gcc. I found an RPM for 1.2.0 so that will get me through most of the RD, and I'd rather wait for the next stable release before spending any more time trying to build. But I'm wondering if there's anybody on the team or in the active contributors/users world who is regularly building numpy on various flavors of CentOS/RHEL5.x. Thanks. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Windows binaries on OS X
On Tue, Feb 23, 2010 at 8:52 PM, David Cournapeau courn...@gmail.com wrote: On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: Hi David, did you find time to put those Atlas binaries somewhere? I am putting them into numpy subversion as we speak (in vendor: http://svn.scipy.org/svn/numpy/vendor). Thank you, Are they ok to link to as an update in http://scipy.org/Installing_SciPy/Windows#head-cd37d819e333227e327079e4c2a2298daf625624 the old Atlas is 3.6.0 Josef cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Windows binaries on OS X
On Wed, Feb 24, 2010 at 11:05 AM, josef.p...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:52 PM, David Cournapeau courn...@gmail.com wrote: On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: Hi David, did you find time to put those Atlas binaries somewhere? I am putting them into numpy subversion as we speak (in vendor: http://svn.scipy.org/svn/numpy/vendor). Thank you, Are they ok to link to as an update in http://scipy.org/Installing_SciPy/Windows#head-cd37d819e333227e327079e4c2a2298daf625624 Maybe we should put them also somewhere on the website directly - I am not sure whether it is good idea to download relatively large binaries directly from svn. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Windows binaries on OS X
On Wed, Feb 24, 2010 at 9:52 AM, David Cournapeau courn...@gmail.comwrote: On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: Hi David, did you find time to put those Atlas binaries somewhere? I am putting them into numpy subversion as we speak (in vendor: http://svn.scipy.org/svn/numpy/vendor). Thanks a lot! Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] RHEL 5.3+ build?
On Wed, Feb 24, 2010 at 11:04 AM, David Carmean d...@halibut.com wrote: Does anyone use/build this stuff on RHEL 5.3+ (x64)? :) Seems not so much. I'd like to use numpy (and PyTables) for a few tasks where it would be much more efficient to have much of the processing performed on the servers generating the data (about 400 systems) than backhauling the huge amount of input data across our WAN around the continent. However, the vast majority of these systems are 64-bit RedHat EL 5.3 and 5.4, and I'm having trouble building numpy 1.3.0 with gcc. I found an RPM for 1.2.0 so that will get me through most of the RD, and I'd rather wait for the next stable release before spending any more time trying to build. But I'm wondering if there's anybody on the team or in the active contributors/users world who is regularly building numpy on various flavors of CentOS/RHEL5.x. Please tell us what does not work, and what you did to build numpy before it fails. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] How to test f2py?
Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py It's not py3k compatible... also it doesn't find the f2py2e module even though it has been installed with numpy. ? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 21:51, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py It's not py3k compatible... So make it py3k compatible. also it doesn't find the f2py2e module even though it has been installed with numpy. ? I don't understand this. Error message? -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 22:12, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:51, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py It's not py3k compatible... So make it py3k compatible. It's autoconverted in build/py3k. It is, however, not installed anywhere. also it doesn't find the f2py2e module even though it has been installed with numpy. ? I don't understand this. Error message? Running /usr/bin/python /home/charris/Workspace/numpy.git/numpy/f2py/tests/f77/return_character.py 10 --quiet Traceback (most recent call last): File /home/charris/Workspace/numpy.git/numpy/f2py/tests/f77/return_character.py, line 10, in module import f2py2e ImportError: No module named f2py2e TEST FAILURE (status=1) So the import is wrong. The question is: did this used to work? From the independent f2py2e days, yes. Just change those import lines to from numpy import f2py as f2py2e. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] long(a) vs a.__long__() for scalar arrays
On Wed, Feb 10, 2010 at 3:12 PM, David Cournapeau courn...@gmail.com wrote: Hi, I am a bit puzzled by the protocol for long(a) where a is a scalar array. For example, for a = np.float128(1), I was expecting long(a) to call a.__long__, but it does not look like it is the case. int(a) does not call a.__int__ either. Where does the long conversion happen in numpy for scalar arrays ? For the record, this happens in the PyNumber machinery (the exact C function doing it is longdouble_long in scalarmath module). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to test f2py?
On Tue, Feb 23, 2010 at 9:19 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 22:12, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:54 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:51, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Feb 23, 2010 at 8:31 PM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 21:14, Charles R Harris charlesr.har...@gmail.com wrote: Hi All, I've made PyCObject - PyCapsule changes to f2py for python3.1. How can I check that f2py still works as advertised before making a commit? numpy/f2py/tests/run_all.py It's not py3k compatible... So make it py3k compatible. It's autoconverted in build/py3k. It is, however, not installed anywhere. also it doesn't find the f2py2e module even though it has been installed with numpy. ? I don't understand this. Error message? Running /usr/bin/python /home/charris/Workspace/numpy.git/numpy/f2py/tests/f77/return_character.py 10 --quiet Traceback (most recent call last): File /home/charris/Workspace/numpy.git/numpy/f2py/tests/f77/return_character.py, line 10, in module import f2py2e ImportError: No module named f2py2e TEST FAILURE (status=1) So the import is wrong. The question is: did this used to work? From the independent f2py2e days, yes. Just change those import lines to from numpy import f2py as f2py2e Boy, that code is *old*, it still uses Numeric ;) I don't think it can really be considered a test suite, it needs lotsa love and it needs to get installed. Anyway, f2py with py3k turns out to have string problems, and I expect other type problems, so there is considerable work that needs to be done to bring it up to snuff. Sounds like gsoc material. I'm not going to worry about it any more until later. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Building Windows binaries on OS X
On Wed, Feb 24, 2010 at 11:19 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Wed, Feb 24, 2010 at 9:52 AM, David Cournapeau courn...@gmail.com wrote: On Mon, Feb 22, 2010 at 11:27 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: Hi David, did you find time to put those Atlas binaries somewhere? I am putting them into numpy subversion as we speak (in vendor: http://svn.scipy.org/svn/numpy/vendor). Thanks a lot! So here is how I see things in the near future for release: - compile a simple binary installer for mac os x and windows (no need for doc or multiple archs) from 1.4.x - test this with the scipy binary out there (running the full test suites), ideally other well known packages as well (matplotlib, pytables, etc...). - if it works for you, or you cannot easily test it, put it for wide testing as a basis for the 1.4.0.1 binary - if it works, make a RC1 for Numpy 1.4.0.1 (full binaries). I think we need to push this ASAP to recover from the current confusion w.r.t. binaries. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
