3.

L Experimental Studies ill

3.1 Experimental Studies

If an algorithm has been implemented. we can study its running time by executing
ii on various 1esL inputs and recording !he rime spent during each execution. A
simple approach for doing Lhis in Python is by using Lhe time function of Lhe time
module. This function reports !he number of seconds. or fractions !hereof. !hat ha\'e
elapsed since n benchmn.d: Lime known as !he epoch. The choic,e of !he epoch is
not significanl 10 our goal. as we can determine Lhe tlapstd Lime by recording !he
time just before Lhe nlgonthm and the time just after the algorithm. and c-0mputing
their difference. as follow~:
from time import t ime
st.lrLtime = time( ) ff' record the starting time
run algorithm
end_time = time( ) # record the ending time
elapsed = end_time - starLtime :Ii compute the elapsed time

We "ill demonstrate use of this approach. an Chapter 5, to gather experimental data

on the efficiency of f>)thon"s list class. An el.lp!>Cd Lime measured in this fashion
is n decen1 renection of Lhe algorithm efficiency. but it is by no means perfect. The
time function measures relnti,e 10 what is knO\\ n as the ""wall clock.- Because
man) processes share use of a compu1er·s central processing unit (or CPU). Lhe
elapsed lime "ill depend on whm olher processes a.re running on the compu1er
when !he tes t is perfonned. A fairer melric is the number of CPU C)cl~ Lhat arc
u.sed by the algorithm. Th,~ can be detcmtincd U)ing the clock function of the time
module. but e\'en Lim measure might not be cons15Lent if repeaung the identical
algorithm on the identical mput, and its granularity "ill depend upon the computer
S)':.Lem. Python includes a more advanced module. named t imeit. Lo help automate
such evaluations "ilh repetition to account for such vari30Ce among lrinb.
Because we are interested in lhe general dependence of running time on the size
and structure of the inpul. \\e ~hould peTfonn inckpendent experiments on many
d11Tercn1 1es1 inpulS of ,urious sizes. We can then visualire the resullS by plouing
!he perfom10,11ce of eoch run of the algori1hm ~ n poinl wi1h x-coordinme equal 10
!he input size. n. and ) -COOrdinale equol to Lhe running time. t . Figure 3.1 di~ploys
such hypolhetical data. This visualiz.ruion may pro, ide some inwitfon regarding
!he relationship betv.een problem size and execution time for !he olgorilhm. This
may lead to a SLalistical analysis LhaL seeks to lit !he best function of the input size
to !he experimental data. To be meaningful Lhis analysis requires tha1 we choose
good sample inputs and test enough of !hem Lo be able Lo make sound stolistical
cloims oboul !he olgorithm's running time.
112 Chapter 3. Algorithm Analysis

500

••••
,....
400
••
! •••
• •••• •
~ 300
E
i=
• •••
Cl:
C
g 200
::
a:

•• ••• •
100
••
0
• •
0 5000 10000 15000
Input Siu

Figure .l.1 : RC!lults or an expenmen1al ~udy on the running 1ime or an algori1hm.

A dot with coordinates (n.1) indicates thai on an input of :.ize n. 1he ru nning time
of 1he nlgori1h m was men:.ured as, milliseconds (ms).

Challenges of Experimental Analysis

While e.xperimen1al Mudics or ruMing 1ime.s ore valuable. especially when fine-
1uning production-quality code. there are lhn.-e major limitations 10 their use for
algorithm analysis:
• Experimental running times or two algorithm:. arc difficult to directly com-
pare unless the e>.periments are perfonned in the same hardware and software
environments.
• Experiments can be done only on n limited set or tes1 inputs: hence. tl1ey
leave out the running times of inputs not included in the experiment (and
these inputs may be important).
• An algorithm must be fully implemen1ed in order to execute it to study its
ruMing time experimentally.
This last requirement is the most serious drawback to the use of experimental stud-
ies. At early stages of design. when considering a choice of data structures or
algorithms. it would be foolish 10 spend a significant amouru of time implementing
an approach that could easily be deemed inferior by a higher-le,•el analysis.
3. 1. Experim CIJt:ll S tudies ll3

3.1. 1 Movi ng Beyond Experimen ta l Analysis

