The problem is you either need to add a Boolean flag "backWasComputed"
or two for completeness. The problem is, often checking the flag every
time you access front or back may be almost as expensive as the
filtering operation itself.
I reached the belief that the canonical filter() implementation should
have absolutely no surprise: no flags, no caching, no frills. Just one
test per container element. So that precludes it being bidirectional.
The bidirectional filter is equally unsurprising.
Andrei
On 1/3/11 12:00 PM, David Simcha wrote:
Why is this a speed disadvantage? IMHO, filterBidirectional should be
the only flavor of filter. Either way, exactly one complete pass has to
be made through the base range to iterate over the Filter. It just
means that things will be computed slightly more eagerly. Are there any
very important use cases where this is a major disadvantage?
On Mon, Jan 3, 2011 at 12:54 PM, dsource.org <http://dsource.org>
<[email protected] <mailto:[email protected]>> wrote:
phobos commit, revision 2270
user: andrei
msg:
Added filterBidirectional for completeness
http://www.dsource.org/projects/phobos/changeset/2270
paths changed:
U trunk/phobos/std/algorithm.d
_______________________________________________
phobos mailing list
[email protected] <mailto:[email protected]>
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
