[Numpy-discussion] ANN: NumPy 1.6.2 release candidate 1

Paul Anton Letnes paul.anton.letnes at gmail.com
Tue May 15 01:51:01 EDT 2012


On Mon, May 14, 2012 at 9:47 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Sun, May 13, 2012 at 1:14 PM, Paul Anton Letnes
> <paul.anton.letnes at gmail.com> wrote:
>>
>> On Sat, May 12, 2012 at 9:50 PM, Ralf Gommers
>> <ralf.gommers at googlemail.com> wrote:
>> >
>> >
>> > On Sun, May 6, 2012 at 12:12 AM, Charles R Harris
>> > <charlesr.harris at gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> On Sat, May 5, 2012 at 2:56 PM, Paul Anton Letnes
>> >> <paul.anton.letnes at gmail.com> 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



More information about the NumPy-Discussion mailing list