Re: Motion 56 -- Level 2, Clauses 12.12.1-12.12.7
> 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.
Nothing to worry about! For correctly-rounded binary operations there
is never a need to widen to more than the widest of source and target.
(It would not be true for sums or products of three or more inputs --
but we have the reduction operations for that.) Moreover, the standard
is not concerned with infix (with implicit typing) vs functional notation
(with implicit or explicit typing).
One might worry about (*) being carried out in binary32 and then widened
on assignment. THAT result would not be tightest in the wider format,
but according to such a language, the programmer ASKED for this.
The requirement that mixed-type (but same-radix) operations be supported
is not going away. What I was proposing was that this could be satisfied
without combinatorial explosion of conceptually explicitly-typed function
types (the formatOf approach of 754-2008): it would be sufficient to have
one homogeneous form per type, and inputs narrower than that type could
safely be accomodated through input widening, without compromising even
tightest evaluation.
Michel.
---Sent: 2013-12-12 15:00:53 UTC