Skip to content

BUG: f2py incorrectly translates dimension declarations - part 2. #17687

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

Closed

Conversation

ianthomas23
Copy link
Contributor

Corrections to PR gh-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 gh-8062.

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.
@@ -2178,14 +2181,10 @@ def getlincoef(e, xset): # e = a*x+b ; x in xset
c2 = myeval(ee, {}, {})
if (a * 0.5 + b == c and a * 1.5 + b == c2):
# gh-8062: return integers instead of floats if possible.
try:
if a.is_integer():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will fail if a is an integer; the same holds for b.

Suggested change
if a.is_integer():
if isinstance(a, float) and a.is_integer():
In [8]: int().is_integer()
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-8-d4bbeabb52a2> in <module>
----> 1 int().is_integer()

AttributeError: 'int' object has no attribute 'is_integer'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And what's supposed to happen here if a.is_integer() evaluates to False?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that int.is_integer actually does exist in newer versions of python.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a new feature planned for 3.10?
On both 3.8 and 3.9 I'm just getting an AttributeError.

@ianthomas23
Copy link
Contributor Author

I am inclined to shelve this PR. If I implement @BvB93's very sensible suggestion then segfaults occur at the end of running the tests or simple standalone examples, and this makes no sense to me. I had categorised the original bug as low-hanging fruit requiring a small localised change, but it has become clear that the situation is much more complicated than this (or at least much more complicated than my understanding of it). The more I look at it, the worse it gets. Two examples: (1) the line

if (a * 0.5 + b == c and a * 1.5 + b == c2):

which controls access to the code fix and the return from getlincoef contains floating point comparisons without any tolerances which is code I assume you wouldn't consider accepting nowadays, and (2) the lack of comprehensive testing of crackfortran.py means I cannot be sure of the impact that any changes made will have on other use cases that aren't explicitly tested.

Hence I am inclined to close this PR as the issue needs further consideration, probably involving a fuller understanding and possible rewrite of getlincoef. Under normal circumstances I would simply close this PR, but as the previous erroneous PR (gh-17654) has already been merged then those changes need to be reverted, ideally before the next numpy release. The best I can think of doing here is to write another PR than undoes gh-17654.

@mattip mattip added the triage review Issue/PR to be discussed at the next triage meeting label Nov 4, 2020
@mattip
Copy link
Member

mattip commented Nov 4, 2020

In a triage review we discussed this. It seems the safe thing to do is to back out gh-17654. The tests here should pass on the old code, right? If so it would be good to keep them.

@mattip mattip removed the triage review Issue/PR to be discussed at the next triage meeting label Nov 4, 2020
@ianthomas23
Copy link
Contributor Author

@mattip The tests need to be removed too, a complete reversal of gh-17654 is required. Do you want me to write a PR to do this?

@mattip
Copy link
Member

mattip commented Nov 5, 2020

Yes please.

@mattip
Copy link
Member

mattip commented Nov 5, 2020

Hopefully we can revisit this after the 1.20 release and do a complete fix

@ianthomas23
Copy link
Contributor Author

Reverting PR submitted (gh-17715). If that is OK, this PR can be closed and the original issue (gh-8062) re-opened.

Base automatically changed from master to main March 4, 2021 02:05
@ianthomas23 ianthomas23 closed this Jul 8, 2021
@ianthomas23 ianthomas23 deleted the 8062_f2py_dimension_eval_2 branch July 8, 2021 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

f2py incorrectly translate dimension declaration
5 participants