Re: Undefined behaviour (Was: Definition of intervals as subsets...)
On Sun, Mar 15, 2009 at 10:26 AM, Michel Hack <hack@xxxxxxxxxxxxxx> wrote:
> Gabriel Dos Reis wrote:
>> We are dealing with computational mathematics. I find it hard to
>> believe that 'it does what it does' is an acceptable description
>> in a standard for interval arithmetic.
>
> All I was saying that there are circumstances where "undefined" or
> "boundedly undefined" is the right thing to do. They should be of
> a kind that can be avoided by the programmer, so no harm is done.
>
> Suppose the standard includes a computational method that applies
> to vectors of intervals. In practice those will be structures in
> memory. A full specification would have to cover the case where
> the inputs overlap, or worse, overlap the result. This *can* be
> defined, e.g. by stating explicitly the sequence of memory accesses
> that must be performed by the method (subject only to the "as if"
> licence), but would that be useful? It could be quite a burden on
> the common case, and prevent vectorization.
Aliasing is something that is best left to programming language bindings.
I don't think it is something the interval arithmetic standard has to specify,
or something that falls squarely in its domain.
The interval arithmetic standard should be specified in a
programming language neutral manner -- even if some of us
have current mainstream programming languages in mind. It
is the job of specific bindings -- such as the C++ interval
arithmetic effort -- to define a faithful mapping from the
interval arithmetic standards to the target language semantics.
[...]
> In other words, overspecification *is* something to watch out for.
Yes, I agree. And I think the fact that we think we have to
define some behaviour as 'undefined' should remind us that
maybe we are overreaching/overspecifying.
-- Gaby