To: J3 07-151
From: Bill Long
Subject: UTI 104: BITS comparisons
Date: 2007 January 29
References: J3/07-007
Discussion of UTI 104, page 142.
This paper addresses the editor's comments in unresolved issue 104
regarding mixed-mode comparison operations involving one operand of
type BITS. Table 7.3 (page 141) currently allows comparison operations
of the form B .op. B, B .op. I, B .op. R if .op. is ==, /=, <, >, <=,
>=, and B .op. Z if .op. is == or /=. Continuing with the notation
used in the table, the objection is primarily to the comparisons of B
and R. Specifically the editor (E) observes:
E: B .op. B works like unsigned integers for comparion operation, and
is well understood.
BITS is a performance feature and processors typically include a
comparison operation that can be used for unsigned integers. BITS
comparisions can also use this hardware, as well as character
comparisons. However, we should not confuse hardware
implementation with language semantics. BITS objects are not
unsigned integers any more than character objects are unsigned
integers. Any datum represented internally as a string of bits,
including a REAL value, can be interpreted as an unsigned integer.
That does not make it one.
E: B .op. I also makes sense since it involves converting to
"unsigned" which is a reasonable thing to do.
The conversion is always of the non-bits object to bits
[148:11-13]. The concept of "unsigned" does not enter. The bits
proposal intentionally avoided the issue of unsigned integers for
two reasons. One is lack of consensus on the correct way to
convert an integer to an unsigned integer, as discussed in the
UTI. The other is so that, in the future, the possibility of an
unsigned integer type is not excluded or limited by the BITS data
type.
E: B .op. R does not make sense because here bits do not act like
unsigned integers.
Sure. That's because bits are not unsigned integers. Here, or in
the case of B .op. I.
E: B .op. R, especially for .op. involving < or >, is very error
prone. And unnecessary, since the user can always explicitly cast the
R to type bits with bits(R).
I think the rules are perfectly clear and should be easy for
textbook authors to explain. I guess I don't share the editor's
low opinion of programmers. A bits comparison operation is a
comparison of the bit strings, without any baggage of the other
type's intepretation of its bits. Suggesting that in the case of
REAL the user should be required to case to type bits first is
inconsistent with the B .op. I case and also irregular compared to
the rules for other mixed-type comparisions. I see no motivating
argument for introducing such an irregularity.
E: Requiring a cast for real and complex operands provides a visual
indication that one is not doing a numerical comprison.
Users have been using relational operators to compare character
strings for a long time and are not confused into thinking they
are doing numerical comparisons. BITS is, similarly, a nonnumeric
type. Once users are familiar with the rules for bits, they should
not be confused in that case either.
E: Comparisons of bits objects and integer/real/complex objects should
be limited to what makes mathematical sense.
BITS is a nonnumeric data type. There is no reason for such
comparions to make mathematical sense. And there is no reason to
distinguish integer from the other cases. Indeed, for all
hardware implementations I know about, integers when viewed as
BITS objects have the property that negative ones are larger than
positive ones. This hardly makes mathematical sense. Mathematics
is just an irrelevant issue when discussing bits comparisons.
Edits to 07/007:
OPTION 1:
No edits.
OPTION 2:
[148:13+] In 7.1.5.6.1 Interpretation of relational intrinsic
operations, in Note 7.26 that begins "As shown in Table 7.3...", add a
second paragraph:
"A relational intrinsic operator can be used to compare the value of
an expression of a numeric type with one of type bits. Such
comparisons can be used to compare, for example, an IEEE real valued
expression with a hexadecimal constant corresponding to a known exact
value. Comparisons between numeric and bits values are nonnumeric
comparisons and, thus, may produce nonmathematical results. For
example, a negative numerical value may compare as larger than the
bits representation of a positive value of the same type and kind."