Re: [Fwd: ISL: M0010.02 Elementary Functions]
> Date: Tue, 24 Nov 2009 10:41:14 -0600
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: [Fwd: ISL: M0010.02 Elementary Functions]
>
>
> To: ISL List <isl@xxxxxxxxxxxxxxxxxxxxxx>
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: ISL: M0010.02 Elementary Functions
> Date: Tue, 24 Nov 2009 14:58:48 +0000
>
> P1788
>
> I think the voting period on motion 10 is nearly on us. Discussion on
> it seems to have been nonexistent since 10th Nov, or have I missed
> something?
>
> On the required functions, I like everything except
> - compound. Only "recommended" in 754, and it seems not to give
> much numerical benefit. It loses a lot of information in x
> when x (and n) are small. If it were defined as (1+x)^n - 1,
> I see the point.
> As it's in 754, I suppose we can't change it, so I support
> moving it to "recommended".
As the only reason for compound to exist is to be
more accurate than pown(1+x,n), this is an excellent
suggestion. If (1+x)^n - 1 is called compoundm1(x,n)
then it is almost everywhere more accurate than the
expression compound(x,n) - 1 & no where less accurate.
Further, the expression compoundm1(x,n) + 1 is within
a rounding error of compound(x,n) everywhere.
If both are recommended or if at least compoundm1 is
required, I think it would serve us well.
> - rSqrt. Maybe I just don't know what application crucially
> requires the extra ulp of accuracy this may give compared
> with doing 1/sqrt(xx). At present I support moving it to
> "recommended", but am persuadable.
The reason for this to exist is to provide normalization
in homogeneous transformations. Things that take
(x, y, z, w) into (x, y, z, w)/sqrt(x^2 + y^2 + z^2 + w^2)
by doing (x, y, z, w)*rSqrt(x^2 + y^2 + z^2 + w^2).
It is commonly used in graphics & is there more for speed
than accuracy (to avoid the often not parallizable divide).
The last ULP is seldom needed in graphics. An interesting
exception is tracing a ray as it bounces off of multiple
quadradic surfaces as between two reflecting spheres. But
even in this case, correct rounding only buys you
consistency not correctness. And the eye cannot see the
difference if the calculation is at least double precision.
I agree this could go into the recommended list but Nate
is the expert in this area. Nate: what are your thoughts?
>
> In the "recommended" list
> - I applaud the inclusion of sinPi and its kin, despite Dan Zuras's
> disapproval.
Let's call it a preference more than a disapproval.
I find them unnecessary but I wouldn't vote against
a standard that recommended them. Indeed, I once
voted FOR a standard that did. :-)
> - I think exp1 should be (e^x-1)/x, not (e^x-1-x)/x.
> And atanPi is defined as \atan(x)/\pi, not \atan(x)\pi.
> And atan2Pi needs a definition entry.
> - It might be good if the authors make the "range" column of Table 2
> consistent ("sign" has range as interval function, the others as
> point functions). And make Tables 1 & 2 consistent with each other.
> Personally I find the Table 1 "interval function" column not very
> helpful and actually wrong in some ways. E.g. asin is defined on
> _any_ interval according to the definition of interval extension
> in section 1.1 -- not just on members of I[-1,1].
> So maybe Table 1 should revert to just a "range" column?
> - Nate Hayes makes a good point arguing for "nint" and "trunc" in
> addition to "ceil" and "floor", so that all four rounding modes are
> catered for.
Agreed.
My personal preference would also be to make these required
rather than recommended but I come to that opinion from a
background in floating-point algorithms. As is often the
case, I don't know how that experience translates into the
needs of the interval world.
>
> As for Dan's general power, I don't like it. As an interval function
> it seems "neither fish, flesh nor fowl, nor good red herring".
What can I say? It is as you describe it.
It is the only way I could think of to find a subsumptive
function that can stand for all of pow, pown, & powr for
intervals. In 754, pow tries to serve that purpose for
floating-point but it does so badly.
I frankly don't know how useful a gpow for intervals would
be for us. None of the other 3 functions always preserves
the principle that the correct answer is contained within
the result in the most general case either by definition of
the result or restriction of the domain. But the context
of any given interval method might 'know' which answer is
sought well enough that the programmer also knows which
power function to call to get it.
Again, this is out of my area of expertise.
>
> At present I expect to vote
> M0010.10 List of required functions NO for reasons above.
> M0010.20 Postpone details YES
> M0010.30 General power NO for reason above.
For the moment, my preference is to vote opposite on all
3 choices on the grounds that it is a good list of functions
even if I disagree with one or two items.
We are only at the beginning of the standard's process.
As we continue to specify things we will have more & more
knowledge about what is needed & what is not. This can
be changed by some new amendment down the line.
We have plenty of time for that.
Yours,
Dan