> Date: Tue, 29 Mar 2005 11:13:59 -0500
> From: David LaFrance-Linden <[log in to unmask]>
> Date: Tue, 29 Mar 2005 10:24:05 +1000
> From: robin <[log in to unmask]>
>
> > 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.
>
> Wrong for WHAT? It seems this discussion is in violent agreement now
> that both the internal form (canonical and otherwise) and testing
> method are outside the language and nobody but NOBODY should depend on
> them (provided there are appropriate conversion interfaces for
> cross-language calls). I could easily design an implementation that
> requires logical to have at least 4 bits of storage, .false. is
> represented as 9 and .true. is represented as 6, and actually have the
> testing method abort if the stored value is not 9 or 6. There is
> nothing right or wrong about it.
Let's go for it them!
Of course, what you propose is foolish, would require even
more storage, take more execution time, and achieve nothing.
Perhaps you'd inform us how under your proposal you would handle
the logical OR of a true and false value?
It you took your argument to its conclusion,
you would need a machine having a word size of 96 bits in
which every third bit was actually used to represent a number.
> It would be my choice as an implementor.
Sure, but only because it's not defined in Fortran.
But would you expect anyone to purchase such a product?
> Or perhaps .false. has an even number of bits lit, and
> .true. has an odd number, and when I need a value I get the next
> gray-code of the desired parity and that way I can look at the
> representation to tell me about how many logical values I've
> produced.
Monty Python might have something to say here.
> (Gray code, for those who don't know, is a binary counting
> system that changes one bit between successive numbers. It is useful
> for designing analog measuring devices (such as mouse wheels) and a
> variety of tavern and other puzzles. Therefore, the next number
> always has a different parity; two numbers away has the same parity.)
>
> In point of fact, I'll remind you that Digital/Compaq(/HP) Fortran for
> Alpha does indeed store .false. as 0 and .true. as ~0 (or -1 for those
> still thinking in two's complement), and uses even/odd as the testing
> method. And they are easily converted to - and ~0/-1;
They can be converted to anything _provided_that you know
what it it you're looking at.
The point is, the user doesn't know, and can't rely on them because they
are not defined.
> as another
> poster said, these are just bit patterns and they take on "value" when
> you impose an interpretation on them.
Bits are binary digits, 0 and 1, and have clear unambiguous values.
Your suggestions sound like Alice's who might design a number
like 19486742 but only the RH digit has any value.
> They aren't the right values or
> the wrong values for anything, until you declare the consistent
> context which imposes an interpretation. What's your context to claim
> they are the wrong values?
They are values generated by and used by hardware,
and require only one bit of storage to represent them.
|