# Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-12-08 07:23:43

Guillaume Melquiond <guillaume.melquiond_at_[hidden]> writes:

> Le mercredi 07 décembre 2005 à 11:21 -0500, David Abrahams a écrit :
>>
>> > The static functions empty and whole produce the corresponding
>> > intervals.
>>
>> "Produce the corresponding intervals" is almost content-free. It's
>> pretty easy to guess what the empty interval must be ([0,0] I
>> presume), but to someone not already versed in interval arithmetic,
>> guessing at the meaning of "whole" is a lot harder. What does that
>> mean?
>
> Because intervals are subsets of a given set, that is not as
> content-free as you seem to think.

Sorry, but it is. It's missing exactly the crucial information that
makes anything it says "contentful." The fact that intervals are
subsets of something isn't that information either; of course, I
and its special language. Substitute, say, "dance_step" for
"interval" (assuming you know nothing about dance steps). Now what if
I told you that empty and whole returned the corresponding
dance_steps?

> The documentation means that empty() generates the empty subset and
> whole() generates the subset

Of what? The universe of all possible intervals? This is a static
function!

> that is the whole set. Maybe the documentation should stress that
> something empty does not contain any element

Sorry, as I wrote that part is rather obvious; I just used the wrong
notation.

> and that the whole set
> contains all the elements. In particular, [0,0] is not empty since
> it contains 0.

Sorry, I meant ]0,0[ or something.

> If you want to express these intervals as pair of bounds [l,u], for the
> empty subset there must be no x such that l <= x <= u (by having !(l <=
> u) for example), and for the whole set, any x must verify l <= x <= u
> (by having l = -infinity and u = +infinity for example).

... okay, then you do mean the universe. So why don't you just tell
us that empty() includes no values of the underlying type while
whole() includes all non-NAN values of the underlying type? Or, if
you must, write your last sentence above, which, although seemingly
more complicated than necessary, at least has the crucial information
in it.

> But these representations are implementation-defined,

unspecified, actually.

> and for an UDT they may even be user-defined. This is why the
> representations are not directly described in the documentation.

```--