Re: Motion 56 -- Level 2, Clauses 12.12.1-12.12.7
Michel, P1788
I'm still playing catchup with emails, so I ask you again to excuse my breaching our procedures, at least technically, by making changes to the text while voting is in progress. I only do it if it is minor and there seems to be consensus.
Here is a matter I'm unsure about:
On 2013 Nov 25, at 04:48, Michel Hack wrote:
> 12.12 intro, bottom of page 54 (P1788/D8.1 of Nov 15): As I pointed out
> for 12.6.2 already, we don't need explicit mixed-type operations for
> inf-sup types -- and 754-conforming types *are* inf-sup types.
I feel this is wrong, but I defer to our experts on language binding issues.
Using ib64 as short for the inf-sup binary64 type, etc., suppose a programmer writes an interval operation such as
zz_ib64 = xx_ib32 op yy_ib128 (*)
where "op" is one of the operations required to have "tightest" accuracy. As Vincent & Michel say, double-rounding isn't a problem for directed rounding, so the required effect is got *if* the program actually does
1. convert xx_ib32 to xx_ib128 (no error at this step),
2. do "op" in ib128 precision, returning zz_ib128,
3. take the ib64 hull of this to get the answer.
But what's to say a given language will make this happen automatically?
- (*) might cause an error at compile time.
- Or, if a language *does* have rules that do this sort of automatic coercion for library datatypes (as well as native datatypes) what's to say they are the right rules? E.g., in (*) the default might be to coerce all inputs to the destination type ib64, and I don't think this guarantees the "tightest" result.
So it seems to me the standard *needs* to make requirements about mixed-type operations. I've already inserted Michel's wording (**) below, end of 12.6.
> I'll have to think about mid-rad types based on 754 arithmetic...
> ... I conclude that we don't need this paragraph about mixed-type operations.
If my point, above, is valid, it would apply to other types besides inf-sup.
> 12.12.6, last paragraph (2nd bullet in Note, middl eof page 56):
>
> "An implementation should not, and for an inf-sup type need not, ..."
>
> Although "should not" is standard standard-speak, I don't get the
> implication of "need not". I do understand the motivation.
Ah. My point is that if a Level 2 result of cancelMinus, in an inf-sup type, overflows, it can only do so one-sidedly, i.e. the tightest Level 1 result is always of the form [a,oo] or [-oo,b]. So returning Entire, while "valid", shows laziness. Maybe you could check I have this correct, and suggest better wording. But it's only a Note. not normative text!
John Pryce
------------------------------------------------
On 2013 Nov 25, at 01:39, Michel Hack wrote:
> 12.6.2, bottom of page 48, mixed-type operations. As Vincent pointed
> out, the double-rounding problem addressed by 754-2008 is not an issue
> for directed rounding, and hence may not be an issue for inf-sup types.
> So I suggest adding:
(**)
> For inf-sup types this requirement may be met by implicit widening
> of inputs to a common widest format, as double rounding is not an
> issue for directed rounding.
On 2013 Jun 12, at 13:08, Vincent Lefevre wrote:
> I also find this less important for intervals. But note that the
> double-rounding problem has a noticeable effect only for rounding
> to nearest, not for the directed rounding modes used with inf-sup
> interval types. Thus if
> (1) T' is a superset of T;
> (2) T -> T' tightest operations are implemented;
> (3) T' -> T tightest hull is provided (this is required, isn't it?);
> then the corresponding T -> T tightest operations are obtained by
> composition of (2) and (3), so that I don't see any reason not to
> provide these T -> T operations. But for a language not providing
> them natively or in a library, saying "to get such an operation,
> the programmer must write the composition explicitly" would be
> a way to conform to the standard, IMHO, though languages should
> define a shorter/simpler way to write these operations.