One more interesting thing to mention is that actually it’s neither the Sieve of Eratosthenes, nor the sieve at all. Here’s the fine paper explaining why, with examples in Haskell:

http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf
"A much beloved and widely used example showing the elegance and simplicity of lazy functional programming represents itself as “The Sieve of Eratosthenes”. This paper shows that this example is not the sieve, and presents an implementation that actually is."

Anyway your example is great.

function LargestPrimeFactor(const aComposite: Int64): Int64;
var
i: Integer;
primes: TEratosthenesSieve;
begin
primes := TEratosthenesSieve.CreatePrimesTo(Round(Sqrt(aComposite + 0.0)));
try
for i := Pred(primes.Count) downto 0 do
if (aComposite mod primes[i]) = 0 then
begin
result := primes[i];
BREAK;
end;
finally
primes.Free;
end;
end;

(apologies for the literals-gymnastics required to co-erce an Extended value from an Int64 param - is that fixed in Delphi 2009 I wonder?)

i.e. the algorithm is - get the primes that the answer could possibly be, then find the largest one that is the answer. The code describes the algorithm, I don’t have to deduce it.

Funny thing - I thought these new language features were supposed to enable us to more clearly express intent, not unwittingly obfuscate it.

Isn’t there also a hidden cost in an enumerator based approach?

With my TEratosthenesSieve, if I have a number of operations that involve a certain sequence of primes, I only need to calculate that sequence once. With an enumerator, won’t I be re-calculating the primes over and over again (every separate time that I enumerate)?

An enumerator approach would perhaps be useful when you don’t know in advance how many primes you are going to need, but even then, a non-enumerating sieve implementation could easily be extended to calculate primes on demand.

Which rather begs the question, what benefit does an enumerating approach really deliver?

Apart from providing a hook off of which to hang some new language features, I mean.

And if such questionable uses are what the language features are useful for, what use are those features, really?

I’m not saying that those features don’t have practical uses, only suggesting that such examples don’t actually help shed any light on what those uses are. And concrete, practical examples do seem rather hard to come by for some reason.

You know, with all the confusion of generics, and the examples being posted of how to use them being somewhat artificial, what we really need is an implementation of something a little more concrete/real world for us all to sink our teeth into and appreciate generics with.

Something like a MapReduce would be cool!

Raymond.

Primoz, I know that the composite is non-prime per the problem statement. In the general sense, I’d agree, but I wasn’t trying to solve a general problem (and, hence, the hard-coded value). Rather, I was trying to solve problem 3 of Project Euler.