Re: As simple as it is now, I am still against motion 24.03...
Vincent, Michel & all
On 13 Jun 2011, at 11:55, Vincent Lefevre wrote:
> On 2011-06-11 12:03:41 +0100, John Pryce wrote:
>> 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 don't think the number of operations is reduced (or what do you mean
> by that?).
I was thinking that for a given math operation, say a+b, one would not require all of round toward +oo, round toward -oo, round toward 0, round away from 0 as separately specified operations. The SINGLE operation a[+]b = "tightest interval containing a+b" is provided (for a suitable variety of formats). It is easy for the low level programmer to extract, from that, the point result in any of those 4 rounding modes.
Michel, of course this is a compromise. I thought I roughly understood your position but now I don't. Please
- Be more specific on the "sharp tools" you DO want (see quote below).
- Tell us how often a[+]b-type operations slow your algorithms down because you really want "round_down(f(x)) and round_up(g(y))" as you wrote on June 11. More than 50% of the time? Less than 20% of the time? In between?
- Suppose a fast coprocessor, on the lines of the old 8087 but for intervals, became available for under $100. (Juergen indicated to me a while back he thought this very feasible.) Would that change your view?
Another thing. Forgetting computation speed, suppose you are asked to implement a portable P1788 interval library for the standard functions exp, sin, atan2, etc. Would the availability of a[+]b-type operations (for +,-,*,/ sqrt and whatever else Arnold mentioned) significantly shorten the time to develop that product? Assume you are given other tools such as faithfully- or correctly-rounded point versions of exp, sin, atan2, etc.
If the answer is Yes, then I suggest the a[+]b-type operations are worth having, since they let one get a possibly slow, but portable, P1788-compliant library out of the door quickly.
On 10 Jun 2011, at 19:53, Michel Hack wrote:
> I can't speak for Joel, but I thought Joel raised the same issue I did:
> Some standardized primitives not strictly needed for end-user IA would
> be useful to implementers of IA libraries. Section 4.8.4 mentions the
> use of monotonicity arguments to compute tighter enclosures, but not
> how they would be used, thus perhaps implying that only IA primitives
> would be used...Experts like to have sharp tools...
I think Dan Zuras (11 Jun 2011, at 01:10) is right that it's not P1788's remit to require any such tools. Sadly, all we can do is recommend. And hope that market forces make them appear eventually.
Vincent wrote:
> Note that if x is a real, then [x,x] is a valid interval.
> As [x,x] must be supported, then it also makes sense to support just x
> as input. ... if not in tight mode, do you still require that f(x) and
> f([x,x]) should return the same interval? ...
I think so. Any problem in that?
>> I suggest that on 754-compliant systems the operations be
> Why 754-compliant systems only?
Because "formatOf" is explicitly provided in 754-2008, so on such systems this comes for free, if I read the standard correctly.
>> 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.
> I think that different input formats (whether in the same radix or
> not) should be optional (and not forbidden). Perhaps recommended for
> the same radix.
Sorry, yes, I didn't mean "forbidden" (and "not permitted", below), just not required.
...
>> 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 think that f(x), with x being a floating-point datum and the
> result being an interval, should just be regarded like f([x,x]),
> with similar constraints and so on.
Yes.
John Pryce