Our goul b 10 dc,elop an npproach 10 nn.11) ,ing the efficiency of nlgori1hm, 1h111:
I. Allow1, u, 10 C\'alu:ue the reln1hc efficiency of nny cwo nlgorichm, inn wny
chnc i.. indcpemlenc of che hardware and <;;.lft\l.are environmena.
2. J,, perfonned by '1Ud) ing n high-lc\el dC\Cnption of 1he nlgorichm wi1hou1
need for implcmentnuon.
3. Takes inco nccounc all possible inpulS.

Counting Primitive Operations

To analyte the running lime of n.n nlgonthm "1thou1 performing expenmcnc~. we
perform nn nnaly11u, ducccly on n high-le\d ~ p t ion of chc nlgorichm (either in
the fonn of an nccual code fragmcn1. or language-mdependenc p<,eude><ode). We
define a !>Cl of primitfrt optratio11s i,uch ru, the following:
• AS!ligning on identifier 10 nn objecc
• Oc1cn111nmg lhc object a.~ocirued "ith an idenulier
• Perfom1ing an nnlhmeuc opcrnuon (for example. adding cwo nun1bers)
• Comparing I\\O number.
• Acce...sing n <.ingle element of n P)'lhoO list by index
• Calling a function (excluding opermio~ executed wilhin lhe function)
• Returning from n function.
Formally. a primili\e operation corresponds to a low-level instrucuon \\ith an exe-
cution time that is conscant. Ideally. this mighc be the cype of b~ic operation that is
executed by the hard\\are. although many of our primitive operations may be trans-
lated 10 a small number of 1ns1ructions. Instead of trying 10 detenninc the specific
execution 1ime of each primicive operauon. \l.e "ill simply coun1 ho\l. many prim-
itive operation~ are executed. and U\C thi~ number, as o measure of the running
time of the ulgorilhm.
This opemlion count will correlate to an nccual running ume m a specific com-
puter. for each primith'e operation corresponm 10 a constant number ofins1tuclions.
and there ore only a fixed number of primithc operations. The implicic assumption
in this approach is lhac the running times of differcm primitive operations wilJ be
fairly similar. Thus, the number.,. of primithe operations an algorithm performs
wiU be proportional 10 the accual running time of lha1 algorithm.

M easuring Operations as a Function of Input Size

To capture the order of gro\\lh of an algorithm·., running 1ime. "e "111 a.,~ociate.
\I.1th euch algorithm. a function /(11) that charnccen,cs 1he number of pnmiuvc
opernuons 1hm are performed as a funcuon of the mput ,;ite 11. Seccion 3 2 "ill in-
troduce the ,;even mo,,1 common functions 1ha1 nn,;c, and Section 3.3 "111 introduce
n rna1hema1icol fmme .... orl for companng function, 10 each other.
114 Chupter J. Algorithm A nulyslo;
Focusing on the Worst- Case Input
An algorithm may run ftbter on some inputs than it doe!. on others of the i,ame sire.
Thus. we may wish to express the running time of an algorithm ~ the function of
the input si,,c obtained by taking the a, eroge over all po!>sible input~ of the i,amc
site. Unfonunately, such an a11erage-case analysis i1, typically quite challenging.
It requires us to define a probability distribution on the set of inputs. which is often
a difficult task. Figure 3.2 !.thematically shows how. depending on the input di, tri-
bution. the running umc of an algorithm can be any,, here between the worst-case
time and the best-case time. For example. whnt if inputs are really only of type~
"A or .. D..'?
0

An overngc-cuse analysis U!,ually require\ thnt \\C calculate expected running

time.-. based on a gi\cn input di~tribution. which usually in\'o h•es ~ophb ticatcd
probability theory. Therefore. for the remainder of this book. unless we t.pccify
otherwise. we,, ill charnctcri.re running times in terms of the ·wot'$t case. as a func-
tion of the input sire, "· of the algorithm.
Worst-cru.e analy!-is i!> much easier than :.wcroge-c~ analysis, as it requires
only the ability 10 identify the ,,ors1-ca.,e input. which is often simple. Also, this
approach typically lends to better algorithms. Making the standard of success for an
algorithm 10 perform well in the worst ca.se necessarily requires that it will do well
on every input. That i-.. designing for the wor..t ca~e leads 10 sLronger algorithmic
"muscles," much like n trock !>tar \\ ho nlwn)•~ pracuces by n1Ming up an incline.

- - - - - - - - - - - - - - worst~'lL~e time

