From jwagener@amoco.com Sun Nov 13 16:12:50 1994 Received: from interlock.amoco.com by dkuug.dk with SMTP id AA13370 (5.65c8/IDA-1.4.4j for ); Mon, 14 Nov 1994 05:13:30 +0100 Received: by interlock.amoco.com id AA03397 (InterLock SMTP Gateway 1.1 for sc22wg5@dkuug.dk); Sun, 13 Nov 1994 22:13:23 -0600 Received: by interlock.amoco.com (Internal Mail Agent-3); Sun, 13 Nov 1994 22:13:23 -0600 Received: by interlock.amoco.com (Internal Mail Agent-2); Sun, 13 Nov 1994 22:13:23 -0600 Received: by interlock.amoco.com (Internal Mail Agent-1); Sun, 13 Nov 1994 22:13:23 -0600 From: jwagener@amoco.com X-Openmail-Hops: 1 Date: Sun, 13 Nov 94 22:12:50 -0600 Message-Id: Subject: an ENABLE subset To: sc22wg5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 Item Subject: Message text The following paper was placed on the table the final day of the X3J3 meeting in Boston; I trust that it is self-explanatory. I have now identified (something close to) a subset of the ENABLE proposal that I believe addresses/resolves the technical concerns raised against that proposal and is extendible to (something close to) the full proposal. The subset does not provide anywhere near the functionality of the full proposal but provides the "right" basic subset for handling numeric exceptions - in this case "half a loaf" is indeed better than none. This subset is consistent with X3J3/94-385 and provides the functionality needed by Hull, et al, in the June '94 issue of ACM/TOMS, page 215. I'll distribute the subset electronically later this week. If there are no serious technical flaws spotted in it, I believe it is feasible for X3J3 to successfully integrate it into the Fortran 95 draft standard at its next meeting as well as complete all of the other interpretation issues. Jerry ---------------------------------------------------------- X3J3/94-386 To: X3J3 From: Jerry Wagener Subject: Is half a loaf better than none? Not always. But sometimes it is, and that may now be the case with numeric exception handling. The comments on the recent ballot on ENABLE, and especially the post-ballot email dialog, apparently struck me quite differently than it did virtually everyone else. For me, emerging from that flood of mostly here's-what's wrong-with-ENABLE, were the most convincing (to me) indications yet that Fortran badly needs _some_ way to handle numeric exceptions. If Fortran has a niche, high performance numerical computation has to be, or be a major part of, that niche. The post-ballot dialog (finally) convinced me that there are important application domains of numerical computation in which achieving both robustness and high performance requires numeric exception handling. Therefore, I now believe that it is very important, for Fortran to remain competitive in that niche, that Fortran "95" have some basic capability for allowing users to detect and respond to the occurrence of numeric exceptions. It is also clear that the current ENABLE proposal is far more than the required basic capability and is fraught with (both technical and nontechnical) problems. I have now looked at that proposal carefully enough, with an eye toward scaling it back, to be convinced that an extendible subset of it can both provide the required basic capability and avoid the problems of the full proposal. For example, that subset would: be limited to the nine numeric exception conditions, limit the scope of enable semantics and user signaling, and reflect other functional economies. I will attempt to produce such a subset soon after X3J3 meeting 131, with edits against 007. I believe that we can, if we so will, include such a facility in Fortran 95 and still meet the established Fortran 95 schedule. However, there are other approaches to providing this functionality, such as a (small) set of condition enabling, testing, and setting intrinsic functions. It is not important what form the basic capability takes. What is important is that the revision of Fortran 90 contain some such basic capability. I urge the WG5 management committee to so require, even if it means a delay in the schedule.