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

Paul Anton Letnes paul.anton.letnes at gmail.com
Sun May 13 07:14:33 EDT 2012


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?

Paul



More information about the NumPy-Discussion mailing list