U\'et'll{:C-Cllse lime?

- - - b~1-aisc time

A B C D E F C
Input Instance

Figure 3.2: The difference between bcM-case and won.1-c~e time. Ench bar repre-
sent!. the running time of some algorithm on a different pos.,iblc input.
3.2. The Seven Functions Used in This Book 115

3.2 The Seve n Functions Used in This Book

In this ,ec1ion. we briefly d&USs the M!\'en most impon.an1 functions used In the
analyi.is or algorithnu.. We "ill use only these se, en simple functions for aJmos1
all the analyhls we do in this book. ln fact. a section that uses a function other
than one of these seven will be marked wilh a s tar (*) to indicate !hat it is optional.
ln addition to these se,-en fundamental functions. Appendix B contains a list or
other useful mathematical facts that apply in the analysis of data structures and
algorithms.

Th e Constant Function
The simplest function we can thml. of ,s the co11stant fimction. This is the function.
/ (11) - C,

for some fixed con.-.1nnt c. such as c - 5. c - 27. or c - 2 10. Tim1 is. for any
argument 11 , the constant function / (11) :isMgns the value c. In other words. ii does
not mauer what the ,'lllue or n is: / (11) will always be equal to the consmnt value c.
Because we are most interested in integer functions, the mosl fundamental con-
stant function is g(n) = I. and this is the typical constant function we use in this
book. Note that nny olher constant function. f (n) = c. can be wri11en :u, a cons1ant
c limes g(n). Thal i,. / (11) = <'g(n} in this Cll!,C.
As simple n., it b . the con, taol Function i, u5eful in algorithm analysis. bccoul>c
ii chnrncteri1e, the number or , teps needed 10 do a bO'tic operation on u compu1er.
like adding two number... as\1g111ng a value to ,omc ,':lnoblc, or comp:mng 1wo
number...

The Logarithm Function

One of the mte~ting and i.omeum~ eH:n i.urprii.ing tl!lpccb of the :malyl> i!. of
data i.lrllcturel> and algorithms ii. the ubiquitous presence of the logariJl,mfu11ctio11.
/ (11) = logh11. for some constant b > I. Thi.-. function is defined as follows:
x = logb11 if and only if b' = 11.
By definition. logh I - 0. The value b is known ai, the base or the logarithm.
The mo~t common bai.e for the logarithm function in computer :.cience is 2.
ru, computer. More mtcgcri. ,n binary. and becau~ a common operation in many
algorithms iJ. 10 rcpctllcdly di\ idc an 111pu1 in hnlf. In fact. thii. bn., c is ,o common
Lhol we will typically omil ii from the notation when it i, 2. 11,at i~. for us.
logn = log1 11.
Jl6 Chapter J . Algorithm Analysis

We note that most handheld calculators have a button marked LOG. but this is
typicnlly for cnJculating the logarithm base- 10. not base-two.
Computing the logarithm function e.~actly for nny integer II involves the use
of calculus. but \\e can use an opproxim:njon that is good enough for our pur-
poses without calculi.I!,. In particular. we con eru.ily compuie the l>malles1 integer
greater than or equal 10 logi,11 (its so-called ctili11g . r1ogi, 111). For positive integer.
11 . this value is equal to the number of times we can divide II by b before we ge1
u number less than or equal 10 I. For exnm pie. the evaluation of pog, 271 is 3.
becau1,e ((27/ 3)/3)/3 = I. Like\\1-.C. Po~ 64l i, 3. because ((64/ 4)i4)/4 = I.
and pog 2 121 is 4. becnu~e ((( 12/ 2)/2)/2)/2 = 0.75 ~ I.
TI1e following proposition de..cribes M:\.erol important identities thot involve
logarithms for nny bnse greater than I.
Proposition 3.1 ( Logarithm Rules) : Gncn n:al numbe~ a > O. b > I. c > 0
tmd d> I. we hmc:
I. lng11 (a<') - log,,a+ log1,r
2. log1,(t1/ t·) log1,a lng1,r
3. log11 (if) c IOgt,a
4. log1,a logJa/ logdh
5. 1,ktf,li ll~'l.th
By convention, the unpnren1he\lLCd notntion log11' denote.~ the value log(11' ).
We u,e a noiational i.honhand. log' 11. 10 denote the quantity. (log11)'. in which the
rcl>ult of the logarithm i\ rru,cd 10 o f)O\\ er.
The above idcntitie1, can be derived from COll\er.e rulci. for cxponcn1iation 1hm
we will prc,ent on page 121. We illustrate these 1demi11es with a few examples.
Example 3.2: \Ve dcmom.trotc below 1-omc mtcre\tmg 11pplic:itiom of !he /og11-
rithm ru/t!!> from Propo!>1tion 3. 1 (U!>W8 tl1e w,ual com ent,on that the ba.~e of 11
/ogllrirhm if> 1 if II i1, onutted).
• log(211) = log2 + log11 = I + log 11. by rule I
• log(11/ 2) =log11 - log2 - log11 - I. by rule 1
• log,,3 =31ogn. by rule 3
• log2" =111og2 =11 • l = 11, by rule 3
• lo&.i 11 = (log11)/log4 = (log11)/2. by rule 4
• 21ot11 = 11101! 2 = 11 1 = 11. by rule 5.
As:, proctical matter. we note tl1:1t rule 4 gfres us a way to compute the base-two
logarit11m on a calculator dmr has D b:Jse- 10 logarithm button. LOG. for

