Date:         Wed, 30 Mar 2005 23:48:48 +1000
   From: robin <[log in to unmask]>
   Precedence: list

   > Date:          Tue, 29 Mar 2005 11:13:59 -0500
   > From:          David LaFrance-Linden <[log in to unmask]>
   >
   > Wrong for WHAT?  ...

   Let's go for it them!
           Of course, what you propose is foolish,

You aren't making any friends with comments like this.

   would require even more storage,

Blatently false; see they reply I sent a few minutes ago.

   take more execution time,

Not at all clear; see the reply I sent a few minutes ago.

   and achieve nothing.

It achieves the semantics of the language, as do all other methods.

   Perhaps you'd inform us how under your proposal you would handle
   the logical OR of a true and false value?

Bitwise OR:
        .false. .or. .false. => ior(0,     0)      => 0      => .false.
        .false. .or. .true.  => ior(0,     not(0)) => not(0) => .true.
        .true.  .or. .false. => ior(not(0),0)      => not(0) => .true.
        .true.  .or. .true.  => ior(not(0),not(0)) => not(0) => .true.
AND is similar, as is XOR.  (EQV is NOT of XOR.)

   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.

What mushrooms have you been eating?  This makes no sense.

   >  It would be my choice as an implementor.

   Sure, but only because it's not defined in Fortran.

Bingo.

   But would you expect anyone to purchase such a product?

Existence proofs don't do anything for you, do they?  I'm told many
people have bought Digital/Compaq(/HP) Fortran for Alpha.  I don't
know if CVF for x86 decided to use 1/0 or ~0/0, so I can't comment
there.

Maybe you mean who would buy a product that requires a 96 bit word in
which every third bit was used to represent a number?  No, I wouldn't
expect somebody to buy such a machine, but since you clearly don't
understand the ~0/0 ideas, your question is irrelevent.

   > 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.

Bingo.  But what are we talking about?  I thought we (everybody who
has been on this thread) were in agreement the user can't rely on an
implemtations choice for values.  Some of us have been debating the
merits of various implementation options.  Which are you doing?

   > 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.

That's true, when you interpret them as bits according to the
dictionary definition.  There are philosophies that worry about the
verb "to be."  People talk about integers as being a sequence of bits.
Or of floating point numbers being an interpretation of a packaging of
bits.  But if you want to dive deeper into IS-ness, modern computers
deal with bi-valued storage entities, which they package in groups
into registers and memory.  We impose interpretations on those
bi-valued packages.  If you insist on people's usage of "bit" as
literal rather than colloquial, you just aren't going to get anyplace
until you find like-minded people.

   Your suggestions sound like Alice's who might design a number
   like 19486742 but only the RH digit has any value.

What are "my suggestions"?  That the testing method tests just the low
bit?  This is not unique to the ~0/0 representation.  It exists in ALL
designs where the storage can have more than 2 states.  You have to
decide how to collapse the >2 states into 2 states.  even/odd is a
priori no better or worse than 0/non-0 or negative/non-negative.  It
is just one possible way.  If hardware were expensive, a claim could
be made it is better than 0/non-0, since non-0 requires ORing all the
bits together which is more complex than testing a single bit.

   >  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.

~0 can be stored in one bi-valued package of storage quite easily,
thank you very much.