interval X**Y and exceptions generally

William Walster Bill.WalsteraEng.Sun.COM
Wed Apr 1 10:55:41 PST 1998


This is a duplicate of my last posting, which should not have contained
a postscript attachment.  Below is a pointer to the .ps file.

I am sorry for any problem my earlier posting may have caused.

Bill Walster

------------- Begin Forwarded Message -------------

Date: Wed, 01 Apr 1998 09:15:45 -0800 (PST)
From: William Walster <bill.walsteraeng.sun.com>
Subject: Re: interval X**Y and exceptions generally
To: neumacma.univie.ac.at, numeric-interestavalidgh.com, validghavalidgh.com
Cc: interval_allagww, eldonhaearthlink.net, sshanbsp.nsk.su
MIME-version: 1.0


Gentelmen,

For those on the numeric-interest alias who may be interested in the background
leading up to the present discussion, I have attached my earlier posting
to reliable-computing.  I have also added some interval people to this posting 
who I believe are interested in the discussion.

  >Date: Wed, 01 Apr 1998 08:22:35 -0800
  >From: validghavalidgh.com (David G Hough at validgh)
  >Subject: interval X**Y and exceptions generally
  >To: neumacma.univie.ac.at, numeric-interestavalidgh.com
  >
  >
  >I have been asked to cease and desist from discussing interval X**Y on 
  >reliable_computing, but there probably won't be an efficient and reliable 
  >commercial implementation of
  >interval methods, and certainly there won't be two interoperable ones, unless
  >the issues of interval exceptions are worked out correctly, if that's
  >possible.   The X**Y discussion raises the issues most acutely.    Exceptions 
  >are certainly a central issue for the numeric-interest mailing list, and so 
I'll
  >continue to discuss them here, although from the discussion so far,
  >one might suppose that there aren't more than half a dozen people in the 
  >world who care much.  But I think Polya said something to the effect
  >that the interesting stuff in mathematics generally 
  >is what happens on the boundaries rather than what happens in the middle.
  >
  >Back to the subject, it seems very odd to me that a source code segment
  >in intervals such as
  >
  >	X=-1.5
  >	Y=0.62
  >	Z=X**Y
  >
  >should yield a result Z slightly wider than [-(1.5**0.62),+(1.5**0.62)]
  >on the grounds that 0.62, not representable in binary floating point,
  >must be widened to an interval, which necessarily contains rational numbers
  >of the form odd/odd and even/odd, while
  >
  >	X=-1.5
  >	Y=0.625
  >	Z=X**Y
  >
  >should yield a result Z that is empty, or Not-an-Interval, or C*, depending 
on 
  >religious preferences, on the grounds that the exactly representable 0.625 
  >need not be widened and so X**Y has no real result.    
  >That's an odd kind of continuity indeed.
  
I am unaware of any prohibition on interval enclosures of non-continuous 
functions.

[empty] works well from the non-stop exception handling perspective, see below.
 
  > 
  >
  >The larger picture is that efficient implementations of interval +-*, with
  >inline code generation based on IEEE 754 point operations,
  >seem to be everywhere at odds with conservative or
  >flexible exception handling schemes.    Perhaps the interval field is not
  >yet ripe for IEEE 754-style nonstop default exception handling, and the 
  >appropriate default is termination on exceptions, in order to force 
  >appropriate selection of non-default exception-handling modes, 
  >or to force appropriate defensive coding.   However the meaning of
  >intervals containing signed zeros, infinities, and NaNs is not something that
  >one would want to change later, yet defining these intervals amounts to
  >deciding a lot about how exceptions are to be handled.   So deferring
  >decisions about exceptions pending wider usage of commercial products is
  >not completely feasible either.
  > 
  
I agree with the need to answer the questions raised.  My problem is that I 
don't see 
why the proposed extended real interval system and the Fortran specification 
based on it 
do not satisfy the basic criteria you list above, at least with respect to the 
present
discussion regarding X**Y:

	1) eficient implementation with inline code generation based on IEEE 754 
point
	   operations;
	   
	2) conservative and flexible (at the choice of the user) interval 
exception handling;
	
	3) non-stop default exception handling.
	
Sincerely,

Bill Walster
	


------------- End Forwarded Message -------------


------------- Begin Forwarded Message -------------

Date: Tue, 24 Mar 1998 09:55:57 -0800 (PST)
From: William Walster <Bill.WalsteraEng>
Subject: Interval enclosure of X**Y for negative x in X
To: reliable_computingainterval.usl.edu
MIME-version: 1.0


Friends,

For floating-point numbers, x**y is not defined for negative x and non-
integer y.  This is not true for an interval enclosure, X**Y, of x**y,
provided the width, w(Y) > 0.

Please review the development of a simple algorithm to compute the
enclosure, X**Y, please see

	The Interval Power Fuction, wich can be found at
	http://www.mscs.mu.edu/~globsol/readings.html#Walster
	 
If you see any problems, or have any suggestions, please send them 
to me.  I will be delighted if you can think of an application.

For a more detailed discussion of limit sets at singularities, please see:
"The extended real interval system" at the same URL as the one above.
	
Thanks in advance,

Bill Walster

P.S. I wish to especially thank David Hough and Arnold Neumaier for their
penetrating questions that stimulated the discovery of this algorithm.  Also,
I wish to thank Dmitri Chiriaev, Michael Ingrassia, Eldon Hansen, Ramon
Moore, and Arnold Neumaier for reviewing and suggesting improvements to
earlier drafts of the extended real interval paper.

P.P.S. If anybody has problems with postscript and needs a fax, please
send email.

------------- End Forwarded Message -------------





More information about the Numeric-interest mailing list