RE: RE: sieve of erothenes

[maverick]

in reply to RE: sieve of erothenes
in thread sieve of erothenes

I removed and extra set of parens, changed the unless to a if! and compressed out the extra whitespace and got us dead even.

sub A { @_=(1);L:for(2..100){$i=@_;while(--$i){next L if!($_%$_[$i])}p
+ush@_,$_} }
sub M { for(1..100){push@_,$_;for(@_[1..$#_-1]){pop@_ and last if!($_[
+-1]%$_)}} }

print join(" ",@_),"\n";

I kept trying to think of how do this with maps and maybe come out with something different, but nothing has come to me yet

/\/\averick

##Update##
just saw how to squish out a 3 more characters

sub A { @_=(1);L:for(2..100){$i=@_;while(--$i){next L if!($_%$_[$i])}p
+ush@_,$_} }
sub M { for(1..100){push@_,$_;for(@_[1..$#_-1]){pop@_&&last if!($_[-1]
+%$_)}} }

[Adam]

You win on the efficiency test too. with n = 100 we are roughly the same time, but as n gets large I get bogged down somewhere. I'm running a test with n = 1000000 on my dual proc, which has been hung for about five minutes now. But based on the out put I've already seen for smaller n's, I suspect that you will slaughter me time wise.

I don't understand why yours is faster because you use two for loops and I use a while loop the second time, dropping the overhead of making the temp array that foreach generates. Now I'm curious about the efficiencies of the two looping mechanisms...

[maverick]

Hadn't even thought about benchmarking them...

I suspect that it isn't my looping structure, but that I'm stepping across the primes low to high and you're going high to low. My code tests division by '2' first, so the inner loop only runs once half of the time. Thus only runs twice a third of the time, 4 times a fifth of the time, etc.

since you test the large numbers first, you have to make more tests to throw out a potential prime.

consider your test of 16:
16%13 -> 16%11 -> 16%7 -> 16%5 -> 16%3 -> 16%2 (not prime)
as opposed to mine:
16%2 (not prime)

The foreach may have temp array overhead, but it looks like I'm making up for it on number of % and iterations

/\/\averick

[Adam]

You know, you are right. I had thought I had done it in the right order, but I didn't... I screwed that up. I guess I would have to use:

@_=(1);L:for(2..100){$i=0;while(@_>++$i){next L if!($_%$_[$i])}push@_,
+$_} 

which uses 2 more chars. Sigh.

UPDATE: I can do it with one less char then above, but still too many.:

@_=(1);L:for(2..100){$i=-@_;while(++$i){next L if!($_%$_[$i])}push@_,$
+_} 

Yes, I lie awake at night thinking about this stuff. No, not really. But when I get started thinking about it, I have a hard time stopping. But I doubt I'm alone in that disease. :)

[husker]

Although what I propose may not be the "classic" sieve algorithm, in truth you only need to test up to the primes which are less than the square root of the target number. In other words, you need not divide by any primes greater than 4 when testing 16. Based on the associative property of multiplication, if you can show that no numbers <= sqrt(n) evenly divide n, then you have also shown that there are no numbers => sqrt(n) which evenly divide n. While this may add a few chars to your code, it reduces the compute time enormously when you get to large n's.

Update: Actually, it doesn't look like ANY of us are implenting the true Sieve algorithm. The algorithm can be found here: http://www.math.utah.edu/~alfeld/Eratosthenes.html. It does in fact use the sqrt(n) modification, but doesn't do divide-testing ... instead it does "weeding out" of multiples. Same result, different technique.

Update 2: my mistake ... Ase is indeed doing the correct Sieve algorithm by using his bit vector technique.