Re: Amendments to Motion 6, version 3
John Pryce schrieb:
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.
Waht about ``function taking real arguments''?
--------------
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.
I support the proposition.
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.
Rather, I'd intersect thwe results, and might get a tighter interval...
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.
I think it should not be enforced. There have been famous instances of
nonisotonic implementations (Triplex arithmetic, the first hardware
interval arithmetic, implemented on the Hydra in Karlsruhe). Also, it
is quite nontrivial (and certainly suboptimal) to implement correctly
rounded midrad multiplication in a guaranteed isotonic way.
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?
Motion 6 should leave it open, as it does at present.
My feeling is that the standard probably needs a section on "Quality of
Implementation Issues".
Probably yes.
Arnold Neumaier