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.