Re: Definition of intervals as subsets of R - the bad news
On Mon, Mar 16, 2009 at 5:46 PM, Ian McIntosh <ianm@xxxxxxxxxx> wrote:
>
> Sometimes "undefined behavior" is appropriate. A C example showing why
> accessing the wrong side of a union is undefined is
> union {
> float f;
> char c [4];
> } u;Min Wu
> char first;
> u.f = 1.0f;
> first = c [0];
We are talking about computational mathematics, not a type
system that is weakly checked. One can conceive of
more strongly checked realistic alternatives.
> That's undefined for several reasons:
> 1. Not all computers use IEEE 754, which didn't exist until a decade and a
> half after C. So C can't and doesn't rely on 754 semantics and the float
> representation is undefined. In particular:
> 1a. The number of bytes in a float isn't specified. That doesn't
> matter here but would in other examples.
> 1b. The size and position of the sign, exponent and fraction in a
> float isn't specified.
> 1c. Whether a float is normalized isn't specified.
> 1d. The base of a float (binary? decimal? hex? other?) isn't
> specified.
> So accessing the first byte gives results that depend on the machine
> architecture.
I find that unconvincing -- yes, I know what the C standard says.
If all that matters is the representation of float, there are ways to
get to that information than issueing a wide 'undefined behaviour'.
> 2. Some computers are big endian, some are little endian, and some are
> mixed endian. So even if you know "float" means "IEEE 754-2008 binary32"
> and understand the bit pattern for 1.0f, you don't know which byte of that
> bit pattern is being accessed. Computers have been built where it would be
> three of the four possibilities. The byte ordering is undefined.
Again, I find that unconvincing argument. Primitive for
byte ordering information could be added to the language.
Failure to do so is not something to be proud of or to
exhibit as 'example'.
> 3. The size of a char isn't necessarily one 8 bit byte. The size of a byte
The size of char is guaranteed by the C standard to be exactly 1byte.
There is no semantics distinction between a byte and char.
> isn't necessarily 8 bits (eg, C can run with a 36 bit word of 4 9 bit
> bytes). So the number of bits included in what's stored in first is
> undefined.
Again, that has nothing to do with the subject matter.
> C programmers handle that, usually by relying on implementation defined
> functions and values. Java was intended to give the same answers
> everywhere, so omits unions from the language. As a result, if you need
> access to details like the exponent of a float, you use functions written in
> C.
Or you can provide primitive operations -- see how we have done
that in GCC. I don't quite understand why C's deficiencies here
are example to follow.
> Each approach has its advantages.
Yes, but I've not seen any convincing example of why the
interval arithmetic standard should not aim at avoiding
'undefined behaviour'. Note that I'm not talking about
programming language semantics. My concern is the rules
that would be put forward for a model for reliable computations.
-- Gaby