log2 11 = LOG 11 / LOG 2.

3.2. Tl1e Sef·en Functions Usl!d in Tbis Book 117

T he Linea r Function
Another simple yet important function is the li11ear f um:tum .

/ (11) = II.

That is. given an input value 11. lhe linear function/ assigns the value fl itself.
This function arises in algorithm analysis any time we have 10 do a single basic
operation for each of II elemenis. For example. comparing a number x to each
element of a sequence of size II wiU require II comparisons. The linear function
also represents the best running time we can hope to achieve for any algorith m that
processes each of II objects that are not already in the computer·s memory. because
rending in the" objects already requires fl operations.

T he N- Log-N Function
The next function we discuss in this section is the 11-log-11 f u11ctio11.

/ (11) = nlogn.

that is. the function that assigns to an input 11 the value of fl times the logarithm
base-two of n. This function grows a little more rapidly than the linear function and
a lot less rapidly than the quadratic function: therefore. we would greatly prefer an
algorithm with a running time that is proportional to II log11, than one with quadratic
running time. We will see several important algorithms that exhibit a running time
proportional to the 11-log-11 function. For example. the fastei."t possible algorithms
for sorting II arbitrary values require time proportional to II log 11.

T he Quadratic Function
Another function chat appears often in algorithm analysis is the qaadratic/ u11ctio11,

Thac is. given an input value fl. the function / assigns the produce of II wicb itself
(in other words, -,, squared").
The main reason why the quadratic function appears in the analysis of algo-
rithms is lhat there are many algorithms that have nested loops. where the inner
loop perfonns a linear number of operations and !he outer loop is performed a
linear number of limes. Thus, in such cases. the algorithm performs fl • 11 = fl 2
operations.
118 Chapter 3. Algorithm Analysis

Ne.s ted l oops and the Quadratic Function

The <1uadr:uic func1ion cnn also nnse in 1he con1e,1 of nes1ed loops where 1he firsl
i1cn11ion or a loop uses one operation, 1he second uses 1wo opera1ions, the third use.,
1hree opem1ions. and so on. Thal is. 1he number of operations ii,

I + 2 + 3 +···+(n - 2)+(11 - l)+ 11.

In other words. this is the total number of operations that will be performed by the
nested loop if the number of operations performed inside the loop increases by one
with each iteration of the outer loop. This quantity also bns an interei.tiog history.
ln 1787. a German i,choolleacber decided 10 keep his 9- and I0-year-<>ld pupils
occupied by adding up tbc integers from I 10 I 00. Bui almoM immediately one
of the children claimed 10 have tbc ans\\er! The teacher was s~1>icious, for Lhe
s1udent had only the answer on his slate. But the answer. 5050. was correct and the
student. Carl Gauss. grew up to be one of the greatest mathematicians of his Lime.
We presume that young Gauss used the following identity.
Proposition 3.3: For any inreger 11 ~ I. \\ e h,we:

11 ( 11 + I}
1+2 -3 +··· - (n-2) - (n- l ) -'-11= - - -.
2
We give two "visual" ju.stifications of Proposition 3.3 in Figure 3.3.

n+t t - - - - - .
n n

3
2

O 23 n O 12n/2
(a) (b)
Figure 3.3: Visual justiticmions of Proposition 33. Both illustrations visualize the
identity in terms of the total area covered by " unit-width rec1angles will, heights
I, 2, ... . 11. In (a). the rec1angles arc shown to co,.er a big triangle of are.i 112 / 2 (base
11 and height 11) plus 11 ~mall tnangles of area I/ 2 each (base I and height I). In
(b). which applies onl) \\hen II is e,~n. the rectangles a.re shown 10 cover a big
rcctnngle of base n/ 2 and height n + I.
3.2. The Sc~cn Functions Used in This Book 119
The les!>on to be learned from Propos1Lion 3.3 is that if we perfonn :m algoriLhm
wiLh neltted loop<, such that the opemLioru. in the inner loop increase by one each
Lime. then Lhe total number or operations is quadratic in the number of times. 11.
we perfonn the ou1er loop. To be fair. the number or opera1ioru. is 112/ 2 + 11/ 2.
and :.o this is just over half the number of operations thnn nn algorithm that u~cs 11
operations each time the inner loop is perfom1ed. But the order or growth is still
quadratic in 11.

