> Date: Sat, 26 Mar 2005 17:26:16 -0700
> From: James Giles <[log in to unmask]>
> robin wrote:
> ...
> >> If all you've got is a single bit, that's also the sign bit.
> >
> > A bit in PL/I is unsigned. That's the definition of a bit.
>
> That's not how I read the PL/I document. The BIT attribute
> can only be applied to non-numeric data.
That's right, and there is no sign associated with BIT data.
(That's what unsigned means.)
> I don't remember
> how bits compare for relative order, or even if they *can*
> be compared for anything but equality or inequality.
The bit '1' ranks higher than bit '0', as you would expect.
> The
> attributes SIGNED and UNSIGNED are not permitted at all
> with BITs,
Nor did I say otherwise.
> as they only apply to numeric data. In any event,
> the PL/I definition is irrelevant to the current thread except
> for comparison purposes only: this is the *FORTRAN*
> newsgroup.
It was you, you will recall, who first introduced languages other than
Fortran into this discussion.
> I would still argue that LOGICAL data should be unordered
> (that is, concepts like "less than" or "greater than" are not
> defined for them). If they *are* ordered, I still prefer .true.
> to be less than .false. as the more natural ordering.
'false' precedes 'true' in the dictionary.
> If you define
> LOGICAL as an enumerated type, the most natural declaration
> (whatever the syntax) is to list the two values as TRUE and
> FALSE in that order.
Whether that is so or not, in PL/I the internal value
of an enumerated type can be specified, so order is
irrelevant.
> It also, as I already pointed out, permits
> the most flexibility in the use and representation of LOGICAL.
No it doesn't, and not on all machines.
I recall one at least one machine (Interdata or Burroughs?)
that had a logicize instruction to produce 0 and 1 following
a comparison.
> Now, as for the original question: I've always said that there
> are many "string" operations that should be allowed on data
> other than type CHARACTER. Among these are the intrinsic
> functions SCAN and VERIFY. If these could be applied to
> arrays of LOGICAL, the functionality the original person wanted
> would be easy.
It doesn't need that to deal with the original poster's
query, as I already pointed out.
But in the meantime, the hand-coded loop is the most
efficient means of doing what he wanted.
> --
> J. Giles
|