On Sun, May 13, 2012 at 1:14 PM, Paul Anton Letnes < [email protected]> wrote:
> On Sat, May 12, 2012 at 9:50 PM, Ralf Gommers > <[email protected]> wrote: > > > > > > On Sun, May 6, 2012 at 12:12 AM, Charles R Harris > > <[email protected]> wrote: > >> > >> > >> > >> On Sat, May 5, 2012 at 2:56 PM, Paul Anton Letnes > >> <[email protected]> wrote: > >>> > >>> Hi, > >>> > >>> I'm getting a couple of errors when testing. System: > >>> Arch Linux (updated today) > >>> Python 3.2.3 > >>> gcc 4.7.0 > >>> (Anything else?) > >>> > >>> I think that this error: > >>> AssertionError: selectedrealkind(19): expected -1 but got 16 > >>> is due to the fact that newer versions of gfortran actually supports > >>> precision this high (quad precision). > >>> > >> > >> Yes, but it should be fixed. I can't duplicate this here with a fresh > >> checkout of the branch. > > > > > > This failure makes no sense to me. > > > > Error comes from this code: > > > > 'selectedrealkind(%s): expected %r but got %r' % (i, > > selected_real_kind(i), selectedrealkind(i))) > > > > So "selected_real_kind(19)" returns -1. > > > > selected_real_kind is the function > > numpy.f2py.crackfortran._selected_real_kind_func, which is defined as: > > > > def _selected_real_kind_func(p, r=0, radix=0): > > #XXX: This should be processor dependent > > # This is only good for 0 <= p <= 20 > > if p < 7: return 4 > > if p < 16: return 8 > > if platform.machine().lower().startswith('power'): > > if p <= 20: > > return 16 > > else: > > if p < 19: > > return 10 > > elif p <= 20: > > return 16 > > return -1 > > > > For p=19 this function should always return 16. So the result from > compiling > > foo.f90 is fine, but the test is broken in a very strange way. > > > > Paul, is the failure reproducible on your machine? If so, can you try to > > debug it? > > > > Ralf > > Hi Ralf. > > The Arch numpy (1.6.1) for python 2.7, installed via pacman (the > package manager) has this problem. > > After installation of numpy 1.6.2rc1 in a virtualenv, the test passes. > Maybe the bug was fixed in the RC, and I screwed up which numpy > version I tested? I'm sorry that I can't find out - I just built a new > machine, and the old one is lying around the livingroom in pieces. Was > that particular bit of code changed between 1.6.1 and 1.6.2rc1? > It was actually, in https://github.com/numpy/numpy/commit/e7f2210e1. So you tested 1.6.1 by accident before, and it's working now? Problem solved in that case. Ralf
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
