From rz48@rz.uni-karlsruhe.de Sat Dec 30 23:04:45 1995 Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id XAA07782 for ; Sat, 30 Dec 1995 23:04:43 +0100 Received: from ry70.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Sat, 30 Dec 1995 23:04:35 +0100 Received: by ry70.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA035831069; Sat, 30 Dec 1995 23:04:29 +0100 Subject: 006 post-meeting 135 ballot To: janshep@watson.ibm.com Date: Sat, 30 Dec 1995 23:04:29 +0100 (CET) Cc: sc22wg5@dkuug.dk From: hennecke@rz.uni-karlsruhe.de X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 7328 Message-ID: <"nz11.rz.un.264:30.12.95.22.04.39"@rz.uni-karlsruhe.de> Here are my comments on the 006 ballot. Sorry I voted 196-Yes at the WG5 approval, in San Diego I overlooked the problem with edit 2. That edit was made in a hurry to convince me of answer 1b, and should be withdrawn/modified. Best wishes, Michael ------------------------------------------------------------------------------- Y|wc N 95-006 Item or Fortran 95 edit |X|_| |_| 000027 Requirements for pointer and target association |X|_| |_| Fortran 95 edits listed for defect item 27 |_|_| |_| 000081 Pointer actual argument overlap |_|_| |_| Fortran 95 edits listed for defect item 81 |X|_| |_| 000100 ASSOCIATED intrinsic and zero-sized objects |_|_| |_| 000125 Copy in/copy out of target dummy arguments |_|_| |_| Fortran 95 edits listed for defect item 125 |_|_| |_| 000145 Expressions in of a FUNCTION statement |X|_| |_| Fortran 95 edits listed for defect item 145 |_|X| |_| 000148 RANDOM_SEED, RANDOM_NUMBER |X|_| |_| Fortran 95 edits listed for defect item 148 |X|_| |_| 000154 EQUIVALENCE and zero-sized sequences |X|_| |_| 000155 Multiple USE statements, rename and only lists. |_|X| |_| 000176 Definition of RANDOM_SEED |X|_| |_| 000179 DO variable with POINTER attribute |X|_| |_| 000183 Unambiguous procedure overloading |X|_| |_| 000185 What is the allocation status of an array after an allocation failure? |X|_| |_| 000187 TARGET attribute, storage association, and pointer ass. |X|_| |_| Fortran 95 edits listed for defect item 187 |X|_| |_| 000194 Statements between SELECT CASE and CASE |_|_| |X| 000196 Inaccessibility of intrinsic procedures |_|_| |X| Fortran 95 edits listed for defect item 196 |_|X| |_| 000201 SELECTED_REAL_KIND result |_|X| |_| Fortran 95 edits listed for defect item 201 |X|_| |_| 000203 Scope of operator/assignment symbols |X|_| |_| Fortran 95 edits listed for defect item 203 ------------------------------------------------------------------------------- 148 Y Hennecke Given these questions, I agree with the answers. But the current specifications are still not enough to allow portable use of RANDOM_SEED: 1. The user cannot be sure about the behavior of a PUT call. Although the edit now implicitly assures that a value obtained by GET shall be acceptable as a PUT value, and that the processor is free to modify a PUT value before actually using "something" as a seed, there is still the open question if a processor is also free to _reject_ a PUT value! Since RANDOM_SEED has no mechanism to report such an "error condition" and the standard does neither require that all PUT values (of the correct SIZE) are acceptable nor require the processor to document which values it _does_ accept as a valid PUT input, this is a real problem. Restricting PUT only to restore a former GET value is (now) safe, but a too hard constraint: there may be information that I want to communicate into a generator via PUT, but that it will not necessarily output in a former GET call. 2. The standard leaves it processor-dependent if an argument-less call to RANDOM_SEED does a repeatable or non-repeatable reset. This is what it says (with or without answer 1), but it's still a bad idea: Both variants are sometimes useful, but it's quite desasterous to write a lottery program using a "non-repeatable" processor, move the code to another processor, and end up with a "repeatable" implementation. The best a programmer can do is to include the code from question 1 in the application and then do a PRINT *, "Go and fetch your dice." ; STOP if the result of X==Y is not what he or she expects. Doing non-repeatable resets by PUT if X==Y is true will also be nonportable because of comment 1 above. So the best way would be to require "non-repeatable" semantics; a repeatable reset _can_ be implemented with GET and PUTs. This would change the standard, but as it stands there is no conforming, portable and _useful_ way to use CALL RANDOM_SEED(). More comments on this and some F90 implementations can be found in an article at http://www.uni-karlsruhe.de/~Michael.Hennecke/Publications/#CPC95 176 Y Hennecke See my comments on 148. 196 N Hennecke I agree with the answer to (2), and edit 1. I do not agree with the answer to (1b), and edit 2 which was made to justify that answer is inadequate: The 3rd paragraph of 14.1.2 originally reads "in the case of generic names (12.3.2.1)". The last paragraph of the quoted section 12.3.2.1 contains the sentence "A generic name may be the same as any one of the procedure names in the interface block, or the same as any accessible generic name." Edit 2 introduces a restriction to the second half ("when both are generic names"). This is a change of the original meaning of 14.1.2, which (in my opinion) addresses the possibility of the first half of the above quotation from 12.3.2.1. If accepted, edit 2 would invalidate the use of a name both as a generic identifier and as the name of a specific procedure in that interface block. Edit 2 should be withdrawn or modified to include the case of "a name used as a generic identifier and as the name of a specific procedure in that interface block". This does not always prohibit the appearance of an "INTRINSIC SIN" stmt, there are a few more holes. I'd prefer to delete the "..." line in [007r1,272:10] and defer that discussion to a F95-interp. F95-196 N Hennecke See my 196 comment. 201 Y Hennecke Why do the F95 edits have an edit 3 not applied to F90? F95-201 Y Hennecke See my 201 comment. -------------------------------------------------------------------------------