Prime Numbers

1.1 Problems and progress 9
some authors denote bit and operation complexity by such as Ob, Oop
respectively. So when an algorithm’s complexity is cast in “O” form, we
shall endeavor to specify in every case whether we mean bit or operation
complexity. One should take care that these are not necessarily proportional,
for it matters whether the “operations” are in a field, are adds or multiplies,
or are comparisons (as occur within “if” statements). For example, we shall
see in Chapter 8.8 that whereas a basic FFT multiplication method requires
O(D ln D) floating-point operations when the operands possess D digits
each (in some appropriate base), there exist methods having bit complexity
O(n ln n ln ln n), where now n is the total number of operand bits. So in such a
case there is no clear proportionality at work, the relationships between digit
size, base, and bit size n are nontrivial (especially when floating-point errors
figure into the computation), and so on. Another kind of nontrivial comparison
might involve the Riemann zeta function, which for certain arguments can be
evaluated to D good digits in O(D) operations, but we mean full-precision,
i.e., D-digit operations. In contrast, the bit complexity to obtain D good
digits (or a proportional number of bits) grows faster than this. And of
course, we have a trivial comparison of the two complexities: The product
of two large integers takes one (high-precision) operation, while a flurry of bit
manipulations are generally required to effect this multiply! On the face of it,
we are saying that there is no obvious relation between these two complexity
bounds. One might ask,“if these two types of bounds (bit- and operationbased
bounds) are so different, isn’t one superior, maybe more profound than
the other?” The answer is that one is not necessarily better than the other. It
might happen that the available machinery—hardware and software—is best
suited for all operations to be full-precision; that is, every add and multiply
is of the D-digit variety, in which case you are interested in the operationcomplexity
bound. If, on the other hand, you want to start from scratch
and create special, optimal bit-complexity operations whose precision varies
dynamically during the whole project, then you would be more interested in
the bit-complexity bound. In general, the safe assumption to remember is that
bit- versus operation-complexity comparisons can often be of the “apples and
oranges” variety.
Because the phrase “running time” has achieved a certain vogue, we
shall sometimes use this term as interchangeable with “bit complexity.”
This equivalence depends, of course, on the notion that the real, physical
time a machine requires is proportional to the total number of relevant bit
operations. Though this equivalence may well decay in the future—what
with quantum computing, massive parallelism, advances in word-oriented
arithmetic architecture, and so on—we shall throughout this book just assume
that running time and bit complexity are the same. Along the same lines, by
“polynomial-time” complexity we mean that bit operations are bounded above
by a fixed power of the number of bits in the input operands. So, for example,
none of the dominant factoring algorithms of today (ECM, QS, NFS) is
polynomial-time, but simple addition, multiplication, powering, and so on are
polynomial-time. For example, powering, that is computing x y mod z, using