|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-03-02 09:33:40
> On Tue, Mar 02, 2004 at 05:31:36AM -0500, Brian McNamara wrote:
> > Below I am attaching a revised version of your code and the FC++ code,
> > where the FC++ version uses your primality test.
>
> Just in case anyone construes this as "cheating" the FP paradigm
> (calling out to code which uses side effects and loops), here is an
> alternate version which is totally pure:
>
> struct Prime : public c_fun_type<int,bool> {
> bool operator()( int x ) const {
> //return is_prime(x); // cheating?
> lambda_var<1> C;
> return until( lambda(C)[ greater[C,x/2] %logical_or%
> equal[x %modulus% C,0] ],
> inc, 2 ) > x/2;
> }
> } prime;
>
> This version does run about 20% slower on my machine, but I think 20% is
> tolerable whereas 32000% is clearly not. (In any case, I did not put any
> thought into making this version run fast--I just transcribed the loop
> into equivalent pure code the first way that sprang to mind.)
This version does work much better. But it's still kinda alarming that there
is a way to write the same algorithm with FC++ that works 200 times slower
(actually the way any regular FP practitioner would use). If you know some
library internals that allows you select fast algorithm over slow one, this
should be one of the primary lessons taught by docs. Anyway I believe there
should be performance analysis for all the operations on a lazy list. Plus
if you could provide an examples of intended usage for this class to address
real-life problems with performance comparison with corresponding imperative
analog, that would be good enough to satisfy me on the topic.
Regards,
Gennadiy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk