Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

.not.

JohnNichols
Valued Contributor II
235 Views

Just out of interest, why did Fortran not introduce symbols for .not. etc. as for .eq. 

I prefer the .not. as they are easier remember.  

0 Kudos
4 Replies
Steve_Lionel
Black Belt Retired Employee
228 Views

The short answer is that the committee is loathe to "burn" another character that might need to be used for something else in the future. The comparison operators all use characters already in the Fortran character set.  It DOES happen, and there was a battle over the addition of [] as an alternative to (//) in array constructors (from Sun, which had used [] for intervals.)  Would you also want symbols for .AND., .OR., .EQV. and .NEQV.?  There is a feature for F202X that currently uses @ , but many are unhappy about it.

JohnNichols
Valued Contributor II
220 Views

No I like it the way it is, it is always a pain to look up the && and remember in language XYZ what it means.  

Makes it easy to read.  

I have always used .eq.  etc.. and I was bemused the other day when I looked at some old code and saw them using == etc. and thought I have to get out of the 1970s.  

 

andrew_4619
Honored Contributor II
207 Views

The world is a varied and interesting place! I always use == and  /=  etc and hate .EQ..  Additionally .OR. is far too many characters as for readability and needs a space either side to that is 6 characters! Anything more than ( A .OR. B) for me becomes ( ANY([ A, B, C, D]) )  much more to the point and more likely to be on one line of code!

JohnNichols
Valued Contributor II
198 Views

I understand your comment. As you said we are all different.  

I was looking at inquire this morning, and I was so glad I could just out my MS Fortran V5 manual from 1991 and find a sample, 

then I looked in the latest oneapi manual and aside from c to ! it is identical.  MS wrote and published good manuals. 

Reply