(j3.2006) Interval arithmetic
Malcolm Cohen
malcolm
Wed Mar 18 02:52:44 EDT 2009
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.
More information about the J3
mailing list