Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Amendments to Motion 6, version 3



On 2009-08-08 08:24:55 +0100, John Pryce wrote:
> 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.

I don't see any reason why this one needs to be changed (if this is
because the word "point" has disappeared, this is not a good reason
since "point" has two different meanings in "floating point" and in
"point function").

> >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?

I think so.

> 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.

However floating-point arithmetic (with correct rounding) and
interval arithmetic are completely different arithmetics (IA is
at a higher level).

> 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.

Yes, I think this is quite an important property. But...

> 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?

If monotonicity is not guaranteed (in domains where the real function
is monotonic), isotonicity may be difficult to guarantee. So, I'd say
that isotonicity should only be recommended.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)