Determining complexity of an integer factorization algorithm

Question

I'm starting to study computational complexity, BigOh notation and the likes, and I was tasked to do an integer factorization algorithm and determine its complexity. I've written the algorithm and it is working, but I'm having trouble calculating the complexity. The pseudo code is as follows:

DEF fact (INT n)
BEGIN
    INT i

    FOR (i -> 2 TO i <= n / i STEP 1)
    DO
        WHILE ((n MOD i) = 0)
        DO
            PRINT("%int X", i)
            n -> n / i
        DONE
    DONE

    IF (n > 1)
    THEN
        PRINT("%int", n)

END

What I attempted to do, I think, is extremely wrong:

f(x) = n-1 + n-1 + 1 + 1 = 2n

so

f(n) = O(n)

Which I think it's wrong because factorization algorithms are supposed to be computationally hard, they can't even be polynomial. So what do you suggest to help me? Maybe I'm just too tired at this time of the night and I'm screwing this all up :(

Thank you in advance.

Aasmund Eldhuset · Accepted Answer · 2014-07-20T10:47:06.007

This phenomenon is called pseudopolynomiality: a complexity that seems to be polynomial, but really isn't. If you ask whether a certain complexity (here, n) is polynomial or not, you must look at how the complexity relates to the size of the input. In most cases, such as sorting (which e.g. merge sort can solve in O(n lg n)), n describes the size of the input (the number of elements). In this case, however, n does not describe the size of the input; it is the input value. What, then, is the size of n? A natural choice would be the number of bits in n, which is approximately lg n. So let w = lg n be the size of n. Now we see that O(n) = O(2^(lg n)) = O(2^w) - in other words, exponential in the input size w.

(Note that O(n) = O(2^(lg n)) = O(2^w) is always true; the question is whether the input size is described by n or by w = lg n. Also, if n describes the number of elements in a list, one should strictly speaking count the bits of every single element in the list in order to get the total input size; however, one usually assumes that in lists, all numbers are bounded in size (to e.g. 32 bits)).

Good explanation! However, if we assume that operations on n aren't atomic steps but dependent on n's size w, then we also need to take into account that modulo and division both aren't constant but in O(w ln w ...) and thus the whole algorithm's worst case complexity cannot be in O(2^w). — le_m, Mar 14 '17 at 14:57

score 0 · Answer 2 · answered May 15 '11 at 02:33

0

Use the fact that your algorithm is recursive. If f(x) is the number of operations take to factor, if n is the first factor that is found, then f(x)=(n-1)+f(x/n). The worst case for any factoring algorithm is a prime number, for which the complexity of your algorithm is O(n).

Factoring algorithms are 'hard' mainly because they are used on obscenely large numbers.

answered May 15 '11 at 02:33

Tauf

21
1

Or rather, factoring algorithms are 'hard' because they can't efficiently scale to large numbers. – Greenstick Nov 15 '18 at 23:29

score 0 · Answer 3 · answered May 15 '11 at 05:39

0

In big-O notation, n is the size of input, not the input itself (as in your case). The size of the input is lg(n) bits. So basically your algorithm is exponential.

answered May 15 '11 at 05:39

BiGYaN

6,974
5
30
43

Determining complexity of an integer factorization algorithm

3 Answers3