> Date: Sun, 27 Mar 2005 17:09:56 -0700
> From: James Giles <[log in to unmask]>
> robin wrote:
> ...
> >> As correctly pointed out by another, the canonical representation
> >> and the testing method are somewhat independent. Assuming two's
> >> complement integers, the canonical representation that travels best
> >> is -1 for true and 0 for false.
> >
> > No it's not.
> > 1. Negative 1 presents problems when it is desired to convert
> > logical to integer. Logical stored as 0 and 1 convert
> > easily to numeric 0 and 1. [...]
>
> Logical stored as -1 and 0 easily converts to INTEGER -1 and 0.
Sure they can, but they are the wrong values.
> Your fallacious assumptions are still showing.
On the contrary, yours are.
The first flaw in yours is that 0 and -1 are best,
when in point of fact that is not the case.
Since the internal representation is not defined in Fortran,
manufacturers are going to use the scheme
that best suits the hardware. That could well be 0 and 1,
or negative and positive, but not -1 and 0.
> > [...] Which is what the orginal enquirer wanted to do.
>
> What he wanted was the first .true. value in an aray.
No, he wanted 0 and 1.
======================quote==================
Date sent: Thu, 24 Mar 2005 08:15:34 +0800
From: Daniel and Nicola Grimwood
yes I was thinking in terms of 0 and 1.
Daniel.
=======================end quote===============
> There is
> no need to make assuptions about the internal representation
> of LOGICALs to do that at all.
I have already pointed that out, and even suggested a solution
along those lines.
> The language need not make
> such assumptions even possible. It shouldn't. At no time
> did the original person want to convert LOGICALs to INTEGERs.
He wanted to use the values 0 and 1. (see above).
The internal value is stored in an integer word.
It looks like an integer to me.
You even claimed (erroneously) that the best values would be -1 and 0.
Reasons 2 and 3 were omitted, so you have conceded that
they are valid arguments.
> >> 4. A statement such as A = B .GT. C produces either positive,
> > or negative, or zero, when B and C are subtracted. If such
> > a value were used as the logical result, that value would
> > be neither negative 1 nor zero for most cases.
>
> The sign bit actually works much better than 1 vs. 0 in this case.
You mean much better than -1 and 0.
> The subtract (C-B) produces the sign bit (and, on the machines
> where it's relevant, the "negative" condition code). The produced
> sign is the correct value for the logical predicate in question (negative
> means true, non-negative means false).
And then we get to strings. Comparing strings does not
usually produce 0 and -1. Typically, the outcome is/are
setting(s) in a condition code register or flag register.
> The bottom line is, and this is repeated information, the language
> doesn't specify what the internal representation of LOGICALs
> are. It shouldn't.
That's a design error. Corrected in PL/I.
With a defined representation, every Fortran compiler would
be consistent and programs could rely on the internal value,
and there would be some consistency in converting from
logical to numeric.
(BTW, the 'word' result harks from the days of word machines.)
> On most hardware I have any interest in at
> all, neither implementation (-1 vs. 0 or 0 vs. 1) is produced
> directly be compare instructions.
Of course not. It's sufficient to branch on >, >=, etc.
But in the case of multiple comparisons - e.g.,
if ((a > b) & (b < c)) ...
that tends to become cumbersome, and the logicize instruction
is of help here (converting to 0 [=false] and 1 [true] ).
But having the 0/1 model comes to the fore with
character data, where a numeric result is not produced
by the hardware, being recorded only as flag(s) or condition code.
Having a consistent mechanism across all the data types
means that -1/0 falls flat, while 0/1 yields a sustainable
outcome.
> In many cases that interest
> me, -1 vs. 0 is a better choice for the canonical internal rep
> than 1 v.s 0. In an even larger set of interesting environments,
> interpreting *any* negative as .true. and *any* non-negative as
> .false. is even better. Using the least significant bit is also the
> least interesting option.
But in practice, 0 and 1 provide the best outcome on many machines.
> --
> J. Giles
