Re: Motion 31 draft text V04.4, extra notes
Dmitry & P1788
At last I'm catching up on recent discussions.
First let me say I agree with criticisms I've seen of the Motion 13 Comparisons text in §5.6.9. They *need* definitions from first principles in terms of sets, rather than endpoints. If we don't have that then how they act on empty and unbounded inputs is likely to be ad-hoc and possibly contradictory. I'm just discussing with Vincent on revised text.
On 20 Mar 2012, at 11:59, Dmitry Nadezhin wrote:
> 1) p.10. Section 4.1. ... "Level 2 arithmetic normally acts on intervals of a given type
> to produce an interval of the same type."
>
> Is this important ?
> The level 2 draft defines level 2 interval operations op_T(x, y) = hull_T(op(x, y)).
> So definition
> op: T1 X T2 -> T
> is as easy as definition
> op: T X T -> T
I'm not so interested in how easy it is to *define* as how easy it is to *implement*. I should hate to implement, in "tightest" mode, something like
op: decimal64 X binary32 -> binary64
(meaning infsup in each case) let alone operations involving several exotic implicit types.
> Could we omit this phrase or append to it something like this :
> "... , but interval operations that act on intervals of types other than the result type are always possible".
But I'ld accept this amendment.
IMHO the only mixed type operations that should be *mandated* by Level 2 are where
- Types T1, T2 and T are inf-sup types derived from IEEE754 formats
- of the same radix
- such that the underlying implementation supports "formatOf" for the
corresponding point operations, in the needed rounding modes;
because these essentially come for free (I believe).
> 2) p.12. Section 5.2. "Excluding Empty is indicated by the notation I, e.g. \underline{I}R or \underline{I}(R), the nonempty closed intervals with
> (finite) real bounds.
>
> Maybe "Excluding Empty, Entire and semi-infinite intervals ... " is more precise ?
Yes, I'll do that.
> 3)p. 18 Table 2 and p.20. Table 3. "recip" or "inv" ?
> Table 2 names inverse function as "recip" and Table 3 names it "invRev".
Good point. I think I'll go for "recip" since someone, Juergen I think, would like to rename the "reverse" functions as "inverse" functions.
John Pryce