f2py related test, test_kind.py, now works for precision up to and inclu... #289

Open
wants to merge 1 commit into
from

Projects

None yet

3 participants

@pletnes
pletnes commented May 31, 2012

...ding 15 for all compilers (save for the NAG compiler). For gfortran it works for precision up to and including 20.

I suppose the selectedrealkind() function should be rewritten, otherwise f2py might use incorrect kind values for non-gfortran compilers. However, if there is no reliable way of detecting which compiler is being used, there is no way to know what the correct kind values are. An alternative is to not return kind values above 8, or to state more clearly that f2py does not support kinds above 8, or equivalently, selected_real_kind(p) for values p > 15.

I was forced to uninstall and reinstall both ifort and gfortran to run the tests properly. It turned out that the error I got previously was because numpy was very clever at finding my ifort installation, even after I removed the PATH modifications in .bash_profile...

(Some comments are related to an offline discussion with Ralf.)

@pletnes pletnes f2py related test, test_kind.py, now works for precision up to and in…
…cluding 15 for all compilers (save for the NAG compiler). For gfortran it works for precision up to and including 20.
62881ba
@pletnes
pletnes commented May 31, 2012

This gist contains more info on the compiler kind numbers in use by some common compilers:
https://gist.github.com/2767436

@charris
Member
charris commented May 31, 2012

Looks good. It would be nice if the information in the gist could be put somewhere that got more notice. Perhaps numpy needs needs a compiler_oddments directory somewhere to collect together such things.

I've wondered if this test actually indicates something important for the operation of f2py but haven't looked into the matter. I would suspect it is related to the translation of C types to Fortran types.

@pletnes
pletnes commented May 31, 2012

On Thu, May 31, 2012 at 7:47 PM, Charles Harris
reply@reply.github.com
wrote:

Looks good. It would be nice if the information in the gist could be put somewhere that got more notice. Perhaps numpy needs needs a compiler_oddments directory somewhere to collect together such things.

I've wondered if this test actually indicates something important for the operation of f2py but haven't looked into the matter. I would suspect it is related to the translation of C types to Fortran types.

I am thinking out loud here, as I'm not sure of the exact
consequences. Say that a user is compiling his module with ifort and
f2py, and uses
selected_real_kind(16)
in his/her code. Now, the f2py kind number should be 16, since (s)he
is using ifort, but gets 10 instead, since the selectedrealkind
function in f2py returns 10. Now the interface that f2py generates,
and which is subsequently compiled and linked with gcc, does not match
the fortran file compiled with ifort (which gets kind number 16).
Exactly what kind of disaster takes place, I don't know, but it's got
to be something, right?

I am guessing that the problem shows up only very rarely, as few
people use the combination of non-gfortran compilers and 80/128 bit
reals. Come to think of it, I'm not sure it's a good idea to fix the
test. After all, it will in a sense silently fail, thus breaking the
maxim of """
Errors should never pass silently.
Unless explicitly silenced.
"""

The best solution would be to have a compiler-dependent
_selected_real_kind_func function in crackfortran.py. If a reliable
way of detecting the compiler vendor and version can be whipped up,
I'm guessing it's doable. But perhaps something separate has to be
thought up for the C compiler, and this is much more complicated than
what I foresee right here and now.

Cheers
Paul

@charris
Member
charris commented May 31, 2012

This all makes me hesitate to apply the PR since I don't have a good understanding of the consequences. I also think that f2py is lagging a bit as quad precision comes into common use, something that numpy will also need to deal with at some point. Hmm, I'm not sure what the best way forward is at this point.

@pletnes
pletnes commented Jun 1, 2012

On Thu, May 31, 2012 at 11:18 PM, Charles Harris
reply@reply.github.com
wrote:

This all makes me hesitate to apply the PR since I don't have a good understanding of the consequences. I also think that f2py is lagging a bit as quad precision comes into common use, something that numpy will also need to deal with at some point. Hmm, I'm not sure what the best way forward is at this point.


Reply to this email directly or view it on GitHub:
#289 (comment)

Well, this PR only makes a test pass silently. Fundamentally, it does
not fix anything. In my opinion, the correct thing to do (in principle

  • perhaps not so easy in practice) is to make a mechanism for getting
    f2py to understand which compiler and version it is using, and then
    select the kind number from some sort of database - which would have
    to be quite large if one is to cover all the compilers that f2py
    claims to support. I guess one would also have to "crowdsource" the
    effort of getting kind values from all compilers, as I doubt anyone
    has access to every compiler under the sun. But then, I don't
    understand f2py in depth, so maybe this is not the problem I believe
    it to be.

I would suggest adding a note in the f2py manual/tutorials that
precision above 64bit real (C double) is only reliably supported on
gcc+gfortran - if that is indeed the case.

Paul

@charris charris was assigned Mar 2, 2013
@charris
Member
charris commented May 4, 2013

@Dynetrekk Sorry to have lost track of this for so long. On rereading, I think it might be best to limit things to 64 bit real as you suggest, as numpy itself doesn't support quad precision types and extended precision isn't very portable.

@pletnes
pletnes commented May 10, 2013

I'd forgotten about it myself. As you say, advertising for something that isn't really there, is bad form.

@rgommers rgommers added the Maintenance label Mar 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment