J3/99-154 Date: 26th February 1999 To: J3 From: Malcolm Cohen Subject: Problems in the IEEE modules While trying to implement the IEEE modules I had some difficulties interpreting chapter 15. Most of these were resolved by discussion with John Reid, but they all require some changes to the draft. 1. All procedures supplied by the IEEE modules should be generics [359:37+] Add "All these procedures are provided as generic names." 2. P and R for IEEE_SELECTED_REAL_KIND should be INTENT(IN) [366:20-21] After each "integer." add "It is an INTENT(IN) argument." 3. Allow IEEE_SELECTED_REAL_KIND in initialisation expressions [124:30] Replace "or" with new item and renumber "(8a) A reference to the function IEEE_SELECTED_REAL_KIND from the intrinsic module IEEE_ARITHMETIC, or" 4. Chapter 15 says near the top "The module IEEE_ARITHMETIC behaves as if it contained a USE statement for IEEE_EXCEPTIONS." This does not actually mean that anything from IEEE_EXCEPTIONS is visible via IEEE_ARITHMETIC! (For instance, there might be a global PRIVATE statement in the IEEE_ARITHMETIC module). [355:7] Before "." add "and everything that is PUBLIC in IEEE_EXCEPTIONS is PUBLIC in IEEE_ARITHMETIC". 5. Insufficient information as to which functions may set which flags; e.g. IEEE_VALUE should not set any flag. How about IEEE_NEXT_AFTER with a NaN input? How about IEEE_SCALB, IEEE_RINT, etc. ... these don't reference the IEEE standard so what flags are set by what? No edits yet. 6. [357:18-20] says "Similar rules apply to the evaluation of specification expressions on entry to a procedure, to format processing, and to intrinsic operations: no signaling flag shall be set quiet and no quiet flag shall be set signaling because of an intermediate calculation that does not affect the result." On the face of it, this means that INTEGER X(100+INT(0.0*SQRT(-1.0))) is not allowed to set the INVALID flag! John Reid replied "I would expect invalid flag to be set, but an optimizing compiler could replace this by INTEGER X(100) Perhaps we have not got the words right, but the intention is to cover the private operations of the intrinsics. They might themselves use exception handling - try a fast algorithm - test the flag - use a slow method if necessary. In such code, the original flag value must be restored if all is well after using the slow method." I said "I cannot see why "specification expressions" appears at all in the statement above - at least I cannot see why it adds anything more than "intrinsic operations" unless the optimisation *is* being demanded." John replied "I think the intention was to draw attention to the fact that some execution takes place in specification statements. I think it would be better to say 'Similar rules apply to intrinsic operations, to format processing, and to the evaluation of intrinsic operations and intrinsic procedures within specification expressions on entry to a procedure:' I can't say that I am really satisfied with John's rewording, I still don't understand why it mentions intrinsic procedures! Even with this rewording it still looks to me as if my original example cannot set the INVALID flag! (If I am wrong, perhaps someone will explain to me how to interpret it!) [Also, I don't think it needs to mention intrinsic procedures - the first part of the paragraph covers them quite adequately, no?] Why does it mention "intermediate calculation"? I see no definition of this in the standard, surely there are no such things as an "intermediate calculation" in an intrinsic function (from the point of view of the std)? Indeed, I don't think these rules do apply to specification expressions any more than they apply to any other user-specified expressions. Therefore: [357:17-18] Delete "to the evaluation of specification expressions on entry to a procedure," Delete "," before "and to". 7. IEEE_UNORDERED: result characteristics should be default logical. [372:39] Change "Same as X" to "Default logical".