Amendments to Motion 6, version 3
P1788 members
Three points on motion 6.
--------------
1. Terminology
I have taken the suggestion by Vincent & Arnold that (abstract or
concrete) "floating point format" is better termed "number format"
and have made the relevant changes.
BTW does that mean "point function" in 3.5.4 should become "number
function"? I don't like that quite so much.
--------------
2. Supporting MRMF
On 7 Aug 2009, at 22:49, Vincent Lefevre wrote:
My current wording [on MRMF at the end of 3.7] is not ideal.
Vincent, will you suggest an
improvement?
I propose something like that:
Mixed-radix should be supported and an elementary function should
return an interval at least as tight as if the following operations
were done: each input is converted into the destination format, then
the single-format elementary function is applied on the converted
inputs.
This proposition by Vincent really belongs in the motion (and thus
specifies something about the standard-text) rather than in the
rationale.
Should it be part of the motion? Rather than have someone make a
formal amendment, which would take several weeks, I prefer a "straw
poll", where interested parties give their views over a few days, and
I take the result as a friendly amendment.
Against:
- I think 754 says nothing about mixed-radix arithmetic, except
implicitly in section 10 where it is assumed that language standards
specify some rules for doing it.
For:
- Vincent's text is a "Quality of Implementation" (QoI) requirement,
and such things are more important for an interval standard than for
a floating-point standard. It is quite mild: being at the level of
single operations (rather than expressions), it looks fairly trivial
to implement.
If, however, the text stays in 3.7 I would tone it down to something
like
If mixed-radix were supported then it would be reasonable to require
that an elementary function should ...
--------------
3. Isotonicity
Another QoI issue. I am uneasily aware that nothing in the
definitions made in the rationale of motion 6 require an interval
version ff(xx,yy,...) of a point function f(x,y,...) to be inclusion-
isotonic, that is
Making xx, yy, ... tighter makes the result tighter.
(Tighter is in the weak, set, sense, i.e. replacing by a subset, with
equality allowed)
But from a practical viewpoint this is very important. As a user, if
I do something that makes the inputs to some expression tighter, and
find the output is _not_ tighter, I shall suspect a bug, and my
confidence in the implementation will be reduced.
Clearly, any function implemented in "tightest" (Vienna) accuracy
mode is isotonic, and any expression built from isotonic functions is
isotonic; but I don't know how easy it is to achieve isotonicity in
non-tightest modes.
Elementary function experts: can you tell us the score on this one?
What should the standard say about this? Is it relevant to motion 6,
or does it belong elsewhere? If the latter, would someone like to
draft a motion about this?
My feeling is that the standard probably needs a section on "Quality
of Implementation Issues".
Again, I should like a straw poll on this, leading to a possible
friendly amendment to motion 6 or its rationale.
--------------
Chair: will you consider extending the discussion period appropriately?
Best wishes
John Pryce