Re: As simple as it is now, I am still against motion 24.03...
Michel, P1788
On 10 Jun 2011, at 15:50, Michel Hack wrote:
> You have to realise that there are different classes of "users" who can
> benefit from a standard:
> (1) end-users, who want a predictable environment for doing their work.
> (2) library writers, who want a predictable set of primitives in order
> to provided the full functionality needed by group (1).
> (3) compiler and basic runtime writers, who need to know what primitives
> to provide for both (1) and (2).
>
> Those are all on top of hardware vendors, who provide the primitives needed
> primarily by group (3), as groups (2) and (1) use them in contexts that are
> progressively more removed.
>
> As most of you know my interests lie towards the bottom of this hierarchy,
> and the comments I made about using explicit directed operations alongside
> interval primitives apply mostly to group (2). Since group (2) is in a
> position to implement parts of a conforming IA environment, it does not
> need the full complement of standard functions, but it can benefit greatly
> from standard versions of those functions it wants to build from.
>
> A standard that only addresses group (1) leaves a lot of uncertainty for
> groups (2) and (3), and therefore makes it more difficult to achieve what
> is needed by group (1).
I find Michel's argument very persuasive. I think P1788 should have some SHALLs in it directed towards group (2), and perhaps group (3).
Motion 24.03 does that, but I am uneasy with it for at least 2 reasons:
- As someone said, it omits asking for some rounding modes that people want, e.g "towards zero", "away from zero". If we pursue this logically, we end up requiring implementations to provide quite a large number of rounding modes many of which are rarely used and some may be never used.
- We are trespassing too far on 754's bailiwick. Our project authorisation did not include saying how floating point operations should be done.
A balance must be struck. I rather like Arnold Neumaier's suggestion:
On 9 Jun 2011, at 12:15, Arnold Neumaier wrote:
> Thus it would be more useful to have operations that take a list of
> reals and return a (preferably the tightest) representable interval
> enclosing the result of an operation with them. Addition and inner
> product of arbitrarily many inputs, subtraction, division with two
> arguments, and sqrt with one argument.
(Does he want multiplication to be treated as a special case of inner product?)
That is, standardise a set of operations that have point input and interval output. Advantages:
- The number of different operations is much reduced.
- This is definitely within P1788's bailiwick, and doesn't trespass on 754's.
I suggest that on 754-compliant systems the operations be parameterised by the output interval format, like a 754 "formatOf" operation, and that interval format shall be of infsup type only. So one can input data of any FP format having the *same radix* as the output format. (Recall this eliminates the "double rounding" problem, while being fairly easy to implement.)
Thus, if
x_b32 denotes a binary32 FP datum, y_d64 a decimal64 FP datum, and so on,
and
[+]_b64 denotes addition of point operands returning
a binary64 infsup interval, and so on,
then
x_b128 [*]_b64 y_b32
is permitted, if the underlying FP system supports b32, b64 and b128 FP formats. It evaluates, in principle, the exact product of the two operands and returns a binary64 infsup interval (preferably the tightest) containing that product.
On the other hand
x_d64 [+]_b64 y_b32 or x_b64 [/]_d64 y_b32
mix up the radixes and are not permitted.
An advantage of (point,point) -> interval is that it allows a P1788-oriented resolution of "what is the result when some input is not a finite real?" Whereas, if we take Ulrich's route we may find ourselves struggling with Qs like
"What is the result of Inf-Inf in round-away from zero mode?"
which is definitely not what P1788 was set up for.
Michel, Vincent, other people who work at the lower level: Would such a set of operations be the right sort of compromise between too low-level and too high-level?
I aim to propose a motion on these lines, and offer it as a friendly amendment to 24.03. Suggestions on wording welcomed.
Regards