Re: M0036.03 Flavors and standard invalidation
Vincent, P1788
Replies to some points made by Vincent, plus an example to show "adding a new decoration" may indeed change a conforming program's behaviour.
On 30 Aug 2012, at 08:39, Vincent Lefevre wrote:
> On 2012-08-29 19:17:43 +0100, John Pryce wrote:
>> I guess Vincent's argument trumps Michel's. A revision of a standard
>> should not invalidate a previously conforming *program*, nor require
>> it to have different functional behaviour. Is that right?
>
> That's right, assuming that the program doesn't use undefined or
> implementation-defined features (in which case the program can
> behave differently even without a revision of the standard).
<<My remark about non-functional behaviour can be ignored.>>
>> Except for one thing. The only functional requirement my draft
>> flavor document makes AFAIK, is that there shall be a decoration D
>> that says "this was a common evaluation at Level 2". That is:
>> "The input box X = (X_1,...,X_k) to operation phi has components
>> X_i that are closed, bounded, nonempty intervals; phi is everywhere
>> defined and continuous on X; and the implementation was able to
>> find a closed, bounded, nonempty interval Y of the destination type,
>> that contains the range of phi over X."
>
> Well, note that even if Motion 36.3 is rejected, one could have such
> a decoration, which could even be useful in the context of set-based
> interval arithmetic.
Yes, and I now think we should have such a decoration, whichever way motion 36 goes.
>> If we don't require such a decoration to exist now, but some future
>> revision requires it, it seems possible that a conforming program,
>> if not written with D in mind, might behave differently under the
>> revised standard.
>
> If the program doesn't use undefined or implementation-defined
> features, I don't see why. New decorations shouldn't affect the
> interval results and shouldn't affect the existing decorations
> either.
Here's an example. It may be nonsense because of my misunderstanding language features, but here goes.
Suppose -- like most schemes we discussed -- the decorations are in a linear sequence that we can think of as going from "best" to "worst". Let them be implemented in C as an enumerated type. This automatically provides some operations, e.g. given decoration values d1, d2 I think one can code "if d2 is the next in the sequence after d1, do XX" as
if (d2 == d1++) {
XX
}
Now, suppose the standard is revised and the hypothetical D is inserted as a new decoration in the sequence. If at run time, d1 and d2 are such that the above test used to be true, but D is in between them, then in the new standard the test is false.
One might say that such code is bad programming style, but to someone who thinks "decorations have always been in exactly this sequence" it will look innocuous.
> Moreover I think that the standard should allow implementation-defined
> decorations ...
Yes
> ... That's why I think that the standard shouldn't be too complex, too
> theoretic (see the past discussions about the most complex decoration
> schemes, for instance).
And yes. One has to get theoretic, and sometimes complex, to prove some feature is *correct*, but such discussion does not belong in the normative part of the standard.
The struggles Arnold, I and others went through to justify a Fundamental Theorem of Decorated Interval Arithmetic (FTDIA) were fairly arduous. But once we did it, the standard only needs to state this FTDIA, and point elsewhere for the technical details.
And one test of a good decoration system is that its FTDIA is simple to *state*. Let's hope we can do that.
John Pryce