[J3] Why is += missing?

Thu Aug 26 14:34:48 UTC 2021

I guess my question is, nowadays who are these monolingual Fortran programmers?  I have tried to teach the language for a long time and very few of the students haven’t at least used some other language.  It’s generally not C or C++, it’s increasingly likely to be Python, which does support these operators.   Others have learned some C++ or perhaps Java at some point though they are rarely fluent.  Students generally learn any programming language not because they want to, but because they have to.  In the case of students who have done at least some of a computer-science curriculum then obviously they will be taught C++.  I find that a lot of scientific/engineering labs try to hire CS students to write code for them, or they use Python even when some other language, like Fortran, would be better, because most of the science and engineering researchers I’ve encountered avoid any compiled language if they possibly can.

There’s been a little movement to Julia, which also supports the combo operators, though I am dubious it will ever achieve anywhere near the success of Python, which is something of a pity since Python is really, really slow (though R is usually worse).

Fields that don’t have a legacy of Fortran use, like bioinformatics, aren’t taking it up at all.  Their underlying compiled code, if they have any, is C++.

Fortran programmers who don’t know C/C++/Python/Julia don’t have to use the operators.  I find the suggestion of ASSOCIATE to be far less obvious.  It’s a new feature, so all those aging monolinguals probably don’t know about it.  It also introduces a cognitive load in that I would have to remember what is associated with what.  It also adds two or more lines of code every time I just want to increment something.  Just FYI, the two monolingual researchers I know about through my institution (one has left) insist on using *Fortran 77*.  They won’t even learn array operations.

That said, among engineers and to a lesser extent scientists, Matlab is still quite popular, though Python is making inroads.  For other fields R is dominant.  Neither of those supports the arithmetic-assignment operators.  Mathworks apparently has some argle bargle about that being because it’s array based (but += works fine for Python numpy arrays).  I suspect it’s not a coincidence that the two interpreted languages that (as far as I know) were originally written in Fortran, and still use 1-based arrays and column-major ordering, don’t provide operators that Fortran didn’t support.  There are similar complaints about their absence in those languages.  (I did see requests for ++ in Matlab and I don’t see that operator used a whole lot outside of C-style for loops, and I’ve seen quite a bit of C/C++ code.  Python doesn’t have ++ or – either.)

And /= does create a problem.  I do not know why /= was chosen (of course it does resemble the mathematical =/= symbol).  Matlab uses ~= .

Katherine Holcomb
UVA Research Computing  https://www.rc.virginia.edu
kah3f at virginia.edu<mailto:kah3f at virginia.edu>    434-982-5948

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Malcolm Cohen via J3
Sent: Wednesday, August 25, 2021 10:48 PM
To: 'General J3 interest list' <j3 at mailman.j3-fortran.org>
Cc: Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] Why is += missing?

Well, I don’t like it.

Below are some reasons and comments. Perhaps not overly compelling, but they are, I think, quite valid reasons for not doing this.

A: It bloats the language with extra (and un-Fortran-like) syntax. There is a cognitive load associated with the size of a language.

B: Then there’s the “why not operator= for all operators”. Doing that would change it from a smallish feature into a largish feature (quite apart from the ambiguity with /=). Not doing that would result in C-familiar user annoyance when the “obvious” things did not work.

C: It is not self-explanatory at all; many Fortran users are not familiar with C or C++.

D: As noted by someone else, it is not the same as X = X + expr, because the compiler can evaluate any mathematical equivalent to “X+expr”, and that is lost with the “obvious” semantics of “add expr to X”. With FMA and similar being quite popular these days, I’d expect some but not all compilers would violate those semantics at least some of the time by turning it back into X=X+expr (to avoid losing performance and accuracy). That’s a recipe for reduced portability.

E: The density of “+=” and friends in C code is not necessarily a good indication of how widely used it would be in Fortran. Quite apart from some uses of += being trivial (N=N+2 is certainly not less readable than N+=2), and some already being handled by ASSOCIATE as previously mentioned, some cases might be covered by a totally different Fortran feature, for example the SUM intrinsic.

F: For that matter, “++” is likely widely used in C codes. That does not mean it would be a good fit for Fortran.

For me, “B” by itself is sufficient to make this not worthwhile.

Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> On Behalf Of Damian Rouson via J3
Sent: Thursday, August 26, 2021 8:47 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Damian Rouson <damian at sourceryinstitute.org<mailto:damian at sourceryinstitute.org>>
Subject: Re: [J3] Why is += missing?

On Wed, Aug 25, 2021 at 6:27 AM Jeff Hammond via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:
I will argue that it is syntactic sugar in the same sense that multidimensional arrays are.  Below is the perfectly functional C code I wrote to match my Fortran years ago (because computer scientists don’t know their history).  There is no actual need for multidimensional arrays in Fortran, just the practical difficulty of not having them.

// t3(h3,h2,h1,p6,p5,p4)+=t1(p4,h1)*v2(h3,h2,p6,p5);
t3[h3+h3u*(h2+h2u*(h1+h1u*(p6+p6u*(p5+p5u*p4))))] += t1[p4+p4u*h1] * v2[h3+h3u*(h2+h2u*(p6+p6u*p5))];

Jeff,

If I'm interpreting the responses accurately, it sounds like the idea simply fell too far down the list of priorities, but I haven't heard any fundamental resistance modulo syntax. Hopefully that's encouraging.

Is the provided C code really so short or were the nested for loops omitted for the sake of brevity?

Damian

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: 30 St. Giles, Oxford, OX1 3LE, United Kingdom. Please see our Privacy Notice<https://www.nag.co.uk/content/privacy-notice> for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210826/5cb607b2/attachment-0001.htm>