Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!mcvax!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.fortran
Subject: Re: CDC FORTRAN trivia questions
Keywords: arithmetic if logical
Message-ID: <7693@boring.cwi.nl>
Date: 1 Nov 88 23:07:38 GMT
Article-I.D.: boring.7693
References: <1196@helios.ee.lbl.gov> <3616@s.cc.purdue.edu> <7523@ut-emx.UUCP> <3622@s.cc.purdue.edu>
Organization: CWI, Amsterdam
Lines: 51

In article <3622@s.cc.purdue.edu> ags@s.cc.purdue.edu.UUCP (Dave Seaman) writes:
 > I agree that there was more than one convention, but I believe most of the
 > later compilers used -1 (59 one bits out of 60 on a ones-complement
 > machine) for .TRUE. and zero for .FALSE.
Still true for FTN4 and FTN5.
 > 
In article <7523@ut-emx.UUCP> cccm001@ut-emx.UUCP (Tom Linsley) writes:
 >The venerable RUN compiler used a different convention, whereby a word with no
 >bits set (+0) was .FALSE., and _any_other_value_ was .TRUE.  This convention
 >made possible some peculiarly illogical logical behaviors, in that both "X" and
 >".NOT. X" could be true simultaneously, if "X" had been given some nonzero (or
 >"non-logical") value (i.e., neither +0 nor -0).  Remember that this compiler
 >dates from a time when "strong typing" meant pounding hard on the keypunch.
 > 
I doubt this.  On the Cybers it is very difficult to distinguish +0 from the
rest.  The hardware compare for zero gets both +0 and -0.  (Testing L you have
to write: OR(NOT(L)+0,L).GE.0 to distinguish +0).
So I do not think any compiler has used this scheme.  (Was RUN FORTRAN 2 or
FORTRAN 3?  I do not remember anymore.)  The illogical thing is of course
that you could have tests like (I.LT.0.AND.I.EQ.0) return .TRUE. or
(P.GE.Q.OR.Q.GE.P) return .FALSE..

In article <3622@s.cc.purdue.edu> ags@s.cc.purdue.edu.UUCP (Dave Seaman) writes:
 > I remember that there was some strangeness about logicals with the RUN
 > compiler, and this may have been it, but I think the later compilers used a
 > slightly different test:  zero for .FALSE. and nonzero for .TRUE.  The
 > ones-complement value -0 (all bits set) is considered "zero" as far as this
 > hardware test is concerned, so that the problem you described does not
 > arise.
No, both FTN4 and FTN5 use negative for TRUE and positive for FALSE.  The
following function:
	LOGICAL COMPARE(X, Y)
	COMPARE = X .LT. Y
	RETURN
	END
would compile to the equivalent of:
	return(x-y)
without postnormalisation step.  If X and Y are not both -0 the subtraction
does not return -0.  Of course the equivalent for integers fails due to
possible overflow, but well, so it is with any comparison on integers.
The best I have found for a fail proof integer compare (<) was:
	OR(AND(XOR(I,J),J),AND(EQV(I,J),I-J)).

There is a very slick method to translate L = A.NE.B:
L = OR(A-B,B-A).

To summarise, I like ones complement machines, and I liked the Cybers.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax