Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

f2py incorrectly translate dimension declaration #8062

Closed
ChewbaccaKL opened this issue Sep 19, 2016 · 3 comments · Fixed by #17654 or #19805
Closed

f2py incorrectly translate dimension declaration #8062

ChewbaccaKL opened this issue Sep 19, 2016 · 3 comments · Fixed by #17654 or #19805

Comments

@ChewbaccaKL
Copy link

Consider n being an integer and a() is an array The declaration

Integer :: a(0:n/2*2)

is converted into:

a(1.0 * n + 1.0)

which is incorrect. Attaching a minimal Fortran 90 example (zipped because I cannot upload
t1.zip

If, in the attached example, you changed n/2*2 into, say, n, the code would compile correctly.

ianthomas23 added a commit to ianthomas23/numpy that referenced this issue Oct 27, 2020
In fortran functions passed to f2py, calculations that occur in the
dimensions of array declarations are interpreted as floats.  Valid
fortran requires integers.  Problem only occurs with fortran functions
not subroutines as only for the former does f2py generate fortran
wrapper code that fails to compile.

Relevant code is in numpy.f2py.crackfortran.getlincoef(), which
calculates and returns the coefficients to getarrlen() for writing to
the fortran wrapper code.

Fixes numpygh-8062.
ianthomas23 added a commit to ianthomas23/numpy that referenced this issue Nov 1, 2020
Corrections to PR numpygh-17654 following post-merge review.  Fix now only
casts floats to integers if they are definitely integers.  Also,
division that occurs in fortran array declarations is evaluated in an
integer context, so f2py.crackfortran.myeval does the same, converting
single to double slashes.

Fixed numpygh-8062.
ianthomas23 added a commit to ianthomas23/numpy that referenced this issue Nov 5, 2020
@BvB93
Copy link
Member

BvB93 commented Nov 5, 2020

Reopened due to the reversion of #17654 (see #17715).

@BvB93 BvB93 reopened this Nov 5, 2020
@pearu pearu self-assigned this Jun 1, 2021
@pearu
Copy link
Contributor

pearu commented Jun 1, 2021

FYI, I am working on implementing a symbolic engine that will allow evaluating the dimension specifications correctly as well as be used in other places where f2py needs to process Fortran expressions.

charris added a commit that referenced this issue Sep 26, 2021
ENH: Symbolic solver for dimension specifications.
@dibnob44
Copy link

It seems still a #8062bug persists: the original example still fails either from command line 'f2py' or or from python3:>>>numpy.f2py. Note "... python3-numpy is already the newest version (1:1.17.4-5ubuntu3)...."
...
18 | integer a(1.0 * n + 1.0)
| 1
Error: Expression at (1) must be of INTEGER type, found REAL
...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment