Here is the code, if you’re interested:

def factor(n, verbose = False):
“”"
Returns all prime factors of n, using simple trial division.
Returns a list of (possibly repeating) prime factors
“”"
t = clock()
ret =[]
nn = n
# Remove 2′s and 3′s first
while nn % 2 == 0:
nn //= 2
ret += [2]
while nn % 3 == 0:
nn //= 3
ret += [3]
maxFactor = int(nn**0.5)

# Prime factors after 2 and 3 will be of the form 6x+-1
# This is equivalent to alternately adding 2 and 4 to each
# successive factor-candidate.
oldnn = nn
i = 5
while i >> from factorAndSieve import *
>>> factor(10**15+37,True)
Calculated factors of 1000000000000037 in 1.69 sec.
[1000000000000037]
>>> factorAndSieve(10**15+37,True)
Calculated factors of 1000000000000037 in 5.61 sec.
Stopped trial division at 31622775 instead of 31622776
[1000000000000037]
>>>

Perhaps a number that has a few large prime factors would produce different results?

But to me it appears that bailing out at the square root of the current number is at least as efficient as sieving as you go. Here’s why I think that is: The sieve-as-you-go strategy is to reduce the number of trial-divisions you must make. But finding primes for this purpose is every bit as expensive (perhaps more so) as those same trial-divisions you hoped to avoid. You must still iterate over your sieve looking for true values that indicate the presence of a prime, and every time you find a prime, you must go through the remainder of the sieve marking multiples false. This is a lot of work. The only thing that would really make your approach perform better would be if a trial-division was a much more expensive operation than the combination of several comparison branches, reads, and writes. The mod operation /is/ pretty expensive on most modern processors, but my guess is it’s not expensive enough to give your approach a serious competitive advantage.

But sometimes it is not: try any number with a large prime factor and you are in for miserably slow code. With my first example, 10^15+37, which is a prime, I seriously doubt you will get an answer within your lifetime! And Sundar’s tricks (which are great optimizations for everyday numbers, don’t get me wrong) are useless: there isn’t much practical use in dividing a billion years of computing time by 4…

It is true, though, that what I propose is very inefficient in memory use, and it will not work with very large easy numbers that are a piece of cake for trial division. Even if it meant sacrificing some efficiency, it could be a good idea to compute primes as fast as when sieving, but allocating memory on the go. This is a somewhat contradictory statement, but there apparently are ways of doing it. Or at least so says this paper sitting in my “to read in detail” folder:

http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf

Now that you’ve asked, I may even try to figure out the details, turn that Haskell code into python and revive this blog…

The trivial example of how much faster your factorAndSieve implementation is than an extremely naive trial-division implementation in the case of a large power of 2 is irrelevant because the speed advantage in this case comes not from the sieving but from dividing out the discovered factor and recalculating the upper bound to which trial-divisions must be made. A non-sieving algorithm can do this just as well as yours, and mine does a pretty good job.

I’d be delighted if you could produce an example of a number this factor-and-sieve algorithm could actually outperform a more ordinary trial-division algorithm on.

X += [X_e[k-M] – X_o[k-M] * twiddles[(k - M) * twiddles[-1] // N]]

(present also in the correct code) do multiply by N and then divide by N?

I rewritten (unsorted version) it into C (and added few other optimalisation). I needed divisors for determining an order of element a in finite field Z/pZ. (order of element a is smallest positive number k, such that a^k mod p == 1, and I know it is true for k==p-1, via Fermat’s theorem, but it is not nacassarly smallest k. so need to check also divisors of p-1, because if a^k == a^(k1*k2) == (a^k1)^k2 == 1^k2 , then we see k1 (a divisor of k), or its divisor, can be an order of a )

You can find it at http://pastebin.com/tMBTYSx7
It is small, fast and interesting code I think.

I will also implement ordered heap to check if it faster, but for my purpose it can be beneficial to also use identity a^(x*y) = (a^x)^y first, as it will be faster to perform powpod probably incrementally, than checking from smallest ones (but early termination in ordered heap will be really nice for me also).

thanks for the great tutorial!

I’d like to use and adapt this code in my thesis project so it would be good to know under which license it is released.

Thanks in advance.

You may want to read this, as it elaborates on the effects of windowing and sampling of a real world signal:

http://en.wikipedia.org/wiki/A_derivation_of_the_discrete_Fourier_transform