Re: [boost] [SPAM (Bayesian)] - Re: Formal Review: Boost.RangeEx - Bayesian Filter detected spam

Subject: Re: [boost] [SPAM (Bayesian)] - Re: Formal Review: Boost.RangeEx - Bayesian Filter detected spam
From: Robert Jones (robertgbjones_at_[hidden])
Date: 2009-03-02 16:47:51

On Mon, Mar 2, 2009 at 3:36 PM, David Abrahams <dave_at_[hidden]> wrote:

>
> on Mon Mar 02 2009, Robert Jones <robertgbjones-AT-gmail.com> wrote:
>
> > On Mon, Mar 2, 2009 at 10:19 AM, Arno Schödl <aschoedl_at_[hidden]
> >wrote:
> >
> >>
> >> In this latter case, I don't see how you can do without an in-place
> >> algorithm, which IMO should be named differently. Or is the idea to do
> this:
> >>
> >> vector<int> vecn;
> >> vecn=transformed( vecn, func ); // overwriting the range that the
> adaptor
> >> is still working on?
> >> sort( vecn ); // sort cannot be done lazily
> >>
> >> I don't feel comfortable with it. Some adaptors are o.k. with it
> >> (transform), while others (say, duplicate each element) are not. For
> some
> >> (slice), it will depend on the implementation of operator=. And the
> compiler
> >> won't warn you.
> >
> >
> > AFAICS there's no issue in principle with something like
> >
> > vecn | boost::adaptors::sort
> >
> > as an expression. This would result in a range that could be iterated
> > through lazily,
>
> What does it mean to "iterate lazily?"

My understanding of an expression like

rng | filter(pred);

is that the range resulting from it never exists independently, but rather
each element is determined by the application of the filter(s) from the
source range on demand.

>
> > although in total could not be as efficient as a traditional
> > sort.
>
> What did you have in mind, using partial_sort?

The implentation of lazy iterators is easy for simple filters, but less
obvious for things like sort, in which case presumably the whole of
the source range must be available before any output iterator can be
evaluated.

I didn't really have any specific algorithm in mind, only that the result
range need only support sequential iteration, and so each evaluation
of the resulting range only needs to provide the next element.

That's probably obvious. Sorry.

>
>
> > Naturally the underlying range must not change in any way, or
> > all bets are off.
>
> The right answer may be to copy the range in that case.

Maybe, that would remove the requirment of immutability of the source
range, but OTOH might be expensive. Alternatively the result range
might iterator through a range of pointers, which would be cheap, but
course prone to failure if the pointed to element is destroyed.

No answer really, just thoughts.

>
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
ACCU - Professionalism in programming - http://www.accu.org