Re: Uncertainty is essential?

["Corliss, George" <george.corliss@xxxxxxxxxxxxx>]

John and all,

On Jan 24, 2014, at 6:45 AM, John Pryce <j.d.pryce@xxxxxxxxxx> wrote:
> The following is just a "for-instance" but illustrates the point well. Take tan(x), which has a singularity at each odd multiple of pi/2. Let
>  p = 214112296674652  (probably an old friend of Vincent Lefevre's).
> This is very close to s=q*pi/2 (s for singularity), where
>  q = 136308121570117.
> In fact
>  s = 214112296674652.000000000000000259...
> 
> p is exactly representable in F (is an F-number); so are p-1, p+1. Hence the intervals
>   zz = [p-1,p+1], xx = [p-1,p],  yy = [p,p+1]
> are exact T-intervals. Since p+-0.5 are F-numbers too, this is also true if T is a mid-rad type.
> 
> Suppose we are doing a bisection algorithm. To check that a singularity of tan() lies somewhere in zz is easy in F-arithmetic. But checking which half it's in, xx or yy, is not so easy. Suppose we are working on xx; our best efforts to find whether s is inside xx fail; so we signal an exception E.
> 
> Does E tell the programmer "xx contains a singularity"? If it does, then knowing there is only one singularity in zz, she can logically conclude "yy does NOT contain a singularity", which is false as you can see from the numbers above. To avoid making false statements, the only thing E can say is "I am unsure whether xx contains a singularity or not”. 

We want intervals to come with guarantees.  In well-behaved examples of this sort, we guarantee good behavior, there is no singularity. 

In this example, I prefer to think of it as, “I am unable to guarantee good behavior,” rather like sending your teenage (or adult) children off on a date.  The behavior in the interval in question might be good, or there might be a singularity. Although I have done everything in my power, I do not know what happens.

I think the exception is a failure to guarantee.  That is a positive spin on “I don’t know."

> 
> I conclude: exceptions that assert uncertainty are inseparable from bare interval arithmetic, if we are to avoid lying. And this is true in any flavor, for any type T capable of serious computing.
> 
> Points:
> - For (our) decorated intervals, this is a practical issue but *not an issue of principle*, because they handle uncertainty simply by downgrading a decoration, e.g. from dac to trv.
> 
> - I guess (our elementary functions experts would know) that similar examples exist in any precision.
> 
> - It might have been a good idea for P1788 to standardise on tanPi(x) = tan(Pi*x), and similarly for other trig functions. But it's too late for that, and probably just shifts the difficulties elsewhere.
> 
> Some in the group have argued that only decorated intervals should exist. But I think most folk want bare intervals to be available, for performance reasons. 
> 
> Therefore it seems to me that the Flavors clause should build in an exception that says "I'm not sure" into the foundations of the standard for all flavors.

Is this a variant of long-standing three-valued logic?  Here, the three values are
   NO singularity, guaranteed;
   Interval includes a singularity, guaranteed (probably takes more advanced analysis to assert); or
   I don’t know.

Analogy:  IF (x < y).  If x and y overlap, the “Boolean” value is “I don’t know.”

Similar in the example you offer.

George Corliss

> 
> I don't see an essential difference between this and the "IntvlConstructorUnsure" exception we already have, so unless persuaded otherwise I'll submit a motion that the latter be renamed "PossiblyUndefinedOperation" or similar. Similarly, that "IntvlConstructorFails" be renamed "UndefinedOperation", and these be used by any operation whether constructor or not, in any flavor, in suitable defined situations.
> 
> Jumping the gun, I'll put this into the revised Flavors Clause 7.
> 
> John Pryce

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail