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