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