(j3.2006) Interval arithmetic

[Malcolm Cohen]

Robert Corbett wrote:
> How would floating-point constants in interval expressions
> be handled?
You ask this as if it were not already one of many features of interval 
arithmetic discussed at length, argued over, and several solutions 
advocated for, at the time.  Actually I don't think any of the solutions 
to this problem got universal acceptance.

>   The standard requires the value of a constant
> to be independent of the rounding mode.  That would appear
> to be a problem for a proper interval implementation (it
> violates containment).
>
>   
If you mean mixing intervals and normal floating-point in a single 
expression, one obvious possibility is to promote the floating-point to 
an interval by widening to +/- one ulp.  That certainly has the drawback 
of unnecessarily widening the interval, even if only by a little bit, 
but it doesn't violate containment.  If you mean as a component of an 
"interval constructor", well the constructor function can round the two 
parts differently: again this might unnecessarily widen the interval.

That can be gotten around in most cases by providing character-interval 
operations, where the character string as the decimal representation is 
converted carefully - then we can certainly pick the narrowest interval 
that contains the decimal value.  (In theory one could use the ROUND= 
specifier and internal file input for this; in practice I'm not sure 
that would actually be reliable.)

It's slightly ugly and maybe counter-intuitive to have to put quotes 
around one's floating-point constants, but it was one of the workable 
solutions.

Maybe another of the suggestions was to disallow implicit conversions 
and require use of a conversion function instead: such a function could 
indicate whether the value was exact or approximate.  I'm sure I heard 
someone suggest something like this, but I don't think this got anywhere 
though.

I'm sure I heard someone advocate what amounted to a Lispish "special 
form" for interval constants, but that got nowhere even faster than the 
other suggestions.

If you want to put these things into initialization expressions, well 
that's a whole other can of worms.  Certainly it could be done - with 
program-load-time initialization by implicitly calling some user 
functions for example - but it got nowhere because lots of people didn't 
want to require that.

Anyway, we didn't actually add intervals, nor did we satisfactorily add 
features to make it easy+efficient to have a user implementation.  It 
actually being possible to do this at the user level already, even if 
clumsy and inefficient, didn't help with the motivation to make it easier.

I seem to recall at one time we were going to add directed-rounding 
arithmetic operations to help with this, but somehow the people 
concerned ran out of enthusiasm or couldn't get agreement on the syntax 
or something.  I'm not sure why we didn't just add a bunch of extra 
intrinsic functions, or intrinsic module functions, but the last 
proposal I recall had hideous infix operator syntax.

There certainly are lots of fine details of various things that are 
tedious to get right at the very least.

Cheers,
-- 
..........................Malcolm Cohen, Nihon NAG, Tokyo.