Re: Revised FlavorsText
Hossam, Guillaume, Vincent, P1788
Responding at last to some comments on Motion 61.
On 2014 Feb 26, at 08:04, Hossam A. H. Fahmy wrote:
> However, I have a comment on the wording of one paragraph that we should
> revise when we vote on the final text. On the first page the current
> text says:
> " Flavor is a property of program execution context, not of an
> individual interval. Therefore, just one flavor shall be in force at any
> point of execution. It is recommended that at the language level, the
> flavor should be constant over a procedure/function or a compilation
> unit."
>
> The above text is valid in general for an execution context that
> computes a result. However, if a library procedure/function is written
> to convert between flavors then it cannot follow the restrictive
> condition of "one flavor shall be in force". The standard must allow for
> such conversion routines to deal with multiple flavors simultaneously.
Good point. If an implementation has more than one flavor then such conversion functions should exist, in fact there can be many of them since they are Level 2 operations and a destination type must be part of the definition.
For a conversion operation between types, from T1 to T2, within a flavor it seemed natural (IMO) to say it belongs to the destination type T2. Is it also reasonable to say the same for flavors? For a conversion operation from T1 of F1 to T2 of F2 it is F2 that is deemed to be "in force".
If there is one flavor per compilation unit as the text suggests, one needs a variable whose scope spans compilation units, say xx_T1inF1, so that
yy_T2inF2 = convertToT2inF2(xx_T1inF1)
makes sense. But that seems OK.
On 2014 Feb 28, at 14:53, Vincent Lefevre wrote:
> On 2014-02-28 09:19:18 +0100, Guillaume Melquiond wrote:
>> The last paragraph of 7.5.4 is a bit restrictive too. It might well happen
>> that two different implementations are just incomparable. I am thinking in
>> particular of elementary functions; which one of two implementations is the
>> most accurate presumably depends on the input domain (values close to zero,
>> large values, etc) due to their having different argument reduction.
>
> I think that linear ordering may be useful for the end user, and
> the current "should" is OK. But IMHO, the ordering should just be
> informative, and not necessarily linear: accuracy mode 1 > accuracy
> mode 2 when in general f1(X) in included in f2(X), without a guarantee
> that this is always the case. The idea is to inform the user that he
> will generally get more accurate results by choosing mode 1 instead of
> mode 2. The only guaratee is that for inf-sup types (when the hull is
> unique), the tightest mode gives the most accurate results.
I agree with Guillaume in the sense that two different implementations of an operation phi are often (usually?) incomparable de facto, in the sense that for a general xx, neither of yy1=phi1(xx) and yy2=phi2(xx) is guaranteed to be a subset of the other. But a mode is a *named assertion about* accuracy. How many of those is it useful to have? We don't invent one for each implementation of phi.
I think the current text is not too bad. If anyone wants to offer better wording, please do. But isn't Vincent's "informative" ordering too subjective? "in general f1(X) is included in f2(X)" presumably means "most of the time f1(X) is included in f2(X)". How to verify this? By performance on some benchmark?
John