Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sgi!calvin@dinkum.SGI.COM
From: calvin@dinkum.SGI.COM (Calvin H. Vu)
Newsgroups: comp.lang.fortran
Subject: Re: extensions to logical variables
Summary: odd/even extentended logicals
Keywords: vax,logicals
Message-ID: <31555@sgi.SGI.COM>
Date: 27 Apr 89 23:44:43 GMT
References: <31660@stellar.UUCP>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 102

In article <31660@stellar.UUCP>, keith@stellar.UUCP (Keith Crews @stellar) writes:
> The basic problem I have with the vax implementation is that I think that 
> a logical variable should always be true or false.  You can do this by 
> forcing a conversion to 0 or -1 when assigning to them
	This is what ANSI says and that's what most non-VMS people expect,
	but some people do want logicals to retains its integer value after
	the assignment so they can be used in the same way as integers :-(.
	Don't search me for the answer though.   The only advantage in using
	extended logicals over integers, as far as I can see,  is that they 
	can do:
		logic = 3
		IF (logic) ...
	instead of:
		int = 3
		IF (and(int,1))
	since TRUE/FALSE condition on the VAX is evaluated by examining the
	last bit.

>     1)  Do people depend on having logicals that are neither true nor false?  
	Apparently so.   But I surely hope that they are the last of a
	dying breed :-}.   Nitpicking: they are neither .TRUE. nor .FALSE. 
	but they do evaluate to true or false according to their own 
	odd/eeven rule.

>     2)  What would people consider a consistent set of semantic rules for 
> these extensions to logicals?  
	Implementational expectation for exact compatibility:
	Allow extended logicals have the same values as integers and evaluate
	conditional expression by testing the last bit of the result. 

	For archaic processors which test TRUE/FALSE by looking at the 
	last bit this is no problem.  Nowaday, with the new processors 
	which test for zero/non-zero value, I doubt if anybody would do 
	an extra bit mask for each conditional expression evaluation just 
	to allow this ridiculous extension.   "How about my benchmarks ?",
	they'll say.

>     3)  Should .eq. and .eqv. behave identically with logical operands 
> or should .eq. do integer comparisons and .eqv. check for both zero or 
> both non-zero?
	.eq. is always implemented as integer comparison.   I don't know
	how .eqv. is implemented on VMS.   It would be interesting to test 
	if l1=1 and l2=3 are .eqv. on VMS.

> If you allow 2 distinct non-zero logicals to not be equal (.eq. different from
> .eqv. in 3 above) then you have another problem where the 2 expressions below 
> may evaluate differently:
> 
> 	l1 = 3
> 	l2 = .true.
> 	if (l1 .eq. .true.) ...
> 	if (l1 .eq. l2) ...
> 
> However, if you evaluate them the same then you are incompatible with vms
> fortran which seems like a dubious idea.
> 
> I guess the real issue is whether I have missed a unifying idea under-
> lying the vms implementation.
	The key is that VMS uses the odd/even concept of TRUE/FALSE so they
	can be liberal in the values their extended logical contains (i.e.
	all integer values).
> 
> Here are a couple of examples:
> 
> This prints 0 on the vax:
> 
> 	logical l1
> 	l1 = 3
> 	i = 0
> 	if (l1 .eq. .true.) then
> 	    i = 1
> 	endif
> 	if (l1 .eq. .false.) then
> 	    i = 2
> 	endif
> 	print *, i
> 	end
	.eq uses integer comparison so 3 is not equal to .TRUE. (which is 
	either 1 or -1)
> 
> This prints 2 on the vax and 1 on the sun:
> 
> 	logical l1, l2
> 	l1 = 3
> 	l2 = 4
> 	i = 0
> 	if (l1 .eqv. l2) then
> 	    i = 1
> 	endif
> 	if (l1 .neqv. l2) then
> 	    i = i + 2
> 	endif
> 	print *,i
> 	end
	SUN forces the logical values to either .TRUE. or .FALSE. so l1
	and l2 are both .TRUE. whereas on the VAX an odd 3 is not equivalent
	to an even 4 no matter how you look at it.
> -- 
> Keith Crews			Stellar Computer Inc.
> 				95 Wells Avenue, Newton, MA 02159

Calvin Vu