> Date:          Wed, 30 Mar 2005 10:16:04 -0500
> From:          David LaFrance-Linden <[log in to unmask]>

>    Date:         Wed, 30 Mar 2005 23:48:48 +1000
>    From: robin <[log in to unmask]>
>
>    > 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.

Well, then, consider your trying to sell such a machine.
For at least 55 years, logical hardware has been using
0=false, 1 = true.
0 + 0 = 0 (for + read .and.)
0 + 1 = 1
1 + 0 = 1
1+1 = 1
and for .or.
0 + 0 = 0
0 + 1 = 1
1 + 0 = 1
1 + 1 = 1 etc
Try convincing anyone that 1001 and 0110 are better than 1 and 0.
I thnk you will agree that the description was appropriate.

>    would require even more storage,
>
> Blatently false; see they reply I sent a few minutes ago.

Not false.  More instructions are required.

>    take more execution time,
>
> Not at all clear; see the reply I sent a few minutes ago.

It's patently obvious.
I invited you to inform us how your "proposal"
would handle the logical OR of a true and a false.
Until you do that, you won't see why you are wrong.
[Below does it trivially for constants.  I had variables in mind.]

>    and achieve nothing.
>
> It achieves the semantics of the language, as do all other methods.

It achieves nothing over 0/1 0/-1, pos/neg or any of the other methods,
and runs slower and fatter.

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

This is for constants.
What happens when you don't know in advance
what the values will be?  E.g.,   v .or. w
where v and w are LOGICAL variables

> 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 makes just as much sense as your proposal for
false = 0110 and true as 1001.

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

The correct answer is that it would be a lemon.

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

That's just the point -- I *do* understand those "~0/0" ideas.
That's why 0110 and 1001 is a lemon.

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

My point is that it *should* be defined.  And that if it
were defined, it should be as 0/1.

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

Well, 0 and 1 are integers, and they are only one bit each.

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

What you have missed is that 0 and 1 are the basic digit
values.
Hardware has been designed to represent and operate upon
logical (Boolean) values.
0 + 0 = 0
0 + 1 = 1
1 + 0 = 1
1 + 1 = 1.
where 0 = false and 1 = true.
General purpose computers since the 1940s have represented
Boolean operations this way, using their logical hardware.

>    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"?

0110 and 1001 for logical.

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

That is, of course, the case of 1/0.
But the Fortran case is to use a whole word to store a logical value.
Given that a whole word is used in Fortran,
0/1 is the best choice in terms of speed.