Embedded blanks in operators

Klaus,

It wasn't a statement of belief (about logical IF), it was a question. Actually, it WAS possible to do without logical operators in constructing IFs, but their meaning very quickly becomes obscure, and whether or not the construct is obsolete, the logical IF is easier to understand later (although anyone can write impenetrable code if they try).

Surely the point I made about compound operators (like >=) is that in free format in FTN95 they cannot have spaces in, and if you want code that is future proofed [u:d8e77a9af7]and[/u:d8e77a9af7] compilable by multiple compilers, you should go that way. I agree that > looks better than .gt., but I'm not sure that >= or /= is better than the dotty version - I don't like either as a matter of aesthetics. I much preferred (decades ago) Algol-60 which had reserved words, including logical operators. But Algol-60 was about as portable as a Durian on a long distance flight!

davidb: You can't have != because the ! would indicate that an inline comment followed.

Eddie

Quoted from LitusSaxonicum Davidb:

Do you really (need logical operators) if all you have is an arithmetic IF (e.g. as in IBM1130 Fortran), or do they simply make the code more readable?

I'm still using this line, programmed in 1969 (I think) on said machine:

      IF ((H+0.40D0)*(H-0.50D0)) 7,7,4

because I can't puzzle out what the heck it does! (But I'm sure it has an .AND. in it).

It does this

if ((H+0.40D0)*(H-0.5D0)) GOTO 7 ! goto 7 if value is <= 0.0DO
GOTO 4 ! else goto 4

No 'And' in there apparently. [u:a576198f5b]But[/u:a576198f5b] there is hidden away, look:

In maths it means: if h**2 -0.1*h -0.2 ⇐ 0 goto 7.

This is the same as if h >=-0.4 .AND. h ⇐ 0.5 goto 7 (solving the quadratic and plotting it out to confirm its concave upwards)

So the function jumps to label 7 if h is between -0.4 and 0.5 (inclusive), otherwise it jumps to label 4.

Using a logical IF

IF (H >= -0.4D0 .AND. H <= 0.5D0) THEN
   ! Do label 7 code
ELSE
   ! Do label 4 code
END IF

Modern version is clearer and should be more efficient. :lol:

I think you still need .AND. .OR. etc since you can't formulate similar tricks when these are used in combination. (At least I can't).

Shame on you davidb !! Your analysis misses all the nostalga of 1130 fortran. When I first started work, I refused to use the 1130 and so these logical expressions were mere fokelore to me.