Flavor conversions (was:Re: Revised FlavorsText)
P1788
It seems that somehow inter-flavor conversion functions were forgotten. They are fairly important, IMO. Suppose an implementation supports two flavors F1, F2 (or more): set-based, Kaucher, Rump, whatever.
- If there's no way of converting, it's just several disjoint
implementations so what's the point?
- Being able to convert from any F1 type to any F2 type, directly, seems
OTT to me since type conversions *within* a flavor are required anyway.
- So I suggest requiring
There be at least one pair of types T1 of F1, T2 of F2 for
which *mutual* conversion operations shall be provided.
- Example: between infsup binary64 of set-based and the same for Kaucher.
They could have the same Level 3 storage method so conversion requires
zero work beyond testing if it can be done. E.g. Kaucher -> set-based
of [3,4] is OK, of [4,3] isn't and presumably gives UndefinedOperation
exception.
- The implementation must document what conversion *means* mathematically,
hence for what intervals it succeeds at Level 1: which includes common
intervals. Exercise: how to express this for Rump intervals? Their
Level 1 & Level 2 are so closely related.
- From the viewpoint of the calling program, the flavor in force when
invoking such an operation is that of the destination flavor. That
is, conversion is an "import", not an "export".
What is in force *inside* the operation is not a meaningful question.
I think what's needed can be said in a few lines of text. I suggest putting it at the end of 7.1, after the list, since the notion of type is introduced in that list.
Thanks Hossam for raising the issue.
John Pryce
On 2014 Mar 17, at 23:01, John Pryce wrote:
> 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.