[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
noWidenTo attribute
I just realised that I don't understand the definition of this.
The language (non-storage format; format available for arithmetic;
arithmetic format) is changing, but that is not the issue here.
I quote from draft 1.4.7 which precedes the one that should soon
be recirculated for ballotting:
Destination width is the maximum of the operand widths:
generic operations with floating-point operands and
results (of the same radix) round results to the widest
format among the operands, unless that format is a
storage format, in which case the result should be
rounded to the narrowest supported basic format.
What I don't understand is this rounding to a narrowest
format. Ok, I see: there is an implicit assumption that
storage formats are necessarily narrower than arithmetic
formats -- but is that necessarily true? Will it remain
true when we move to a different classification, where
we have arithmetic formats and interchange formats?
Consider an Intel x86 environment that defines a binary128
interchange format (so it can interchange 80-bit arithmetic
values with non-x86 environments without loss of precision).
In this environment binary128 is NOT available for arithmetic.
Does this mean that, under noWidenTo, all results that involve
at least one binary128 operand must be rounded to binary32?
It seems to me that noWidenTo is superfluous and misleading.
Its equivalent should be "widenTo (narrowest basic format)",
which would have the desired effect in all cases, including
the one I just brought up.
But perhaps I'm totally confused, so please help me out.
Michel.
Sent: 2008-01-11 23:39:40 UTC