{"id":182,"date":"2024-07-30T06:50:36","date_gmt":"2024-07-30T06:50:36","guid":{"rendered":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/chapter\/what-is-big-o\/"},"modified":"2026-03-16T14:30:55","modified_gmt":"2026-03-16T14:30:55","slug":"what-is-big-o","status":"publish","type":"chapter","link":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/chapter\/what-is-big-o\/","title":{"raw":"What is Big O?","rendered":"What is Big O?"},"content":{"raw":"<div class=\"what-is-big-o?\">\n<p class=\"import-Normal\">When comparing algorithms, it is typically not sufficient to describe how one algorithm performs for a given set of inputs. We typically want to quantify how much better one algorithm performs when compared to another for a given set of inputs. To describe the cost of a software function (in terms of either time or space), we must first represent that cost using a mathematical function. Let us reconsider finding the ace of spades. How many cards will we have to inspect? If it is the top card in the deck, we only have to inspect 1. If it is the bottom card, we will have to inspect 52. Immediately, we start to see that we must be more precise when defining this function. When analyzing algorithms, there are three primary cases of concern:<\/p>\n\n<ul>\n \t<li class=\"import-Normal\" style=\"text-indent: 18pt\"><strong>Worst case:<\/strong> This function describes the most comparisons we may have to make given the current algorithm. In our ace of spades example, this is represented by the scenario when the ace of spades was the bottom card in the deck. If we wish to represent this as a function, we may define it as f(n) = n. In other words, if you have 52 cards, the most comparisons you will have to perform will be 52. If you add two jokers and now have 54 cards, you now have to perform at most 54 comparisons.<\/li>\n \t<li class=\"import-Normal\" style=\"text-indent: 18pt\"><strong>Average case:<\/strong> This function describes what we would typically have to do when performing an algorithm many times. For example, imagine your professor asked you to first find the ace of spades, then 2 of spades, then 3 of spades, until you have performed the search for every card in the deck. If you left the card in the deck each round, some cards would be near the top of the deck and others would be near the end. Eventually, each iteration would have a cost function of roughly f(n) = n\/2.<\/li>\n \t<li class=\"import-Normal\" style=\"text-indent: 18pt\"><strong>Amortized case:<\/strong> This is a challenging case to explain early in this book. Essentially, it arises whenever you have an expensive set of operations that only occur sometimes. We will encounter this in the resizing of hash tables as well as the prerequisites for Binary Search.<\/li>\n<\/ul>\n<p class=\"import-Normal\">You may wonder why best-case scenarios are not considered. In most algorithms, the best case is typically a small, fixed cost and is therefore not very useful when comparing algorithms.<\/p>\n\n<h3>Asymptotic Analysis<\/h3>\n<p class=\"import-Normal\">Thus, rather than comparing algorithms based on a speed test or the exact number of operations involved, algorithms are compared using <strong>[pb_glossary id=\"238\"]Asymptotic analysis[\/pb_glossary]. <\/strong>Asymptotic analysis measures the efficiency of an algorithm, or its implementation as a program, as the input size becomes large. The term \"asymptotic\" here means basically \"the tendency in the long run, as the size of the input is increased.\" An asymptotic analysis of an algorithm's run time looks at the question of how the run time depends on the size of the problem. The analysis is asymptotic because it only considers what happens to the run time as the size of the problem increases without limit; it is not concerned with what happens for problems of small size or, in fact, for problems of any fixed finite size. Only what happens in the long run, as the problem size increases without limit, is important.<\/p>\n<p class=\"import-Normal\">There are a few important assumptions and generalizations we're going to make when using asymptotic analysis.<\/p>\n\n<ul>\n \t<li class=\"import-Normal\" style=\"text-indent: 18pt\">When we describe the runtime as a function, the function will be in terms of the size of the input. We will use N to represent the size of the input.<\/li>\n \t<li class=\"import-Normal\" style=\"text-indent: 18pt\">We're going to treat all operations as if they cost the same. Technically, multiplication is a more expensive operation than addition, certain memory operations take longer than others, etc. Those differences do not matter in this case.<\/li>\n \t<li class=\"import-Normal\" style=\"text-indent: 18pt\">We are comparing the <strong>[pb_glossary id=\"239\"]growth rate[\/pb_glossary] <\/strong>of the algorithms. That is, we are only concerned with how well the algorithm scales as the size of the input increases. Does it take three times more operations or N^2 more operations if we double the size of the input, N? We consider the algorithm that only takes three times more operations as the \"more efficient\" algorithm.<\/li>\n \t<li class=\"import-Normal\" style=\"text-indent: 18pt\">We only care about the growth rate after some particular value of N. This is where the \"asymptotic\" part comes in. Algorithm A is better than Algorithm B as long, after some point, Algorithm A grows more slowly than Algorithm B.<\/li>\n \t<li>Growth rates are typically expressed as one of the following functions: [latex]1, logn, n, nlogn, n^x, 2^n[\/latex].\u00a0 These are shown on the graph below.\u00a0 You can see the relative rate of growth of each function.<\/li>\n<\/ul>\n<p class=\"import-Normal\"><img class=\"\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/21\/2024\/07\/image122-1.png\" alt=\"image\" width=\"402\" height=\"402\"><\/p>\n<p class=\"import-Normal\">Figure by <a class=\"rId143\" href=\"https:\/\/commons.wikimedia.org\/wiki\/User:Cmglee\">Cmglee<\/a> under <a class=\"rId145\" href=\"https:\/\/creativecommons.org\/licenses\/by-sa\/4.0\/deed.en\">CC BY-SA 4.0<\/a><\/p>\n\n<h4>Example: Largest-Value Sequential Search<\/h4>\n<p class=\"import-Normal\">Consider a simple algorithm to solve the problem of finding the largest value in an array of N integers. The algorithm looks at each integer in turn, saving the position of the largest value seen so far. This algorithm is called the largest-value sequential search and is illustrated by the following function:<\/p>\n\n<pre>\/\/ Return position of largest value in integer array A\nstatic int largest(int[] A) {\n\u00a0\u00a0\u00a0\u00a0 int currlarge = 0; \/\/ Position of largest element seen\n \u00a0\u00a0  for (int i=1; i&lt;A.length; i++) { \/\/ For each element\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 if (A[currlarge] &lt; A[i]) {\/\/ if A[i] is larger\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 currlarge = i; \/\/ remember its position\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\n\u00a0\u00a0\u00a0 }\n\u00a0\u00a0\u00a0 return currlarge; \/\/ Return largest position\n}\n\n<\/pre>\n<p class=\"import-Normal\">Here, the size of the problem is A.length, the number of integers stored in array A. The basic operation is to compare an integer\u2019s value to that of the largest value seen so far. It is reasonable to assume that it takes a fixed amount of time to do one such comparison, regardless of the value of the two integers or their positions in the array.<\/p>\n<p class=\"import-Normal\">Because the most important factor affecting running time is normally the size of the input, for a given input size N, we often express the time T to run the algorithm as a function of n, written as T(n). We will always assume T(n) is a non-negative value.<\/p>\n<p class=\"import-Normal\">Let us call <em>c <\/em>the amount of time required to compare two integers in function largest. We do not care right now what the precise value of <em>c<\/em> might be. Nor are we concerned with the time required to increment variable i because this must be done for each value in the array, or the time for the actual assignment when a larger value is found, or the little bit of extra time taken to initialize <em>currlarge<\/em>. We just want a reasonable approximation for the time taken to execute the algorithm. The total time to run largest is therefore approximately <em>cN<\/em>, because we must make N comparisons, with each comparison costing <em>c <\/em>time. We say that function largest (and by extension, the largest-value sequential search algorithm for any typical implementation) has a running time expressed by the equation<\/p>\n<p class=\"import-Normal\">[latex]T(n)=cn[\/latex]<\/p>\n<p class=\"import-Normal\">This equation describes the growth rate for the running time of the largest-value sequential search algorithm.<\/p>\n\n<h3>Big O Notation<\/h3>\n<p class=\"import-Normal\">Asymptotic notation gives us a way of describing how the output of a function grows as the inputs become bigger. There are several notations used, but the most important is Big-O. Most often stylized with a capital O, this notation enables us to classify cost functions into various well-known sets. Big-O provides an upper bound for the growth of the runtime. It indicates the upper or highest growth rate that the algorithm can have.<\/p>\n<p class=\"import-Normal\">Because the phrase \u201chas an upper bound to its growth rate of f(n)\u201d is long and often used when discussing algorithms, we adopt a special notation, called Big O notation. If the upper bound for an algorithm\u2019s growth rate (for, say, the worst case) is (f(n)), then we would write that this algorithm is \u201cin the set O(f(n)) in the worst case\u201d (or just \u201cin O(f(n)) in the worst case\u201d). For example, if n<sup>2<\/sup> grows as fast as T(n) (the running time of our algorithm) for the worst-case input, we would say the algorithm is \u201cin O(n<sup>2<\/sup>) in the worst case\u201d.<\/p>\n<p class=\"import-Normal\">Formally, we define Big-O as follows:<\/p>\n<p class=\"import-Normal\" style=\"text-align: center\">f(n) = O(g(n)) if f(n) \u2264 cg(n) for some c &gt; 0 and all n &gt; n<sub>0<\/sub>.<\/p>\n<p class=\"import-Normal\">The constant n<sub>0<\/sub> is the smallest value of n for which the claim of an upper bound holds true. Usually n<sub>0<\/sub> is small, such as 1, but does not need to be. You must also be able to pick some constant <em>c<\/em>, but it is irrelevant what the value for <em>c<\/em> actually is. In other words, the definition says that for all inputs of the type in question (such as the worst case for all inputs of size n) that are large enough (i.e., n &gt; n0), the algorithm always executes in less than or equal to <em>cf(n)<\/em> steps for some constant c.<\/p>\n\n<h3>Example<\/h3>\n<p class=\"import-Normal\">Given T(N) = 64N, we can say T(N) is O(N<sup>2<\/sup>) because there is some positive constant <em>c<\/em> and some value of N for which T(N) \u2264 N<sup>2<\/sup>. The graphs below provide visual proof. Note that the first graph shows 64N &gt; N<sup>2 <\/sup>when 0 &lt; N &lt; 10. This is allowable. Eventually, there is a value of N where from that point on, N<sup>2 <\/sup>&gt; 64N (as shown in the second graph).<\/p>\n<p class=\"import-Normal\"><img src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/21\/2026\/03\/image11-1.png\" alt=\"image\" width=\"2048px\" height=\"626px\"><\/p>\n<p class=\"import-Normal\"><img src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/21\/2026\/03\/image120-1.png\" alt=\"image\" width=\"2048px\" height=\"659px\"><\/p>\n\n<div class=\"textbox textbox--exercises\"><header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>Test Yourself<\/strong><\/p>\n\n<\/header>\n<div class=\"textbox__content\">\n<p class=\"import-Normal\">For each function below, is it O(n), O(n<sup>2<\/sup>), or both?<\/p>\n<p class=\"import-Normal\">a. f(n) = 8n + 4n<\/p>\n<p class=\"import-Normal\">b. f(n) = n(n+1)\/2<\/p>\n<p class=\"import-Normal\">c. f(n) = 12<\/p>\n<p class=\"import-Normal\">d. f(n) = 1000n2<\/p>\n\n<\/div>\n<\/div>\n&nbsp;\n\n<\/div>","rendered":"<div class=\"what-is-big-o?\">\n<p class=\"import-Normal\">When comparing algorithms, it is typically not sufficient to describe how one algorithm performs for a given set of inputs. We typically want to quantify how much better one algorithm performs when compared to another for a given set of inputs. To describe the cost of a software function (in terms of either time or space), we must first represent that cost using a mathematical function. Let us reconsider finding the ace of spades. How many cards will we have to inspect? If it is the top card in the deck, we only have to inspect 1. If it is the bottom card, we will have to inspect 52. Immediately, we start to see that we must be more precise when defining this function. When analyzing algorithms, there are three primary cases of concern:<\/p>\n<ul>\n<li class=\"import-Normal\" style=\"text-indent: 18pt\"><strong>Worst case:<\/strong> This function describes the most comparisons we may have to make given the current algorithm. In our ace of spades example, this is represented by the scenario when the ace of spades was the bottom card in the deck. If we wish to represent this as a function, we may define it as f(n) = n. In other words, if you have 52 cards, the most comparisons you will have to perform will be 52. If you add two jokers and now have 54 cards, you now have to perform at most 54 comparisons.<\/li>\n<li class=\"import-Normal\" style=\"text-indent: 18pt\"><strong>Average case:<\/strong> This function describes what we would typically have to do when performing an algorithm many times. For example, imagine your professor asked you to first find the ace of spades, then 2 of spades, then 3 of spades, until you have performed the search for every card in the deck. If you left the card in the deck each round, some cards would be near the top of the deck and others would be near the end. Eventually, each iteration would have a cost function of roughly f(n) = n\/2.<\/li>\n<li class=\"import-Normal\" style=\"text-indent: 18pt\"><strong>Amortized case:<\/strong> This is a challenging case to explain early in this book. Essentially, it arises whenever you have an expensive set of operations that only occur sometimes. We will encounter this in the resizing of hash tables as well as the prerequisites for Binary Search.<\/li>\n<\/ul>\n<p class=\"import-Normal\">You may wonder why best-case scenarios are not considered. In most algorithms, the best case is typically a small, fixed cost and is therefore not very useful when comparing algorithms.<\/p>\n<h3>Asymptotic Analysis<\/h3>\n<p class=\"import-Normal\">Thus, rather than comparing algorithms based on a speed test or the exact number of operations involved, algorithms are compared using <strong><a class=\"glossary-term\" aria-haspopup=\"dialog\" aria-describedby=\"definition\" href=\"#term_182_238\">Asymptotic analysis<\/a>. <\/strong>Asymptotic analysis measures the efficiency of an algorithm, or its implementation as a program, as the input size becomes large. The term &#8220;asymptotic&#8221; here means basically &#8220;the tendency in the long run, as the size of the input is increased.&#8221; An asymptotic analysis of an algorithm&#8217;s run time looks at the question of how the run time depends on the size of the problem. The analysis is asymptotic because it only considers what happens to the run time as the size of the problem increases without limit; it is not concerned with what happens for problems of small size or, in fact, for problems of any fixed finite size. Only what happens in the long run, as the problem size increases without limit, is important.<\/p>\n<p class=\"import-Normal\">There are a few important assumptions and generalizations we&#8217;re going to make when using asymptotic analysis.<\/p>\n<ul>\n<li class=\"import-Normal\" style=\"text-indent: 18pt\">When we describe the runtime as a function, the function will be in terms of the size of the input. We will use N to represent the size of the input.<\/li>\n<li class=\"import-Normal\" style=\"text-indent: 18pt\">We&#8217;re going to treat all operations as if they cost the same. Technically, multiplication is a more expensive operation than addition, certain memory operations take longer than others, etc. Those differences do not matter in this case.<\/li>\n<li class=\"import-Normal\" style=\"text-indent: 18pt\">We are comparing the <strong><a class=\"glossary-term\" aria-haspopup=\"dialog\" aria-describedby=\"definition\" href=\"#term_182_239\">growth rate<\/a> <\/strong>of the algorithms. That is, we are only concerned with how well the algorithm scales as the size of the input increases. Does it take three times more operations or N^2 more operations if we double the size of the input, N? We consider the algorithm that only takes three times more operations as the &#8220;more efficient&#8221; algorithm.<\/li>\n<li class=\"import-Normal\" style=\"text-indent: 18pt\">We only care about the growth rate after some particular value of N. This is where the &#8220;asymptotic&#8221; part comes in. Algorithm A is better than Algorithm B as long, after some point, Algorithm A grows more slowly than Algorithm B.<\/li>\n<li>Growth rates are typically expressed as one of the following functions: [latex]1, logn, n, nlogn, n^x, 2^n[\/latex].\u00a0 These are shown on the graph below.\u00a0 You can see the relative rate of growth of each function.<\/li>\n<\/ul>\n<p class=\"import-Normal\"><img decoding=\"async\" class=\"\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/21\/2024\/07\/image122-1.png\" alt=\"image\" width=\"402\" height=\"402\" \/><\/p>\n<p class=\"import-Normal\">Figure by <a class=\"rId143\" href=\"https:\/\/commons.wikimedia.org\/wiki\/User:Cmglee\">Cmglee<\/a> under <a class=\"rId145\" href=\"https:\/\/creativecommons.org\/licenses\/by-sa\/4.0\/deed.en\">CC BY-SA 4.0<\/a><\/p>\n<h4>Example: Largest-Value Sequential Search<\/h4>\n<p class=\"import-Normal\">Consider a simple algorithm to solve the problem of finding the largest value in an array of N integers. The algorithm looks at each integer in turn, saving the position of the largest value seen so far. This algorithm is called the largest-value sequential search and is illustrated by the following function:<\/p>\n<pre>\/\/ Return position of largest value in integer array A\nstatic int largest(int[] A) {\n\u00a0\u00a0\u00a0\u00a0 int currlarge = 0; \/\/ Position of largest element seen\n \u00a0\u00a0  for (int i=1; i&lt;A.length; i++) { \/\/ For each element\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 if (A[currlarge] &lt; A[i]) {\/\/ if A[i] is larger\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 currlarge = i; \/\/ remember its position\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\n\u00a0\u00a0\u00a0 }\n\u00a0\u00a0\u00a0 return currlarge; \/\/ Return largest position\n}\n\n<\/pre>\n<p class=\"import-Normal\">Here, the size of the problem is A.length, the number of integers stored in array A. The basic operation is to compare an integer\u2019s value to that of the largest value seen so far. It is reasonable to assume that it takes a fixed amount of time to do one such comparison, regardless of the value of the two integers or their positions in the array.<\/p>\n<p class=\"import-Normal\">Because the most important factor affecting running time is normally the size of the input, for a given input size N, we often express the time T to run the algorithm as a function of n, written as T(n). We will always assume T(n) is a non-negative value.<\/p>\n<p class=\"import-Normal\">Let us call <em>c <\/em>the amount of time required to compare two integers in function largest. We do not care right now what the precise value of <em>c<\/em> might be. Nor are we concerned with the time required to increment variable i because this must be done for each value in the array, or the time for the actual assignment when a larger value is found, or the little bit of extra time taken to initialize <em>currlarge<\/em>. We just want a reasonable approximation for the time taken to execute the algorithm. The total time to run largest is therefore approximately <em>cN<\/em>, because we must make N comparisons, with each comparison costing <em>c <\/em>time. We say that function largest (and by extension, the largest-value sequential search algorithm for any typical implementation) has a running time expressed by the equation<\/p>\n<p class=\"import-Normal\">[latex]T(n)=cn[\/latex]<\/p>\n<p class=\"import-Normal\">This equation describes the growth rate for the running time of the largest-value sequential search algorithm.<\/p>\n<h3>Big O Notation<\/h3>\n<p class=\"import-Normal\">Asymptotic notation gives us a way of describing how the output of a function grows as the inputs become bigger. There are several notations used, but the most important is Big-O. Most often stylized with a capital O, this notation enables us to classify cost functions into various well-known sets. Big-O provides an upper bound for the growth of the runtime. It indicates the upper or highest growth rate that the algorithm can have.<\/p>\n<p class=\"import-Normal\">Because the phrase \u201chas an upper bound to its growth rate of f(n)\u201d is long and often used when discussing algorithms, we adopt a special notation, called Big O notation. If the upper bound for an algorithm\u2019s growth rate (for, say, the worst case) is (f(n)), then we would write that this algorithm is \u201cin the set O(f(n)) in the worst case\u201d (or just \u201cin O(f(n)) in the worst case\u201d). For example, if n<sup>2<\/sup> grows as fast as T(n) (the running time of our algorithm) for the worst-case input, we would say the algorithm is \u201cin O(n<sup>2<\/sup>) in the worst case\u201d.<\/p>\n<p class=\"import-Normal\">Formally, we define Big-O as follows:<\/p>\n<p class=\"import-Normal\" style=\"text-align: center\">f(n) = O(g(n)) if f(n) \u2264 cg(n) for some c &gt; 0 and all n &gt; n<sub>0<\/sub>.<\/p>\n<p class=\"import-Normal\">The constant n<sub>0<\/sub> is the smallest value of n for which the claim of an upper bound holds true. Usually n<sub>0<\/sub> is small, such as 1, but does not need to be. You must also be able to pick some constant <em>c<\/em>, but it is irrelevant what the value for <em>c<\/em> actually is. In other words, the definition says that for all inputs of the type in question (such as the worst case for all inputs of size n) that are large enough (i.e., n &gt; n0), the algorithm always executes in less than or equal to <em>cf(n)<\/em> steps for some constant c.<\/p>\n<h3>Example<\/h3>\n<p class=\"import-Normal\">Given T(N) = 64N, we can say T(N) is O(N<sup>2<\/sup>) because there is some positive constant <em>c<\/em> and some value of N for which T(N) \u2264 N<sup>2<\/sup>. The graphs below provide visual proof. Note that the first graph shows 64N &gt; N<sup>2 <\/sup>when 0 &lt; N &lt; 10. This is allowable. Eventually, there is a value of N where from that point on, N<sup>2 <\/sup>&gt; 64N (as shown in the second graph).<\/p>\n<p class=\"import-Normal\"><img decoding=\"async\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/21\/2026\/03\/image11-1.png\" alt=\"image\" width=\"2048px\" height=\"626px\" \/><\/p>\n<p class=\"import-Normal\"><img decoding=\"async\" src=\"https:\/\/libraryresources.nse.org.ng\/wp-content\/uploads\/sites\/21\/2026\/03\/image120-1.png\" alt=\"image\" width=\"2048px\" height=\"659px\" \/><\/p>\n<div class=\"textbox textbox--exercises\">\n<header class=\"textbox__header\">\n<p class=\"textbox__title\"><strong>Test Yourself<\/strong><\/p>\n<\/header>\n<div class=\"textbox__content\">\n<p class=\"import-Normal\">For each function below, is it O(n), O(n<sup>2<\/sup>), or both?<\/p>\n<p class=\"import-Normal\">a. f(n) = 8n + 4n<\/p>\n<p class=\"import-Normal\">b. f(n) = n(n+1)\/2<\/p>\n<p class=\"import-Normal\">c. f(n) = 12<\/p>\n<p class=\"import-Normal\">d. f(n) = 1000n2<\/p>\n<\/div>\n<\/div>\n<p>&nbsp;<\/p>\n<\/div>\n<div class=\"glossary\"><span class=\"screen-reader-text\" id=\"definition\">definition<\/span><template id=\"term_182_238\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_182_238\"><div tabindex=\"-1\"><p>A method for estimating the efficiency of an algorithm or computer program by identifying its growth rate. Asymptotic analysis also gives a way to define the inherent difficulty of a problem. We frequently use the term algorithm analysis to mean the same thing.<\/p>\n<\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><template id=\"term_182_239\"><div class=\"glossary__definition\" role=\"dialog\" data-id=\"term_182_239\"><div tabindex=\"-1\"><p>In algorithm analysis, the rate at which the cost of the algorithm grows as the size of its input grows.<\/p>\n<\/div><button><span aria-hidden=\"true\">&times;<\/span><span class=\"screen-reader-text\">Close definition<\/span><\/button><\/div><\/template><\/div>","protected":false},"author":1,"menu_order":3,"template":"","meta":{"pb_show_title":"","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[49],"contributor":[],"license":[],"class_list":["post-182","chapter","type-chapter","status-publish","hentry","chapter-type-numberless"],"part":174,"_links":{"self":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters\/182","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":2,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters\/182\/revisions"}],"predecessor-version":[{"id":255,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters\/182\/revisions\/255"}],"part":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/parts\/174"}],"metadata":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapters\/182\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/media?parent=182"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/pressbooks\/v2\/chapter-type?post=182"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/contributor?post=182"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/libraryresources.nse.org.ng\/computersciencetwo\/wp-json\/wp\/v2\/license?post=182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}