From rbk@usl.edu Mon Oct 14 12:56:47 1996 Received: from bp.ucs.usl.edu (root@bp.ucs.usl.edu [130.70.40.36]) by dkuug.dk (8.6.12/8.6.12) with SMTP id MAA01830 for ; Mon, 14 Oct 1996 12:56:36 +0100 Received: from rbk5287.usl.edu ([130.70.46.171]) ([130.70.46.171]) by bp.ucs.usl.edu with SMTP id AA21389 (5.65c/IDA-1.4.4 for ); Mon, 14 Oct 1996 06:56:21 -0500 Message-Id: <2.2.32.19961014115455.006c9070@pop.usl.edu> X-Sender: rbk5287@pop.usl.edu X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Oct 1996 06:54:55 -0500 To: "Weber C, BSSA" From: "R. Baker Kearfott" Subject: Re: F2000: miscellaneous requirements Cc: sc22wg5 At 10:21 AM 10/14/96 +0200, Weber C, BSSA wrote: >Dear Baker, > >Thank you for your comments. >I see the issues you mentioned as follows: > >>1. I thought "hpc" was charged with dealing with the core of >> scientific computing, that is, with numerical issues in >> addition to high-performance constructs. Within this framework >> I would judge exception handling, viewed as numerical exception >> handling, to be a part of hpc. >I think that hpc is in charge of all requirements concerning >"performance issues" *or* "numerical computation issues" (not with >*and* instead of *or*). Therefore I put issues such as "asynchronous >IO", parallel processing... onto your list although there is nothing >particularly numeric with it. Do you agree? > >I put "exception handling" onto my list because this requirement has now >to be reduced to "exception handling beyond the IEEE TR": I am just preparing >an essay showing what still remains to be covered - it's essentially the >high-level "longjump" construct and exceptions beyond the IEEE ones. I >considered these items as of essentially non-numeric and non-hpc nature. >Do you agree? > Yes, that form of exception handling should be in "miscellaneous." The one thing under the purview of the "hpc" subgroup related to exception handling is support of properly rounded I/O as specified by IEEE. This is not an exception per se', but is similar to the other IEEE support in John Reid's "exceptions" TR and is not in the TR itself. There is a technical issue to be worked out with this I/O support. >> >>2. Do you view our function as further processing the present list, >> or as identifying additional items? I thought that the present >> list had more or less already been prioritized. Or do you view >> our function as doing technical work on the items other than >> those "already treated?" > >Both. I see our task as follows: > >(1) Collect new requirements if there should be any (which I do not >really expect - the repository is pretty comprehensive). > >(2) Collect additional information for the present list which allows a >better judgment of the amount of *work to be done by X3J3* such that in >Las Vegas it can be judged better how much X3J3 can handle. > >(3) Organize a "prioritization vote" for the present (or possibly >enhanced - see (1)) list which hopefully gives a more accurate result >than the "subgroup voting" which we had in Dresden. (It was my feeling >that the subgroups in Dresden were far too small and randomly assembled >to actually "represent the Fortran community"). > That sounds very reasonable. >I did not want to distinguish between "TR" and "other kind of dedicated >activity". All I wanted to point out is that the issue is already >handled adequately and has extremely high priority - so there's nothing to do >within the three "requirements handling subgroups" for this item. Do you >agree? > Yes, I agree with your analysis of the list. I apologize for being somewhat pedantic about terminology, but I was recalling various discussions concerning whether specific items should proceed as TR's or not. Best regards, Baker --------------------------------------------------------------- R. Baker Kearfott, rbk@usl.edu (318) 482-5346 (fax) (318) 482-5270 (work) (318) 981-9744 (home) URL: http://interval.usl.edu/kearfott.html Department of Mathematics, University of Southwestern Louisiana ---------------------------------------------------------------