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

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

--- ai12s/ai12-0144-1.txt	2016/01/09 01:48:22	1.8
+++ ai12s/ai12-0144-1.txt	2016/01/29 00:12:07	1.9
@@ -1,4 +1,4 @@
-!standard A.5.2(20)                             16-01-08   AI12-0144-1/06
+!standard A.5.2(20)                             16-01-28   AI12-0144-1/07
 !standard A.5.2(32)
 !standard A.5.2(41)
 !class Amendment 14-12-04
@@ -88,9 +88,10 @@
   Constraint_Error is the existing exception for that (A.5.2.(39)), so we
   used that here.
 
-  Postconditions are assumed to be a requirement on the body of a subprogram,
-  as proposed in AI12-0179-1. If that AI is not approved, then we should not
-  use a postcondition here; we'd need some wording instead.
+  Postconditions are assumed to impose a requirement on the body of a
+  subprogram, as proposed in AI12-0179-1. In the unlikely event that AI is not
+  approved, then we should not use a postcondition here; we'd need some
+  wording instead.
   End Editor's notes.]
 
 Modify A.5.2(41):
@@ -99,9 +100,20 @@
   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 {consecutive}
+  [successive] calls to Random {that have the same generator and result range}
+  is approximately uniformly distributed over the {result} range [of the
+  result subtype].
+
+  {AARM Discussion: In this rule, "consecutive" means at least that there are
+  no intervening explicit calls involving the same generator. This restricts
+  the rule to only applying to cases where just the Random function changes
+  the generator. We don't mean to impose a requirement if there are
+  intervening calls to Reset, to Random with same generator but a different
+  result range, or any other case that would affect the sequence of values
+  returned. Operations which use the resulting random values (for instance,
+  to store them somewhere) are not considered in determining if calls are
+  consecutive.}
 
 Modify A.5.2(42):
 
@@ -110,6 +122,8 @@
   finite number of calls, provided that the number of such values does not
   exceed 2 15.
 
+[Editor's note: the above "15" is a superscript, which doesn't show up in this
+plain text rendering.]
 
 !discussion
 
@@ -1449,3 +1463,453 @@
 
 ***************************************************************
 
