Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: What is the FORTRAN for ?
Message-ID: <3638@goanna.cs.rmit.oz.au>
Date: 29 Aug 90 09:32:30 GMT
References: <13293@mentor.cc.purdue.edu> <61279@lanl.gov> <9317@ubc-cs.UUCP>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 28

In article <13393@mentor.cc.purdue.edu> ags@seaman.cc.purdue.edu (Dave Seaman) writes:
> [different FORTRANs may represent LOGICAL values differently on the same
> machine]
In article <9317@ubc-cs.UUCP>, buckland@cheddar.ucs.ubc.ca (Tony Buckland) writes:
>  The universal convention, so far as I know, is that .FALSE. is
>  always represented by all bits zero, while *any* bit on must be
>  recognized as .TRUE. and detected by the code generated by a
>  conforming compiler.

Universal?  The machine I did my first real programming on took
"any odd number" as .true., "any even number" as .false.  Another
compiler I used later took "any negative number" as .true.,
"any non-negative number" as .false., while another language on
that machine used exactly the opposite convention.

What's more, I've just been reading the book
	Programming Parallel Processors, ed. Robert G. Babb II
The date of the book is 1988, but most of the chapters seem to have
been produced in 1986.  Let me quote from the CRAY appendix:
	...
	alternate return labels may not be used because CIVIC and
	CFT pass statement labels in different ways that are
	totally incompatible
	...
	LOGICAL functions and values are not used because CIVIC and
	CFT ***use different values for .TRUE.***.
-- 
You can lie with statistics ... but not to a statistician.