> Date:          Tue, 29 Mar 2005 20:38:19 -0700
> From:          James Giles <[log in to unmask]>

> robin wrote:
> ...
> >> No they are merely better than 0 and 1.
> >
> > Well, they just are not, and before you are five good reasons
> > why they are not.
>
> No, before me are five attempt to save a losing position.
>
> >>  Not requiring *any*
> >> specific internal representation is best.
> >
> > Not in this case.
>
> Yes, even you attempted loop solution to the originally posted
> problem does not depend in any way upon the internal represenataion
> of LOGICALs.  Suince that is the context of the phrase "in this case"
> you are demonstrably wrong - and by you own example code.

No, I produced that because you had trouble comprehending
a loop solution.

> >> Not *allowing* any comparison based on order is best.
> >
> > Demonstrably false.
>
> Since you have yet to even post an example of *any* case
> where order is important, that statement is empty.  If something
> is demonstrably false: demonstrate it.
>
> >>>> What he wanted was the first .true. value in an aray.
> >>>
> >>> No, he wanted 0 and 1.
> >>
> >> I suggest you learn to read.  He *assumed* 0 and 1, and then
> >> acquiesed to the fact that .true. and .false. were not ordered
> >
> > Only because you told him so, when it was inappropriate.
>
> Your own solution to the problem also requires no ordering and
> no specification of internal values.  I was right all along.

No, you were wrong all along.
That was a work-around, to demonstrate a simple loop
that you had difficulty comprehending.

> > You didn't reply because the arguments are irrefutable.
>
> Most religious fanatics claim that.  Even to the point of disregarding
> obvious refutations - as you have.

What nonsense.

>  ...
> >> Yes, I mean *both*  But, since in an IF statement there is no need
> >> to produce *any* canonical form of LOGICAL, but merely to
> >> identify a criterion which matches some hardware conditional
> >> jump: NO canonical form is ever generated.
> >
> > You're repeating what's already stated.
>
> Because you seem to constantly disregard it.

In an involved logical expression, it is more convenient
to convert to 0/1 form.  The trivial examples you use
for illustration apply only to integers, but ignore the cases
of floating-point and strings.

> >>  However, if it's
> >> required, -1 and 0 are still better for this purpose than 0 and 1.
> >
> > Again, that's demonstrably false.
> > Negative 1 is not the natural outcome of a subtract -
> > whether it's integer, real, or string.
> > Using 0 and 1 produces simpler, faster code compared to
> > producing jumps.
>
> Which I didn't mention.  Since jumps are not even solutions
> I considered, but producing 1 or 0 reqires additional steps
> (on most hardware - the new Cray being the only exception),
> it's slower.

0/1 requires no additional steps compared to -1/0, and
can require less.
You are wrong.
You are wrong because you ignore the general case.

>>> 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.
> >>
>> As I actually said in my own article.
>
> > You have not mentioned that in this discussion.
> > I raised it first.
>
> I said it explicitly in the very article you were responding
> to above.  You elided it.  This mailing list is archived.  There
> is no point to your lying about who said what.  It's too
> easy to check.

I suggest that you produce the piece you claim was elided.

> >>  This is one of the many (many,
> >> many) design errors of PL/I.
> >
> > The designers were out to improve on Fortran,
> > and this they did, because the Fortran rule is inadequate
> > and inappropriate.  Hardware has changed considerably since
> > the 1950s.
>
> They failed miserably.  25+1/3 is not 5.3333333333333.

You are wrong again.  Even the example you quote is wrong.
This has been bandied about by prople who, like yourself,
should know better.
PL/I does not produce such a result.

I guess you overlooked Fortran's 1/2, but that's another story.

> > Having an internal representation that makes
> > for simple, straightforward, conversions between logical and numeric
> > makes for simple programs and portable programs.
>
> Whish you've not yet even demontrated a need to do.  Even
> your own solution to the problems at hand have yet to need
> *any* conversion between logical and numeric.  None is needed.

That was not a solution to the problem.  It was a work-around.
I wrote it because you had problems comprehending a loop.

> >>> 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] ).
> >>
> >> For integers the answer is the sign bit of (NOT(IOR((b-a),(b-c)))).
> >
> > Looks like muddled logic (npi) here.
> > Should be IAND in place of IOR.
>
> You don't even know deMorgan's rule?  That's the caliber of
> your thinking is it?

Is that how you try to cover up your mistakes?  Abuse the other party?
Your code is plain wrong.
Try it with the set of values a = 1 b = 2 c = 3
and also the set a = 1 b = 3 c = 2
and you will see why.

> > Your suggested code fragment impacts on other factors,
> > one being optimization.  It uses two registers and clobbers the
> > value of B.
>
> It makes no assignments at all, to B or anything else).

It changes the value of B in the register.
It ties up two registers.

>  The OR and the NOT could be applied to the condition code bits
> (on PCs, the compare instructions set the flags exactly as
> a subtract does, but without storing the difference anywhere).
> Converting the flags to 0 vs. 1 would require extra steps of
> unpacking the sign flags into registers and shifting them down
> to the least signigficant bit.  Slow.

I did not say anything about converting to 0/1 or anything else
in this example  "if ((a > b) & (b < c))".
If you read what I wrote, you will see that it states that the
logicize instruction is of help here.

> > And it need scarcely be pointed out that your flawed code
> > uses the pos/neg model, not the neg 1/0 model that you
> > erroneously claim is superior.
>
> The -1 vs. 0 *is* superior to 1 vs. 0.  Allowing the processor
> to pick *any* efficient method is superior to either.  A position
> you continue to erroneously deny.

The -1/0 model is inferior, and all (if not all) your examples
use pos/neg model, not the -1/0 model.

> > On the other hand, the 1/0 model needs no additional register
> > workspace.
>
> ????
>
> Wrong.

It is you who are wrong.  The logical result can be written direct
to storage without using a register.

> It needs to move the data to a register and mask the appropriate
> bit out of the flags and shift it down to the least significant position.
> If not, it's not 1 vs. 0.

It doesn't need to move anything of the sort.
The result can be written direct to storage on all known
machines.

> >>> But having the 0/1 model comes to the fore with
> >>> character data, where a numeric result is not produced
> >>> by the hardware, [...]

Here you will see that I first referred to character data,
and proof that it was you who elided it.

> >> You mean it receeds to the background, since zero and one are
> >> integers.
> >
> > No doubt you are trying to make a pun.
> > Refer to tbe preceding discussion,
> > where for simple tests, a branch is adequate without
> > necessitating the production of a 0/1 value.
> > Where one is required to be stored, the 0/1 model comes to the fore.
>
> How?  It requires as much shifting, packing, unpacking, masking,
> or generation as using any other bit (say the sign bit).  And requires
> more work later in using the value.

Have you considered the TEST instruction (PC)?  Or TM instruction?
Or whatever is the equivalent on your machine.

You should take a look at a hardware reference text.
There you will find that you are talking nonsense.

> Well, I tired.  Arguing with a fool is dull.  Go get an education
> or go back to the PL/I newsgroup where your diatribes are maybe
> welcome.

Why don't you have a good day?

It is unfortunate that you have resorted to abuse
when you have lost an argument.

> --
> J. Giles