fwrap refactor: What about complex -> real?

When faced with Fortran functions expecting a real scalar, f2py will happily accept complex numbers and silently discard the imaginary part. Is this really the preferred behaviour? It would take quite a bit of work to have fwrap behave like that, and I've heard occasional complaints about the behaviour earlier (can't say I'm fond of it myself either). Opinions? (Note that Python implements ".real" on float objects, so the fix is in all cases trivial when this breaks things for people, one just appends ".real" when calling the function, which should also increase the readability of the code.) Dag Sverre

Thu, 09 Dec 2010 20:11:56 +0100, Dag Sverre Seljebotn wrote:
When faced with Fortran functions expecting a real scalar, f2py will happily accept complex numbers and silently discard the imaginary part.
Is this really the preferred behaviour? It would take quite a bit of work to have fwrap behave like that, and I've heard occasional complaints about the behaviour earlier (can't say I'm fond of it myself either).
IMHO, it's not a desired behavior. We are probably working towards addressing this issue in Numpy. Even the idea of disallowing implicit real->complex cast for Numpy 2.0 has been floated around. Personally, I don't see it worthwhile trying to emulate f2py here if it's not trivial. Scipy is not as frozen as Numpy anyway, so I believe changing this would not be a problem.
(Note that Python implements ".real" on float objects, so the fix is in all cases trivial when this breaks things for people, one just appends ".real" when calling the function, which should also increase the readability of the code.)
Yes, this is true. Also in this case explicit is better than implicit. -- Pauli Virtanen

+1 -- (mobile phone of) Travis Oliphant Enthought, Inc. 1-512-536-1057 http://www.enthought.com On Dec 9, 2010, at 2:29 PM, Pauli Virtanen <pav@iki.fi> wrote:
Thu, 09 Dec 2010 20:11:56 +0100, Dag Sverre Seljebotn wrote:
When faced with Fortran functions expecting a real scalar, f2py will happily accept complex numbers and silently discard the imaginary part.
Is this really the preferred behaviour? It would take quite a bit of work to have fwrap behave like that, and I've heard occasional complaints about the behaviour earlier (can't say I'm fond of it myself either).
IMHO, it's not a desired behavior. We are probably working towards addressing this issue in Numpy. Even the idea of disallowing implicit real->complex cast for Numpy 2.0 has been floated around.
Personally, I don't see it worthwhile trying to emulate f2py here if it's not trivial. Scipy is not as frozen as Numpy anyway, so I believe changing this would not be a problem.
(Note that Python implements ".real" on float objects, so the fix is in all cases trivial when this breaks things for people, one just appends ".real" when calling the function, which should also increase the readability of the code.)
Yes, this is true. Also in this case explicit is better than implicit.
-- Pauli Virtanen
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (3)
-
Dag Sverre Seljebotn
-
Pauli Virtanen
-
Travis Oliphant