Th e Cubic Function and Other Polynomials

Continuing our discussion of functions that nre powers of the input, we consider
the cubic function.
/ {11) = 113 •
which assigns to an input value n the product of n with itself three times. This func-
tion appears less frequently in the context of algorithm analysis than the constant.
linear. and quadratic functio~ previously mentioned. but it does appear from time
to Lime.

Polynomials
Mo:.t or the functions we ha,e h:.ted i.o far cun each be viewed as being part of a
larger clos!> of functions. the poly11omials. A polynomial fu nction has the fonn.

where no ,t1 1, ... ,ad are consLants. called the coefficients of the polynomial. and
flJfa 0. lnLeger d. which indicates the highest power in the polynomial. is called
the degree of the polynomial.
For example. the following funcLions are all pol) nomials:
• / {11)= 2 + 511 + 112
• /{11)= 1 + n1
• /{11) I
• /(11) "
• f{r,) - ,,2
Therefore. we could argue that thi., book presenLS J~t four important function!, u:,ed
in algorithm nnnlyi.i~. but ""e will , ticL. to saying that there are ..even. i.ince the con-
1,1an1. linear. and qundro11c funcuons are too important to be lumped in with other
polynomials. Running umei. Lhnt are polynomirus with small degree nre generally
beuer than polynomial running tin1es wi1h larger degree.
120 Chapter 3. Algorithm Analysis
Summations
A oouuion !hat appears again and again in the analysis of dam structures and algo-
rithms is the summation. which is defined as follows:

