CVS difference for ai12s/ai12-0144-1.txt

Differences between 1.7 and version 1.8
Log of other versions for file ai12s/ai12-0144-1.txt

--- ai12s/ai12-0144-1.txt	2016/01/07 05:35:08	1.7
+++ ai12s/ai12-0144-1.txt	2016/01/09 01:48:22	1.8
@@ -1,7 +1,8 @@
-!standard A.5.2(20)                             16-01-06   AI12-0144-1/05
+!standard A.5.2(20)                             16-01-08   AI12-0144-1/06
 !standard A.5.2(32)
 !standard A.5.2(41)
 !class Amendment 14-12-04
+!status work item 15-12-17
 !status ARG Approved 7-0-0  15-10-18
 !status Promising (10-0-0) 15-02-26
 !status work item 14-12-04
@@ -62,7 +63,7 @@
   instantiation of Numerics.Discrete_Random is delivered as a value of the
   generic formal subtype Result_Subtype.]
 
-  [Editor's note: We delete the last two paragraphs here as all they say is
+  [Editor's note: We delete the last two sentences here as all they say is
   that the function result is in the result subtype, which is always true for
   a function (in the absence of exceptions or erroneous execution, both of
   which have to be explicitly stated). The actual description of the result
@@ -94,14 +95,14 @@
 
 Modify A.5.2(41):
 
-  {The *result range* of a Random function, is the range First .. Last for the
-  version of Random with First and Last parameters, and the range of the result
-  subtype otherwise.}
+  {Each call of a Random function has a *result range*; this is the range
+  First .. Last for the version of Random with First and Last parameters and
+  the range of the result subtype of the function otherwise.}
+
+  A sufficiently long sequence of random numbers obtained by successive calls
+  to Random {that have the same result range} is approximately uniformly
+  distributed over the {result} range [of the result subtype].
 
-  A sufficiently long sequence of random numbers obtained by successive calls to
-  Random is approximately uniformly distributed over the {result} range [of the
-  result subtype].
-
 Modify A.5.2(42):
 
   {A}[The] Random function in an instantiation of Numerics.Discrete_Random is
@@ -124,8 +125,8 @@
 
 
 Users often accomplish this in ways that do not provide a truly uniform
-distribution. It's easy to come up with methods that don't work (see the
-!appendix for several such algorithms), but it's difficult to get right.
+distribution. It's easy to come up with methods that don't work (see
+the !appendix for several such algorithms), but it's difficult to get right.
 
 One algorithm that is correct is to start with a uniform random generator
 that produces an integer in the range 0 .. Large. (Usually Large is some
@@ -1177,3 +1178,274 @@
 I agree for the same reason.
 
 ***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 7, 2016  8:48 AM
+
+[Editor's note: Letter Ballot stuff stripped out here.]
+
+This new sentence preceding A.5.2(41) has some grammatical issues:
+
+   The result range of a Random function, is the
+   range First .. Last for the version of  Random
+   with First and Last parameters, and the range
+   of the result subtype otherwise.
+
+That first comma doesn't make sense to me, but then that second comma has a
+problem if you leave it out.
+
+How about the following:
+
+    Each Random function has a /result range/; this
+    is the range First .. Last for the version of Random
+    with First and Last parameters and the range
+    of the result subtype of the function otherwise.
+
+***************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, January 7, 2016  9:14 AM
+
+[Editor's note: Letter Ballot stuff stripped out here.]
+
+It seems there has been some aggressive "substitute all" in the text.
+After "Add after A.5.2(32):", the text is in the code font, and all Ada
+keywords are in bold in the editor's note. Under the !discussion, in the
+phrase "see the appendix", appendix has been turned into a !appendix
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 7, 2016  1:46 PM
+
+Those are the effects of the auto-formatter. The first defies any correction,
+since the only way to prevent the formatter from treating the text as part
+of the code would be to not indent it (the autoformatter assumes code
+continues until the end of the indented section). But the style of the RM
+is to have such text indented. Presumably the !corrigendum will be correct
+one it gets added to the AI. I saw this when I posted it, but as noted, I
+couldn't think of any fix.
+
+The second occurred because "!appendix" happened to start a line, and thus
+the formatter took it as the start of the !appendix section. Since the other
+tools make the same assumption, I will change that by moving line breaks
+around, but note that the formatting is not part of the official AI, so this
+is not a real change at all.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 7, 2016  1:55 PM
+
+> How about the following:
+> 
+>     Each Random function has a /result range/; this
+>     is the range First .. Last for the version of Random
+>     with First and Last parameters and the range
+>     of the result subtype of the function otherwise.
+
+<grumble>You couldn't have made this comment when I proposed this wording
+back on December 11th?? That's kinda the reason I *send* wording suggestions
+to the ARG list in the first place.</grumble>
+
+This does seem like an improvement, I'll use it. I'll wait for any other
+suggestions before posting an updated AI.
+
+***************************************************************
+
+From: Steve Baird
+Sent: Thursday, January 7, 2016  1:50 PM
+
+The proposed wording includes.
+
+>  Modify A.5.2(41):
+> {The result range of a Random function, is the range First .. Last for 
+> the version of Random with First and Last parameters, and the range of 
+> the result subtype otherwise.} A sufficiently long sequence of random 
+> numbers obtained by successive calls to Random is approximately 
+> uniformly distributed over the {result} range [of the result subtype].
+
+When we say "is approximately uniformly distributed over the result range",
+what single range are we talking about? We are talking about "result range"
+as though it is a property of the function, but two calls to the same function
+can have different result ranges (in the case where First and Last are passed
+in).
+
+To be correct, I think we really need to say that the result range differs
+from one call to the next (i.e., it is a property of the call, not of the
+function) and then require something like
+
+   "A sufficiently long sequence of random numbers obtained by
+    successive calls to Random which have the same result range is ..."
+
+The idea is that you have lots of calls to the Random which takes a First and
+Last parameter, then you partition that set of calls so that two calls are in
+the same partition element if and only if their First/Last values match (which
+means that they have the same result range). We then impose the "sufficiently
+long sequence" requirement on partition elements (where the notion of a single
+result range makes sense).
+
+Or am I being too pedantic?
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 7, 2016  2:23 PM
+
+> Or am I being too pedantic?
+
+Usually. ;-)
+
+<grumble>Why didn't you point this out when you were complaining about this
+wording in Bennington? The wording proposed there had a similar problem. Or
+back in December when the current version was proposed??</grumble>
+
+OK, now that I that I got *that* off of my chest, I'm understanding that you
+are proposing the following change to this wording, folding in Tucker's
+change:
+
+Modify A.5.2(41):
+
+  {Each call of a Random function has a *result range*; this is the range
+  First .. Last for the version of Random with First and Last parameters and
+  the range of the result subtype of the function otherwise.}
+
+  A sufficiently long sequence of random numbers obtained by successive calls
+  to Random {which have the same result range} is approximately uniformly
+  distributed over the {result} range [of the result subtype].
+
+(The changes are to add "a call of" in the first paragraph, and "which have
+the same result range" to the second paragraph.
+
+One effect of this wording is that the requirement would hold for mixed calls
+to the Random without First and Last parameters and calls to Random where
+First = Result_Subtype'First and Last = Result_Subtype'Last (since these
+result ranges would be the same). That's probably OK, we'd want the routines
+to operate in the same way in that case.
+
+Should we make these changes? (I lean toward doing so, as they clarify the
+model.) [I think we'd restart the Letter Ballot if we do, as this is a pretty
+substantive change.]
+
+***************************************************************
+
+From: Bob Duff
+Sent: Thursday, January 7, 2016  3:39 PM
+
+[Editor's note: Letter Ballot stuff stripped out here.]
+
+...
+> The revised AI can be found on-line in the normal place:
+> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0144-1.txt (make 
+> sure you use the most recent version; I mistakenly posted a version 
+> with a blank space where the change for A.5.2(32) was supposed to go, 
+> so there are two /05 versions in the VCS).
+
+Sounds naughty to have to same-numbered versions.  It's not like we're going
+to run out of positive integers.  ;-)
+
+...
+
+I agree with the comments that led to this:
+
+> Modify A.5.2(41):
+> 
+>   {Each call of a Random function has a *result range*; this is the range
+>   First .. Last for the version of Random with First and Last parameters and
+>   the range of the result subtype of the function otherwise.}
+> 
+>   A sufficiently long sequence of random numbers obtained by 
+> successive calls to
+>   Random {which have the same result range} is approximately uniformly 
+> distributed
+>   over the {result} range [of the result subtype].
+
+I suggest deleting this from the AI:
+
+     (unless a compiler
+    vendor makes them available through a non-standard package).
+
+You could say that about ANY new feature.
+
+  Obtains the ?next? random number from the given generator, relative to its
+  current state, according to an implementation-defined algorithm.[ The result
+  of the function in Numerics.Float_Random is delivered as a value of the
+  subtype Uniformly_Distributed, which is a subtype of the predefined type
+  Float having a range of 0.0 .. 1.0. The result of the function in an
+  instantiation of Numerics.Discrete_Random is delivered as a value of the
+  generic formal subtype Result_Subtype.]
+
+  [Editor's note: We delete the last two paragraphs here as all they say is
+                                         ^^^^^^^^^^
+
+Those things we're deleting are sentences, not paragraphs.
+
+***************************************************************
+
+From: Gary Dismukes
+Sent: Thursday, January 7, 2016  4:11 PM
+
+> Should we make these changes? (I lean toward doing so, as they clarify the
+> model.) [I think we'd restart the Letter Ballot if we do, as this is a 
+> pretty substantive change.]
+
+Yes, I'm in favor of going ahead with those changes.  With one minor tweak:
+change "which" to "that" in "{which have the same result range}". Other than
+that it looks good. :)
+
+If that means restarting the ballot, will hold off on my vote.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 7, 2016  4:30 PM
+
+...
+> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0144-1.txt (make
+> > sure you use the most recent version; I mistakenly posted a version 
+> > with a blank space where the change for A.5.2(32) was supposed to 
+> > go, so there are two /05 versions in the VCS).
+> 
+> Sounds naughty to have to same-numbered versions.  It's not like we're 
+> going to run out of positive integers.  ;-)
+
+I try to ensure that we never have two versions on the same date, so we're
+limited to one per day in usual circumstances. In a situation like this,
+where an incomplete AI gets stored, I just make the correction as the previous
+version shouldn't exist. (But one can't delete versions from the VCS, so my
+mistakes will live forever.)
+
+I also don't use new version numbers for presentation changes (that is, moving
+around the whitespace), for posting mail, and (rarely) for fixing obvious
+typos in nonnormative parts of an AI.
+
+...
+> I suggest deleting this from the AI:
+> 
+>      (unless a compiler
+>     vendor makes them available through a non-standard package).
+> 
+> You could say that about ANY new feature.
+
+That's from the original posting by Adam; as I frequently tell John, we try to
+use as much of the original question as possible, and as such we edit it as
+little as possible. (In John's case, that means we might leave some iffy
+grammar and some unclear constructions.) I will trim out extraneous
+information, so it's a close call as to whether to leave it or remove it. I
+view it as harmless, which is why I left it initially.
+
+It fairly frequent that I have to create !problem or !question out of thin air,
+in which case all changes are on the table. But I don't want to put words in
+other people's mouths unless absolutely necessary (and it's best to let as much
+of their original thought remain as possible).
+
+...
+>   [Editor's note: We delete the last two paragraphs here as all they say is
+>                                          ^^^^^^^^^^
+> 
+> Those things we're deleting are sentences, not paragraphs.
+
+Arrggghh!!
+
+***************************************************************
+

Questions? Ask the ACAA Technical Agent