Re: motion elementary functions
> Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: Re: motion elementary functions
> Date: Tue, 13 Oct 2009 16:21:39 +0100
> To: J. Wolff v. Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> Juergen, and Dan asking for explanation
>
> A.
> On 13 Oct 2009, at 11:09, J. Wolff v. Gudenberg wrote:
> >> 3. compound(x,n) should be defined compatibly with pown(x,n).
> >> After all, mathematically it's the same as pown(1+x,n). But if
> >> numerically accurate evaluation is what's wanted, surely compound
> >> should be the function (1+x)^n - 1 ? For exactly the same reason
> >> one wants expm1.
> > that compound is from 754 standard
It is a fair criticism & something along the lines
of a compound1p WOULD be generally useful.
Indeed, besides returning (1+x)^n - 1 more accurately
than compound(x,n) - 1 in the case where |n*x| is
small relative to 1 it could replace compound in all
cases as it turns out that compound1p(x,n) + 1 is
as accurate or better than compound(x,n) in almost ALL
cases, even when the result is large compared to 1.
The only exceptions are when the compound1p is so
large that the roundoff error is larger than 1. And
even in that case the extra error will only be as
large as a ULP.
> >>
> So it is. I had not noticed it before. So far it seems only
> marginally useful to me. Numerically, its only use is when |x| is
> small. Then, when |n| is large enough that |n*x| is comparable with 1
> or larger, it is useful because y = (1+x)^n is quite far from 1 and a
> relative error of ~1 ulp doesn't matter for typical uses. But I
> should have thought it might often be used when |n*x| is << 1 and
> even comparable with macheps. Say, xd is compound interest on a daily
> basis and you want to convert it to a weekly basis xw. Then the
> formula is xw = (1+xd)^7 - 1. With current US rates xd \approx
> (1.0/365), this will NOT be well done using 754's compound()
> function, especially in single precision, because of cancellation in
> the final "- 1". If the "- 1" is part of the function this can be
> avoided.
It is not necessary for |n*x| to be small relative to
the machine epsilon for (1+x)^n - 1 to be innaccurately
computed by compound. Roughly speaking for every bit
that |n*x| is small relative to 1 there is a bit lost
in the computation of (1+x)^n - 1 as an expression.
So, while it is not mathematically necessary for us to
have compound1p hanging around, the numerical issue for
floating-point translates to an interval width issue
for 1788 which is improved by using compound1p.
>
> I am also baffled why 754 says compound(x,n) is undefined for x < -1.
> But, apparently allowed for x > +1.
>
> Any ideas? I am cc-ing to Dan Zuras to see if he can explain.
(It is not necessary to cc me. I'm on the list. :-)
You are quite correct. compound(x,n) is formally
equivalent to pow(1+x,n) & defined everywhere the power
function is defined. It is computed differently then
pow as we are concerned with the case where 1 + x
suffers from a roundoff error due to |x| being small
relative to 1.
The restriction was a conceptual one rather than a
mathematical one. Compound interest is meaningful for
all x > 0 in the financial domain & for -1 < x < 0 in
the domain of radioactive decays. But, even if defined
for x < -1, it has no meaning in this context.
Still, the restriction could be removed & harm nothing.
Remember though that x^y has an essential singularity at
x = y = 0 & so all power related functions will suffer
similar troubles. In the case of compound, at x = -1 &
y = 0.
BTW, part of the trouble in defining x^y among the
floating-point numbers is in deciding whether 0^0 is
1 or NaN. There are arguments both ways.
But in the interval domain it is easy to define xx^yy
when 0 \in xx & 0 \in yy: The answer is [entire].
And there are famous theorems to support that.
>
> B.
> >> Typo: in logp1 you have written Latex ln instead of \ln
> > by the way the function name is logp1 in 754 and log1p in C
> > what to do ?
>
> Oh dear, a nuisance. But I think 754 must have decided this renaming
> is necessary because they support log2 & log10 as well as natural
> log. We really can't use
> log1p, log21p, log101p.
> So those million Unix users will have to put up with it.
You have it exactly. It was a name space problem
for which logp1, log2p1, & log10p1 were our less than
perfect answers. We can but try. :-)
>
> C.
> Your list says the range of tanh is [-1,1] (correct for 754), but in
> our context it is (-1,1).
This one is subtle but you are mathematically correct.
However, numerically, there are surprisingly small
intervals (as small as [-86,86] in double precision,
I believe) for which the correctly rounded & containing
result will be [-1,1].
(Similarly, there will be surprisingly narrow intervals,
say [100,100+eps] for which the correct interval result
is [1 - eps,1] even though the ENTIRE mathematical range
of that result is crammed up so close to 1 as to make
the rest of this already narrow interval seem lonely. :-)
So how should we say it? Shall it be (-1,1) & be
mathematically correct? Or shall it be [-1,1] & be
what the user sees commonly as an answer with otherwise
no errors?
I could go either way.
>
> D.
> Finally (for now) I am surprised you left out the 754 functions
> sinPi, cosPi, atanPi, atan2Pi
> which IMO are MUCH more important in the interval context than in the
> floating point context.
>
> Cheers
>
> John
Well, as I said, everyone has an opinion on these things. :-)
These functions were included in 754 primarily due to
their presence in Sun's math library. They are IN that
library on the grounds that the evaluation of circular
functions to known multiples of Pi (or, more of
concern to the Sun guys, multiples of Pi/4), suffer
from roundoff error when a machine value of Pi is used
in a call to sine or cosine.
While, in principle, that numerical error translates to
a slight width expansion in the interval domain, in
practice it would only be noticed if the interval were
a singleton or having endpoints that are multiples of
1/4.
Given that intervals are best used in work that involves
contraction maps of continuous functions, it seems to me
that this case would typically come up only in passing
& would otherwise go unnoticed.
I could be wrong.
Your mileage may vary on this one. :-)
Enjoy,
Dan