b
[ f (i) = f(a)-t- / (a- I )+ /{a ~2)+···+ f (b ),
' a

where a and b are integers and a ~ b. Summations arise in data i.tructure and algo-
rithm analysis because the running limes of loops naturally give ri~ 10 summations.
Using a summation. "'e can rewrite the fonnula of Proposition 3.3 as

f . 11(11 + 1)
1..., 1 - - - -
, I 2

Likewi!>e. we can \\.rite n polynomrnl / (11) of degreed" ith coef'ficienti. a 0, ... ,a,1 ru,

,I
/ (11) = [ a,11
1
•

I 0

Thu~. the summation notation givci, u~ n \honhand way of cxpres,ing , um, of in-
crca.,ing tenm that ha,e a regular structure.

The Exponential Function

Another function UM!d in the analysis of algorithm, is the upo11t 11tial f1111ctio11,

/ {11) = II'.

where bis a positi\ e constant. called the base. and the argument II is the u po11mt.
That is. function / (11) assigns to the input argument II the value obtained by mul-
tiplying the base b by itself II times. As wru, the case ,, ith the logarithm function,
the most common base for the exponential function in algorithm analysis is b = 2.
For example. an integer word containing II bits can represent all the nonnegati ve
integers less than 1!'. If we have a loop that stfillS by perform.ing one operation
and the n doubles the nu mber of operations performed with each iteration. then the
number of operations performed in the d" iteration is 2".
We sometimes have other exponents besides n. however: hence. it is useful
for us to know a few bandy rules for working with exponents. In particular. the
following exponent rules are quite helpful
3.2. TIie Seven Functions Used in This Book 121
Proposition 3.4 (Exponent Rules): Gi\en positne integers". b. nnd c. we /wl'e
I. (It')' - If"
2. II' b' - II'.,.
3. If' /It - ba- ,
For example. we have the following:
=
• 256 = 162 = (2")2 z4 2 = 28 = 256 {Exponent Rule I)
• 243 = 35 = 3hJ = 3 23 3 = 9 •27 = 243 (Exponent Rule 2)
= = =
• 16 = 1024/ 64 2 10/ 26 2 10- 6 z4 = 16 (Exponent Rule 3)
We can extend the exponential function 10 exponents that arc fmc1ions or real
number. and 10 ncgauvc exponents. a.~ follow~. Given n positive i,ucgcr k, we de-
line 1, 1 4 10 be k'" root of b, 1h111 i~. 1he number r ,uch Lhlll I' - h. For cxomplc,
25 112 S, 1,incc 51 25. Like" t'>I!, 27 1 ' 3 and 16 1 ~ 2. This approach al-
lows u~ 10 define any power whose exponent can be exprc,sed n.~ u fraction, for
11'11 - (/1') 1 'c, by Exponent Rule I. For example, 9 1 2 = {9 1 ) 112 729 112 27.
Thus, If'/ ' is really jus1 the~ root or the integral exponen1 ll'.
We can further extend the exponc.ntinl funcuon 10 define b' for any real number
:c, by computing a !.Cries or numbers of the fonn II'' for fractions a/ c that get pro-
grcs!.ivcly clo!.Cr and clo~er 10:c. Any real number :c cnn be approximated orbi1mrily
closely by a rroc1ion a/c: hence. we can use the fraction a/ ca., 1he exponent of b
10 ge1 arbitrarily close 10 b'. For example. the number 211 is well defined. Finally.
given a negative c,poncnl ti. we define It' - 1/ b J. which correspond~ 10 applying
Exponent Rule 3 \\ ith a - 0 and c - - d. For example. 2 ' - I/ 21 - I/ 8.

Geometric Sums
Suppose we have a loop for which each iteration takes a multiplicative factor longer
than the previous one. This loop can be analyzed using the foUowing proposition.
Proposition 3.5: For any integer 11 ~ 0 and any real number a suc/J 111111 a > 0 and
a I I• consider the summation
"
L a' = I + a+ a1 + ·•·+ a"
j 0

(remembering Iha1 a0 = I if a > 0). This !tUmmation is equal lo

a"• ' - I
a- I
Summations as shown in Proposi1ion 3.5 are calJed geometric summations. be-
cause each 1erm is geometrically larger than Lhe pre\,ious one if a > I. For example,
everyone worling in computing should know 1ha1
1
1+2+ -4 +8+ ··+ 211 - 2" - I,
for thi!. i!t the largest integer that can be reprc!>enled in binary norntion u.,ing 11 biL~.
122 Chapter 3. Algorithm Analysis

3.2.1 Comparing Growth Rates

To sum up. Table 3. 1 <.how<;. in order. each or the SC\'en common funcuons used in
algorithm analy'ils.

constant logarithm linear n-log-n quadratic cubic cxpooentiol

l logn n nlogn n-' n' ti'
Table 3.1: Classes or functions. Here we assume lhat a> I is a conslllDt.
Ideally. we would like data slruclure operations 10 run in times proponional
to the constant or logarithm function. and we would like our algorithms to run in
linear or 11-log-n time. Algorithms with quadratic or cubic running times are less
practical. and algorithms with e.,ponential running times are infeasible for a.II but
the smallest siz.ed inputs. Plots of the seven funcuons n.re shown in Figure 3.4.

- 0 - N -Lor,•N
+ -+~+-.......-----------ii---.C-:::---r---,.-,,,.ec;....t--+-___;.-1- l.mr:,r

- 1...op:ithmic
- cODStruJt

"
Figure 3.~: Growth rates for the se,en fundamental functions used in algorithm
analysis. We use base a = 2 for the exponential function. The functions are plotted
on a log-log chan. 10 compare the growth rates primarily as sl~. faen so. the
exponential function grows too fast 10 display all iu \.-alues on the chan.

The Ceiling and Floor Functions

One additional comment concerning the functions above is in order. When dis-
CUSMllg lognrithrru. we noted that the \'alue is generally not an integer. yet the
running time or an algorithm is usually e x ~ by means or an integer quantity,
~uch as the number or operations perfonn.:d. Thus. the analysis or an algorithm
may sometimt!!i imol\.e the U.M! or the floor f unctio11 and ceiling f unctio11. "hich
are ddined r~pecti,ely as follows:
• L-' J = the lnrgest integer less than or equal to x.
• fxl = the smallest integer greater than or equal 10 \'.