On Mon, May 14, 2012 at 9:47 PM, Ralf Gommers <[email protected]> wrote: > > > 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 >
Looks like it to me! Sorry for the silly bug report. I'll have to take more care next time... Paul _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
