Guillaume Melquiond <guillaume.melquiond@ens-lyon.fr> 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 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 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.
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