J3/06-358r2 Date: 16 November 2006 To: J3 From: Dick Hendrickson Subject: Clause 13 Bits issues References: J3/06-007r1 Technical problems and questions in Clause 13 related to the BITS feature. In general, I don't propose an answer because I don't know what the intent was. 341:8-9 says the bits model only applies to the bit manipulation functions. However, many of the newer reduction functions (IAND, IPARITY, etc.) accept integer arguments and treat them as bit things. We should also edit the reduction functions to have them point to 13.3 Edit: 341:9 after "bit manipulation procedures" add " or the reduction functions IANY, IALL, or IPARITY" -- 374:24- B'0' is the wrong thing here, it has the wrong type. We need something like "kind zero bits". Editor please add a clarifying phrase to the BOUNDARY definition in EOSHIFT abut result kinds. -- 389:39 case(iv) doesn't specify what the result is if it isn't valid. We should pin it down so people can write portable code. Edit: Add ", otherwise it is processor dependent" to the end of the last sentence in case (iv). -- 402:1+ This needs to describe the end case for a bits array when the array is zero sized. Edit: 402:5. Add as a last sentence "If ARRAY has size zero and type bits, the result has a bits value with every bit zero." 405:25+ Similarly for MINVAL. Edit 405:33. Add as a last sentence "If ARRAY has size zero and type bits, the result has a bits value with every bit one." ------------------- Comments requiring no edits or action 388:INDEX Was there any thought about extending this to bits? I'd think something like INDEX (my_genome, cancer_gene) would be useful and natural. RESPONSE: The underlying code to implement this is non-trivial, for an efficient implementation. I'm not sure vendors would want to do this. Also, avoiding similarities between bits and characters is intentional. 389:26 IPARITY refers to "the bitwise exclusive OR", but I don't think the term is actually defined. Sure, it's obvious. But, we give truth tables for all of the logical functions like IEOR right above it. This may be resolved if 341:8-9 above causes edits. this applies to most of the new bit logical-ish transformational functions. RESPONSE: The Description of IEOR is "bitwise exclusive OR". The bitwise rules are defined there as well as in clause 7 (page 154). 399:27 For both the MAX and MIN functions, it's not clear from clause 7 how MAX(bits...) is defined. I think this is a problem with table 7.1, as the text in clause 7 (138:21 and 153:10) look like they define the comparisons. If 7 isn't fixed, something needs to be done here. RESPONSE: There was an omission from table 7.1. It should have specified bitwise relational operations. 406:4-6 All of the min*/max* functions have a special case saying that for characters, the intrinsic operators are used. Do we need to do the same for bits? Or is it obvious that B'11' > B'01'. It's maybe not obvious when people use a bit kind of 32, where you might (incorrectly) think the leading bit is a sign bit. RESPONSE: There was an omission from table 7.1. It should have specified bitwise relational operations. 412:13 I don't understand why PARITY is different from IPARITY. Why not let the mask be masked as in IPARITY (ARRAY, DIM [,MASK]) or IPARITY (ARRAY [,MASK]) 412:13 If we do something magical with automatic use of bits as a logical, we should think about merging PARITY and IPARITY. RESPONSE: Both PARITY and IPARITY were copied from HPF. The calling sequence and definitions are from the HPF spec. 431:15 Does the bits stuff work with TRANSFER? I'm just not sure how to read it. To me, TRANSFER seems awful word oriented and I'm not sure it works for bits. Also, there was talk about letting processors pad bits for efficiency. So that a kind=15 bit thing might take up a whole word. If a processor does this, does it effect the TRANSFER of a bits array to something else? RESPONSE: Yes, bits work with transfer. There are a couple of Notes that discuss bits and transfer. See Note 7.43, page 160-161, and Note 16.13, page 495. The Note about padding is 16.13, page 495.