Boost logo

Boost :

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:


Do we need more? Remember that these names encapsulate
operations, not filters:

  |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?

   between(x, y).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:


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           
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at, gregod at, cpdaniel at, john at