Re: M0036.03 Flavors and standard invalidation
Vincent and P1788
On 29 Aug 2012, at 11:48, Vincent Lefevre wrote:
> On 2012-08-28 08:25:48 -0400, Michel Hack wrote:
>> The argument that we can always deal with this issue later
>> does not work, because it would INVALIDATE a standard that
>> does not allow for the possibility of multiple flavors.
>
> Well, a new standard (a revision) always invalidates the previous
> standard. What really matters is that a revision of a standard
> shouldn't introduce requirements under which a program written
> for the old standard could no longer behave like before with the
> new standard.
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? (It might require new behaviour that can be regarded as non-functional, e.g. make rules for writing stuff to a log file.)
> IMHO, a set-based interval program would still behave in the same
> way if flavors are introduced in the future, assuming that the
> implementation uses the set-based flavor. Or could you show an
> example for which this would not be the case? (If you can find
> one, I think there's something buggy about flavors.)
As I see it, my description of flavors merely codifies the *existing* behaviour that is common to systems that extend classical interval arithmetic, in particular set-based and Kaucher/modal arithmetic.
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."
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.
Can you see anything else in flavors, that makes requirements beyond existing behaviour?
> However if flavors are specified in the first standard and if some
> mistake (currently not visible due to the lack of an implementation)
> is made with the flavor specification, fixing it in the future could
> introduce incompatible changes, and this would be bad.
That is a valid point. It applies, however, to all parts of a standard, so the question is how far the newness of flavors makes them less trustworthy than the rest of the standard.
John Pryce