+From: Steve Baird
+Sent: Monday, January 11, 2016  12:36 PM
+
+[Significant part of a longer message - Editor.]
+
+I'm seeing
+    "does not exceed 2 15"
+as opposed to, perhaps,
+    "does not exceed 2 ** 15" . Is there a typo here?
+
+
+***************************************************************
+
+From: Gary Dismukes
+Sent: Monday, January 11, 2016  1:11 PM
+
+I believe that's a actually a superscript, and it doesn't get rendered
+properly in the online AI web page.
+
+[Added Editor's note to clarify - Editor.]
+
+***************************************************************
+
+From: John Barnes
+Sent: Tuesday, January 12, 2016  4:09 AM
+
+[Significant part of a longer message - Editor.]
+
+The sentence "postconditions are assumed to be a requirement on the body of
+a subprogram" upset me  I could read that to mean that every subprogram body
+has to have a postcondition.
+
+[Changed "be" to "impose" - Editor.]
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Tuesday, January 19, 2016  8:00 PM
+
+[Significant part of a longer message - Editor.]
+
+For a letter ballot I am casting a "reject" vote (although I agree with the
+techbnical intent), because
+
+1. The sentence
+> 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].
+
+is at best seriously incomplete, at worst plain wrong. It should read:
+
+A sufficiently long sequence of random numbers obtained by successive calls to
+Random with the same actual parameter for Gen and the same result_subtype is
+approximately uniformly distributed over the {result} range [of the result
+subtype].
+
+Obviously, both qualifications, especially the Gen bit, are important.
+
+2. Looking at the interface in context, I am not sure that it is a good
+   idea to have one interface in the package use postconditions, while
+   the others do not. As much as I like postconditions, this looks odd.
+   Maybe we could (re)do this package in its entirety with
+   postconditions?
+
+Also, there are editorial bugs:
+Formatting is somehow off (courier fonts for parts of the text.) In the
+Semantics section of (32): ". it" -> ". It"
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 20, 2016  8:28 PM
+
+[Significant part of a longer message - Editor.]
+
+...
+> Obviously, both qualifications, especially the Gen bit, are important.
+
+I suppose you're right, but this is Ada 95 wording, and it's hard to imagine
+how important it could be to be precise about the generator parameter now
+when it never was before.
+
+> 2. Looking at the interface in context, I am not sure that it is a good
+>    idea to have one interface in the package use postconditions, while
+>    the others do not. As much as I like postconditions, this looks odd.
+>    Maybe we could (re)do this package in its entirety with
+>    postconditions?
+
+The postcondition on the new routine is pretty minimal (it just defines the
+range); the operative stuff is in the Implementation Requirements that can't
+be described in a postcondition. There's no point in adding a postcondition
+of True to the other Random functions, and there isn't anything about the
+result which can be described with a postcondition. I don't see any useful
+postconditions that could be added to any of the other routines, either
+(Reset, Save, Image, Value). That's rather typical: the containers most
+likely will only have a handful of routines that have postconditions (based
+on our previous discussion on AI12-0112-1), the majority of routines will not.
+
+While this was one of the reasons that I've been luke-warm at best at adding
+a postcondition rather than words for this routine, this is a discussion that
+I clearly lost and I don't see much point in revisiting it lest we enter an
+infinite loop of no progress.
+
+> Also, there are editorial bugs:
+> Formatting is somehow off (courier fonts for parts of the
+> text.) In the Semantics section of (32): ". it" -> ". It"
+
+Sigh. You're (like several others) looking at the autoformatted version, which
+ should *never* be used for editorial review of an AI, as the format is
+generated by guessing what each piece of text is. It will *always* have errors.
+These particular errors (assuming you meant "if" instead of "it", since there
+is no "it" in (32)) come from something that was discussed twice previously. 
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Friday, January 22, 2016  6:22 PM
+
+Returning to more technical arguments ....
+
+What got me going here was the fact that a user can easily misjudge the
+situation casued by a local instantiation of the generic package, which par
+force, because the generator type is inside the package (-- maybe stupidly --),
+causes his seemingly sequential calls on Random to NOT return random numbers,
+because the Generators differ. (Wasn't this even the scenario why this AI came
+up in the first place?)
+
+Worth mentioning? I think so.
+
+Worth a shitstorm? No.
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, January 24, 2016  5:09 PM
+
+[Significant part of a longer message - Editor.]
+
+I have yet another technical issue:
+
+Now that there are two Random functions, what do the semantics say if both of
+them get called in some order? Clearly the uniform distribution sentence is
+then all screwed up.
+
+(A safer version would duplicate the surrounding package, so that the
+Generators keep the two kinds of calls apart, but that is a lot of text or
+the manual.)
+
+In exchange, I take back the one about a singular interface with
+postconditions. The other functions don't really have specifiable ones.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, January 24, 2016  5:32 PM
+
+[Significant part of a longer message - Editor.]
+
+> I have yet another technical issue:
+> 
+> Now that there are two Random functions, what do the semantics say if 
+> both of them get called in some order?
+> Clearly the uniform distribution sentence is then all screwed up.
+
+My intent (I thought that it was written somewhere, but I can't find it now)
+is that it doesn't matter. That is, only the result range (and, as you point
+out, the generator) matters, not the form of the call.
+
+Specifically, if one interleaved calls to the two random functions:
+    ... Random (Gen, Result_Subtype'First, Result_Subtype'Last) ...
+    ... Random (Gen) ...
+    ... Random (Gen, Result_Subtype'First, Result_Subtype'Last) ...
+    ... Random (Gen) ...
+
+The uniform distribution requirement would still apply. The expectation is
+that these really different views of the same logical function; we have two
+separate specifications for compatibility.
+
+As the AI says, if this was 1994, we just would have defined the function
+as:
+function Random (Gen   : Generator;
+                 First : Result_Subtype := Result_Subtype'First;
+                 Last  : Result_Subtype := Result_Subtype'Last) return Result_Subtype;
+and there would be no question about the handling of "different" random
+functions. (This specification is incompatible on the margins -- specifically
+for renaming and formal subprogram matching -- and it's too late to break
+those things.)
+
+I think the wording reflects that. We have (with your generator change):
+
+  A sufficiently long sequence of random numbers obtained by successive calls
+  to Random that have the same generator and result range is approximately
+  uniformly distributed over the result range.
+
+And the definition of result range is in the (new) previous paragraph:
+
+  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 safer version would duplicate the surrounding package, so that the  
+> Generators keep the two kinds of calls apart, but that is a lot of 
+> text  for the manual.)
+
+I don't see the point. We want to think of this as two views of a single
+random function, not two different functions.
+ 
+> In exchange, I take back the one about a singular interface with 
+> postconditions. The other functions don't really have specifiable 
+> ones.
+
+Yup, that's what I noticed when I looked at it.
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, January 25, 2016  6:43 AM
+
+> Specifically, if one interleaved calls to the two random functions:
+>     ... Random (Gen, Result_Subtype'First, Result_Subtype'Last) ...
+>     ... Random (Gen) ...
+>     ... Random (Gen, Result_Subtype'First, Result_Subtype'Last) ...
+>     ... Random (Gen) ...
+> 
+> The uniform distribution requirement would still apply. The 
+> expectation is that these really different views of the same logical 
+> function; we have two separate specifications for compatibility.
+
+True for the above. False for:
+>     ... Random (Gen, Result_Subtype'First+5, Result_Subtype'Last-5)
+>     ... Random (Gen) ...
+>     ... Random (Gen, Result_Subtype'First+5, Result_Subtype'Last-5)
+>     ... Random (Gen) ...
+
+Now the 10 outliers get chosen half as often, since the distribution in the
+one routine gets narrowed to the First..Last range, and in the other routine
+to Result_Subtype'Range. And, within each category, the series is not
+reproducible, due to possibly varying numbers of the "other" calls.
+
+(What one could promise is that the float-version with the uniform
+distribution is underneath it all, and these versions merely map its uniform
+distribution faithfully onto discrete values within the result ranges.)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 25, 2016  6:12 PM
+
+> Now the 10 outliers get chosen half as often, since the distribution 
+> in the one routine gets narrowed to the First..Last range, and in the 
+> other routine to Result_Subtype'Range.
+
+Sure, but the requirement doesn't apply to these calls because the ranges are
+different. The same would be true for:
+
+     ... Random (Gen, 1, 10) ...  -- (A)
+     ... Random (Gen, 1, 5) ...   -- (B)
+     ... Random (Gen, 1, 10) ...  -- (C)
+     ... Random (Gen, 1, 5) ...   -- (D)
+
+> And, within each category, the series is not reproducible, due to 
+> possibly varying numbers of the "other" calls.
+
+I couldn't parse this, but I do see a problem with the wording (and probably
+it's the same one you're seeing).
+
+Specifically, the requirement wouldn't apply to calls (A) and (B) above,
+because the ranges are different. But the requirement does appear to apply to
+calls (A) and (C) above; the calls are "successive" and meet the other
+requirements. And that's not going to be easy to ensure, as the changes that
+call (B) makes to the generator Gen might make it difficult to preserve
+uniformity. Particularly if the pattern of calls is irregular. Similarly, a
+call to Reset or one of the other operations on Gen would mess up the
+requirement. Worst case:
+
+    Reset (Gen, 1);
+    A(1) := Random (Gen, 1, 10);
+    Reset (Gen, 1);
+    A(2) := Random (Gen, 1, 10);
+    ...
+
+Arguably, the requirement applies to the two calls to Random here, but they'll
+most likely both return the same value.
+
+I think we can fix the wording to cover these cases by simply changing
+"successive" to "consecutive" in the proposed wording:
+
+  A sufficiently long sequence of random numbers obtained by {consecutive}
+  [successive] calls to Random that have the same generator and result range
+  is approximately uniformly distributed over the result range.
+
+Maybe it would help to add an AARM note to spell out that "consecutive" here
+means that there are no intervening explicit calls (to anything) between the
+calls to Random. That prevents any issues because the generator is changed by
+calling Reset, other calls on Random with the same generator, and probably
+other things that we haven't thought of yet.
+
+You (or someone else) might complain that this version of the requirement
+would hardly ever apply. That's true, but it's OK, since the only real purpose
+of this requirement is to give users and implementers a baseline for a "good"
+random generator. And so long as the requirement *could* happen in a program
+(and it certainly could, just put the values in an array and analyze them
+later), the random function will have to behave properly. I'm not worried
+about someone constructing a random generator that only works right if there
+are no intervening calls -- one would have to be actively evil for a call to
+some unrelated function to make the random generator malfunction. (And the RM
+does not worry about actively evil implementers anyway, they can't be stopped
+by a mere Standard.)
+
+> (What one could promise is that the float-version with the uniform 
+> distribution is underneath it all, and these versions merely map its 
+> uniform distribution faithfully onto discrete values within the result
+> ranges.)
+
+That exposes too much mechanism; arguably, there wouldn't even have to be a
+float version.
+
+I think the above change does the trick. One could argue that the intent of
+"successive" was to not allow non-matching calls in between, but it's not
+obvious and at a minimum deserves an AARM note.
+
+Thoughts??
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Tuesday, January 26, 2016  6:10 AM
+
+> Sure, but the requirement doesn't apply to these calls because the 
+> ranges are different. The same would be true for:
+> 
+>      ... Random (Gen, 1, 10) ...  -- (A)
+>      ... Random (Gen, 1, 5) ...   -- (B)
+>      ... Random (Gen, 1, 10) ...  -- (C)
+>      ... Random (Gen, 1, 5) ...   -- (D)
+> 
+>> > And, within each category, the series is not reproducible, due to 
+>> > possibly varying numbers of the "other" calls.
+> I couldn't parse this, but I do see a problem with the wording (and 
+> probably it's the same one you're seeing).
+> 
+> Specifically, the requirement wouldn't apply to calls (A) and (B) 
+> above, because the ranges are different. But the requirement does 
+> appear to apply to calls (A) and (C) above; the calls are "successive" 
+> and meet the other requirements. And that's not going to be easy to 
+> ensure, as the changes that call (B) makes to the generator Gen might 
+> make it difficult to preserve uniformity. Particularly if the pattern 
+> of calls is irregular. Similarly, a call to Reset or one of the other 
+> operations on Gen would mess up the requirement.
+
+
+Since the calls go to the same generator, I would expect
+
+  - indeed, each one, within their range, would distribute uniformly
+
+  - however, in general, not reproducibly, i.e., for cases, where
+    the number of intervening other calls to the same Gen is
+    dynamically determined, the sequence will not be reproducibly
+    the same.
+
+So, one requirement on Random is met, the other is not. The counter example
+is:
+
+    Reset (Gen, 1);
+    A(1) := Random (Gen, 1, 10);
+    for I in 1..changingvalue loop
+       ... Random(Gen, 1, 5);
+    end loop;
+    A(2) := Random (Gen, 1, 10);
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 26, 2016  4:49 PM
+
+Yes, that's what I said (or at least meant). I went on to point out that we
+don't really care if the uniform requirement only applies in narrow
+circumstances, since an implementer would have to get it right in those
+circumstances and only an actively evil implementer would manage to do
+something bad in a case like the above if they've really met the uniform
+requirement.
+
+But you didn't answer my question: does changing the wording to "consecutive"
+(rather than "successive") and then adding an AARM note to clarify further
+address your concern???
+
+And if not, what *would* address your concern???
+
+P.S. To repeat yesterday's message, here's exactly what I suggested (with an
+explicit AARM note to follow):
+
+  A sufficiently long sequence of random numbers obtained by consecutive
+  calls to Random that have the same generator and result range
+  is approximately uniformly distributed over the result range.
+
+AARM Discussion: In this rule, "consecutive" means that there are no
+intervening explicit calls (to anything) between the calls to Random. This
+restricts the rule to only applying to cases where just the Random function
+changes the generator. We don't mean to impose a requirement if there are
+intervening calls to Reset, to Random with same generator but a different
+result range, or any other case that would affect the sequence of values
+returned.
+
+[I don't want to get into formally defining what and what cannot appear
+between two consecutive calls, as that way seems to lead to madness. If the
+generator is hardware-based, simply wasting differing amounts of time between
+calls could change the behavior to something non-uniform. But we at least have
+to allow the program to store the value somewhere between calls to Random.
+Vague is probably better here.]
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, January 27, 2016  8:42 AM
+
+> But you didn't answer my question: does changing the wording to 
+> "consecutive" (rather than "successive") and then adding an AARM note 
+> to clarify further address your concern???
+
+Saying "consecutive" helps me, at least.
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Wednesday, January 27, 2016  10:55 AM
+
+> But you didn't answer my question: does changing the wording to 
+> "consecutive" (rather than "successive") and then adding an AARM note 
+> to clarify further address your concern???
+> 
+> And if not, what *would* address your concern???
+
+I am o.k. with the new wording, especially with the idea expressed by the
+AARM note. It is more user-understandable than what I had in mind.
+
+Maybe the AARM note could be relaxed by saying "...means that there are no
+other intervening calls involving the same generator." Tying it to a
+statically checkable and very restrictive property seems unnecessary.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 27, 2016  2:20 PM
+
+In thinking about it more, I think you're right. I was trying to cover for
+the *next* problem someone thought of, but that's probably taking CYA too far.
+
+P.S. CYA = Cover your a**!
+
+***************************************************************

Questions? Ask the ACAA Technical Agent