On Saturday, 26 May 2012 at 18:40:53 UTC, maarten van damme wrote:
well, I was thinking about using a sieve but when you were to
request
prime 400_000 you're sieve would blow up in size.
Because you only need primes up to sqrt(n) to check if n is prime,
you can make a sieve based range that only uses O(sqrt(n)) memory.
I've put an example at https://gist.github.com/2795954 .It could
be optimized further (skipping even numbers, keeping track of the
multiples of small primes...), but it is already much faster
than a range that does not use a sieve.
That's why I
opted
for something else (and I don't know if it was the right thing
to do
though). (Ab)using opIndex like that is indeed a bit wrong but
what
would be the alternative? remove slicing and introduce getPrime?
Wouldn't that be the same but without the great syntactic sugar?
Syntax sugar isn't great if it confuses people and causes bugs.
You can use r.drop(n).front to get nth element of a range.
If you need to do it often, you could just write a nth() function.
