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