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
> 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
already knew that. Imagine you don't know anything about the domain
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
> 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
> 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
> 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
> But these representations are implementation-defined,
> and for an UDT they may even be user-defined. This is why the
> representations are not directly described in the documentation.
I don't care about representation; I care about semantics. The docs
don't tell me what the semantics are.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk