Putting features in vs. leaving them out, especially functions
Dear P1788
As I revise Level 1, I'm very aware that P1788 is of several minds about where we should sit in an interval with "hardware standard" at one end and "language standard" - or is it "applications"? - at the other. (Not very well put: anyone who can say it better, please do.)
I'm thinking just now of what operations (standard functions) we include as Required or Recommended.
- See George Corliss's comment of Feb 2010 below, which positions us toward the hardware end.
- See Nate Hayes's comment of 22 May below, and did he say a few days earlier that +, -, *, /, sqrt
are the only operations that really interest him? Correct me if wrong, please, Nate.
That would position us even nearer the hardware end.
- On the other hand we have Juergen's (Motion 10) list of operations.
- Required: +, -, *, /, sqr, sqrt, pown, pow; 3 kinds of each of exp, log, exp(x)-1, log(1+x);
13 trig and hyperbolic functions and inverses; abs, 1/sqrt(x), hypotenuse, compound.
- Recommended: sign, ceil, floor, round, trunc; x^(1/q), x^(p/q); sin(pi*x) & 6 relatives;
5 relatives of (exp(x)-1)/x; gamma, error function & 2 relatives.
Which position us nearer the language end.
My view is in between. At the risk of exposing my vast ignorance in this area:
1. There should be a core of P1788 that is easily put into hardware. (OK you experts, I
know that's a vague statement.) But we should EXPECT P1788 to have much, even of Required
stuff, that no one will think it economic to put in hardware soon, or maybe ever.
2. Initially on mainstream architectures, P1788 will be implemented entirely in software
(C++ libraries etc.) apart from underlying 754 arithmetic support. We hope it will be
successful enough that performance-critical parts will migrate to hardware in due course.
On specialist architectures, like Nate's machine, a P1788 compliant system will be a mix
of hardware and software.
3. Back to Required/Recommended operations. Much of this is gut feeling. Looking at
the current Motion 10 list, and discussions on Motion 11:
- I rather disagree with George on reverse operations. Constraint Programming seems
an important application (I know little about it) and it needs operations of
the form "enclose the set of all x in xx for which f(x) is in yy" where f is some
elementary operation. In CP applications I guess these are performance-critical;
if so, that seems a reason to have them in the standard.
- Stuff like gamma and error function seems to me too close to the language or
application end. Stuff like (1-cos x)/x^2: people to whom these are important are
competent enough to code them themselves; they are unlikely to be performance-
critical. I think all these should be dumped, even from the Recommended list.
- Stuff like atanPi overcomes some annoying widening, e.g. atanPi([1,1]) is computed
exactly while atan([1,1]) cannot be. Seems useful in many areas including graphics,
so should stay.
- Should sign, ceil, floor, round, trunc be moved from Recomm to Required on the grounds
that they are fairly trivial to implement? How often do interval applications actually
use them? E.g., are some of them used in graphics to pixel-ize an image?
- Hyperbolic functions and their inverses are used much less than trig functions.
Should they move from Required to Recommended?
Full of ignorant prejudice, probably. Maybe we should invent a scoring system to
determine what operations to keep or discard.
Your views please.
John
On 16 Feb 2010, at 01:50, Corliss, George wrote:
> I'd like to offer a mild argument AGAINST Motion 11. I prefer a standard as simple as possible, but that still provided intervals.
>
> I agree that reverse interval operations are useful; I have programmed and used them, too.
>
> If this were a programming language standard, I would accept reverse interval operations.
>
> However, P1788 is intended as primarily a hardware (or hardware-like) standard. Vendors are more likely to implement our standard if there is a clear market. The fewer features we write into the standard, the easier it is to implement.
>
> If we add all the features any of us would like to see, we may end up with such a feature-rich standard that it is to heavy to implement and too hard to document a compelling market need for every feature. The outcome I fear is an un-implemented standard.
>
> Any market survey people or hardware implementation people are welcome to make the opposite case.
On 22 May 2011, at 04:11, Nate Hayes wrote:
> Hi Vladik,
>
> IMHO, it seems you understand the most important aspects, particularly when you say about straightforward interval computation:
>> "The resulting enclosure is often too wide. There exist much more efficient
>> techniques (such as the mean value form); see, e.g., [1]. However, straightforward interval computation is important, since most efficient techniques for computing the desired range y use straightforward interval computations on intermediate steps."
>>
>
> In my perspective, it is straightforward computation that is within the scope of IEEE 1788 to standardize...
>
> On the other hand, it is the straightforwad computations on intermediate steps that can be implemented efficiently at the hardware level in an interval processor, as well as the neccesary property tracking with decorations. So I believe IEEE 1788 has a potential to be a very successful standard if it concentrates on this aspect.