From: "Pavel Vozenilek" <pavel_vozenilek@hotmail.com> Date: Tue, 2 Aug 2005 16:43:56 +0200 Reply-To: boost@lists.boost.org Sender: boost-bounces@lists.boost.org
________________________________________________________ 6. Would it be possible to have other qualifiers, e.g.: "more_than_half_of"
if (more_than_half_of(a) >= any_of(b)) ...
or more complex versions like:
more_than(10).items_of(a) >= ... more_than(30.1).percents_of(a) == ...
less_than(2).items_of(a) >= ... less_than(95).percents_of(a) == ...
between(1, 5).items_of(a) >= ... between(10.5, 20.0).percents_of(a) == ....
exactly(10).items_of(a) >= ....
________________________________________________________ 7. Will it be possible to use other predicates than
, <=, etc in following form:
if ( is_true_that(all_of(a), a_binary_functor, one_of(b)) ) ...
where the functor could be lambda:
if (is_true_that(all_of(a), _1 >= _2, one_of(b)) ....
It feels more natural than the asymetric "do_comparison".
________________________________________________________ 8. If the "is_true_that" will be implemented than a filter "where" could be considered, like:
if ( is_true_that(all_of(a), _1 >= _2, one_of(b) ).where(_1->does_fulfill_condition()) ) ...
and the "where" fould have unary predicate as parameter, this predicate would filter out undesirable items from both ranges.
I've been thinking about these ideas further. They are mostly set manipulations and probably should be part of another library rather than the junctions/multivalues idea we're working at this point. Manipulating ranges and filtering them is a wide open field that should be addressed by its own library. However, there may be room to implement some of the ideas. The junctions/multivalues idea is simply to compare a range with a scalar, or two ranges, and produce a Boolean. We presently support these operations: all any each n_m n none not_all one Do we need more? Remember that these names encapsulate operations, not filters: |operation|behavior| |all | if any fails, the expression is false |any | if any succeeds, the expression is true |each | if each succeeds independently, the expression | | is true |n_m | if at least n and no more than m succeed, the | | expression is true |n | if exactly n succeed, the expression is true |none | if any succeeds, the expression is false |not_all | if all succeed, the express is false |one | if exactly one succeeds, the expression is true "one" is syntactic sugar for "n" which is syntactic sugar for "n_m." "not_all" is syntactic sugar for "!any." ("none" is really just syntactic sugar for "n," but also has a slightly more straightforward (and efficient) implementation.) Pavel's syntax ideas--more_than(x).items_of(a)--are interesting. "percent_of" seems limiting, but "fraction_of" doesn't read as well. I also wonder whether "percent_of" is in the realm of that other library I keep mentioning. How do these look? at_least(n).of(a) between(x, y).of(a) exactly(n).of(a) less_than(n).of(a) more_than(n).of(a) With those, we'd still keep the following *_of() operations because they otherwise require the computation of the range's length to use one of the above: all_of(a) each_of(a) not_all_of(a) Of course "at_least," "exactly," "less_than," and "more_than" are syntactic sugar for "between." By the same token, you could argue to keep "any_of," "none," and "one" as syntactic sugar for their alternatives. What do you think is the complete set of operations? Should we include "percent_of?" Should we provide the alternate spellings like "at_least," "more_than," and "one?" -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;