Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion 10 -- elementary functions



> Date: Mon, 30 Nov 2009 18:33:59 -0500
> To: stds-1788                           <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack                                 <hack@xxxxxxxxxxxxxx>
> Subject: Re: Motion 10 -- elementary functions
> 
> >> ... my question about ranges with unrepresentable endpoints ...
> 
> Dan Zuras replied:
> > 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.
> 
> My problem is that I don't know how to interpret the specification
> of the range of the point function whose interval hull is to be
> used when computing the interval result.
> 
> Let PI be the closest floater not exceeding mathematical \pi.
> For binary64 and a value near 1.5, one ulp is 2^-52.
> 
> Take atan(x), whose given range is (-\pi/2, +\pi/2), for an argument
> x that exceeds tan(PI/2) -- i.e. an interval with values greater than
> about 2^52, a quite moderate floater.  Should the result then include
> nextup(PI/2), or should it stay within the specified bounds and return
> the equally valid -PI/2 which *is* within the specified bounds?  After
> all, the reflected just-out-of-bounds angle is just within bounds:
>    let PI/2 = \pi/2 - eps, with eps < ulp
>    the next floater after PI/2 is PI/2+ulp = \pi/2-eps+ulp
>    this reflects to PI/2+ulp-\pi = -(\pi/2 -(ulp-eps))
>    which is inside (-\pi/2, +\pi/2)
> 
> It is this ambiguity in the specification that I would like to
> see cleared up.
> 
> Michel.
> ---Sent: 2009-12-01 00:21:02 UTC

	I understand the problem, Michel.

	I'm sure you remember it was one that vexed us greatly in
	754.

	But your problem is a conceptual one.  And a conceptual
	problem with the point function.

	The point function is not being defined here.  The interval
	function is being defined.

	And if the number ONE, overriding everything else, rule for
	intervals is containment, then such functions MUST return
	intervals that contain the results even if that interval
	is slightly outside the range of the function.

	Because there is no narrower interval that is correct.

	While I don't think of this as a property of the motion 10
	functions or even more commonplace interval functions, you
	are probably correct that some statement could be made to
	clarify the matter.

	If so, let it be a simple "this seemingly odd thing can
	happen because its the best possible answer".  Let it be
	placed outside the table & not attached to any particular
	function.

	Then let it be of no further concern when you consider the
	merits of this motion.

	Would that be sufficient?

	Would you care to write that statement & propose it as an
	amendment?  I will support that.


				Dan


	P.S. - BTW, I erred in my earlier example.  I said that
	an expression like

		zz = tan(atan([10^10,10^50]));

	would return zz = [entire] if pi/2 rounded up in the
	working precision.  It turns out this will happen whether
	it rounds up or rounds down.  Containment will require
	the larger of the two representable numbers to be returned
	as soon as the true arctangent lands in between the same
	two representable numbers that surround pi/2.  And, as
	Michel points out, quite modest numbers are sufficient for
	that.  So 10^50 would qualify for any working precision of
	less than, say, 48 or 49 digits.

	Let me ask a question of the collective expertise out there:
	As this problem is much like the manifold jump problem we
	discussed a couple of weeks ago, is there some general
	strategy for managing such discontinuities without losing
	containment?  Or is the problem fundamental to intervals
	as a method?

	Just curious...


	P.P.S. - I just realized that since motion 8 has passed
	this result would be decorated with something like
	{[entire],discontinuous} or even
	{[entire],discontinuous+unbounded}.  We have no
	decoration for 'outOfRange'.  Do you think we need one?