From: Rob Stewart (stewart_at_[hidden])
Date: 2005-08-07 15:09:44
> From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>
> Date: Tue, 2 Aug 2005 16:43:56 +0200
> Reply-To: boost_at_[hidden]
> Sender: boost-bounces_at_[hidden]
>
> ________________________________________________________
> 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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;