Re: Motion 10 -- elementary functions
> Date: Mon, 30 Nov 2009 15:07:46 -0500
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Motion 10 -- elementary functions
>
> The revised version 10v2.1 looks nice -- except that I don't see how
> my question about ranges with unrepresentable endpoints was addressed
> for the arctrig functions.
>
> This problem becomes acute when we consider several precisions, because
> when converting a result to a higher precision, legitimate values could
> be left out if the listed range was respected strictly in the lower
> precision. So I suppose the listed range should imply outward rounding,
> i.e. use PI/2 instead of \pi/2, where PI is the floating-point number
> closest to but not smaller than mathematical \pi. This may then include
> several representable values outside the strict range when converted to
> higher precision -- but over-inclusion is often to be expected in IA.
>
> I would also prefer to see "compound-1" instead of compound, for no
> loss in general and greatly improved precision for small arguments.
> (Others have made this point already.)
>
> Michel.
> ---Sent: 2009-11-30 20:20:32 UTC
Michel,
I agree this is a problem.
Even that the problem is made worse by conversion from one
precision to another.
But I would not characterize the problem as an acute one
for us for a couple of reasons.
First, it is typically only a problem if the sequence of
expressions takes one through an arctrig function, further
manipulated with perhaps lesser precision, & then taken back
through a trig function with its smallest pole at an
unrepresentable point. Since the only such trig function
is tangent & since the entire sequence of expressions must
be considered questionable from an intervals perspective,
I suspect that any such user will have to take special
action in the neighborhood of such a problem.
Then, there is the fact that there is nothing we can do
about it. Even a library of correctly rounded (& containing)
functions will suffer from this problem near such a pole.
Indeed, an interval expression as simple as
zz = tan(atan([10^10,10^50]));
will surround the pole if inclusion is to be maintained &
pi/2 rounds up in the working precision. A user that is
expecting zz = [10^10,10^50], or zz = [10^10,+oo] at least
approximately might be surprized if zz = [entire] but it is
in the nature of the calculation not in the nature of the
definition of our trig or arctrig functions.
Therefore, I would have to say that motion 10 IS addressing
this problem as best it can in that correct containment is
the correct answer in this case.
It is true that it might not be what the user expects. It
is true that it might be inconvenient & might have to be
addressed by the user.
It is also true that it is not an acute problem for us.
IMHO, of course...
Dan