Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Pseudocode Examples Making Change (in US Currency), Study notes of Russian

•We may also express the algorithm by example: “Suppose you're making change for 67 cents. A maximum of 2 quarters 'fits' into 67 cents, for a total of.

Typology: Study notes

2021/2022

Uploaded on 09/07/2022

nabeel_kk
nabeel_kk 🇸🇦

4.6

(66)

1.3K documents

1 / 7

Toggle sidebar

Related documents


Partial preview of the text

Download Pseudocode Examples Making Change (in US Currency) and more Study notes Russian in PDF only on Docsity! Pseudocode Examples • This is it, folks: using pseudocode as a first step toward expressing ordered, unambiguous, and executable steps that define a terminating process (i.e., an algorithm) initiates you into the realm of computer science • While the textbook contains a more thorough discussion of pseudocode, this is one of those areas where you can’t have too many examples • This handout works through pseudocode approaches to a “make change” algorithm, as well as “Russian peasant multiplication,” an alternative multiplication algorithm Making Change (in US Currency) • While there are many ways to express a “make change” algorithm, we’ll take an approach that illustrates how algorithms can be reused within other algorithms • For this example, we focus on US currency: quarters, dimes, nickels, and pennies • As an aside, think about whether you can: Modify the algorithm to accommodate some other currency/coinage system Modify the algorithm to work with any coinage system Expressing “Make Change” in Human Terms • As mentioned before, knowing how to perform an algorithm does not necessarily mean that we know how to express it in a manner that can be used by a machine • Still, that doesn’t mean we can’t express this algorithm at all — it’s just that human brains can manipulate and infer things that machines cannot (for now) • In natural language, one might say: “Determine the number of quarters to use. Then, from what is left, determine the number of dimes. Do the same for the number of nickels and pennies.” • We may also express the algorithm by example: “Suppose you’re making change for 67 cents. A maximum of 2 quarters ‘fits’ into 67 cents, for a total of 50 cents. With 17 cents remaining, a maximum of 1 dime leaves 7 cents. 1 nickel leaves 2 cents, which finally results in 2 pennies.” • People can handle these expressions of algorithms because we are capable of inductive reasoning — we can infer general principles either from limited information or patterns and examples Given the phrase “determine the number to use,” humans can choose the correct arithmetic operations that make this determination Given the phrase “do the same thing as before,” humans can figure out which steps form the “same thing,” and whether these steps may vary slightly (by denomination, in this example) Given a specific example such as 67 cents, humans can generalize to other amounts Avoiding Redundancy Using countQuarters() as a pattern, it isn’t too hard to figure out the rest of the count() algorithms: procedure countDimes(amount) currentAmount ! amount coinCount ! 0 while (currentAmount ! 10) (coinCount ! coinCount + 1 currentAmount ! currentAmount – 10) return coinCount procedure countNickels(amount) currentAmount ! amount coinCount ! 0 while (currentAmount ! 5) (coinCount ! coinCount + 1 currentAmount ! currentAmount – 5) return coinCount procedure countPennies(amount) currentAmount ! amount coinCount ! 0 while (currentAmount ! 1) (coinCount ! coinCount + 1 currentAmount ! currentAmount – 1) return coinCount …but wait, this looks pretty repetitive! If you’re also thinking that countPennies() looks like overkill, you would be right; for the moment, though, that isn’t the point that we’re making • Note how only the darker sections of each algorithm are different — the overall structure and sequence are otherwise the same • After some staring, we realize that this difference is based on the denomination of the coin — so we can turn that into part of the algorithm’s input! procedure countDimes(amount) currentAmount ! amount coinCount ! 0 while (currentAmount ! 10) (coinCount ! coinCount + 1 currentAmount ! currentAmount – 10) return coinCount procedure countNickels(amount) currentAmount ! amount coinCount ! 0 while (currentAmount ! 5) (coinCount ! coinCount + 1 currentAmount ! currentAmount – 5) return coinCount procedure countPennies(amount) currentAmount ! amount coinCount ! 0 while (currentAmount ! 1) (coinCount ! coinCount + 1 currentAmount ! currentAmount – 1) return coinCount procedure countCoins(amount, denomination) currentAmount ! amount coinCount ! 0 while (currentAmount ! denomination) (coinCount ! coinCount + 1 currentAmount ! currentAmount – denomination) return coinCount Expanding to Other Currencies At this point, our algorithm looks like this: procedure countCoins(amount, denomination) currentAmount ! amount coinCount ! 0 while (currentAmount ! denomination) (coinCount ! coinCount + 1 currentAmount ! currentAmount – denomination) return coinCount procedure makeChange(amount) currentAmount ! amount quarters ! countCoins(currentAmount, 25) currentAmount ! currentAmount – (25 ! quarters) dimes ! countCoins(currentAmount, 10) currentAmount ! currentAmount – (10 ! dimes) nickels ! countCoins(currentAmount, 5) currentAmount ! currentAmount – (5 ! nickels) pennies ! countCoins(currentAmount, 1) return [quarters, dimes, nickels, pennies] Not bad, but it still assumes US currency; can we change this? • As one last tweak, we observe that the notion of “US currency” is just a list of denominations: in this case, [25, 10, 5, 1] • If our algorithm can accept any list of denominations, then we can handle any type of currency! // countCoins() is the same as before. procedure makeChange(amount, denominationList) currentAmount ! amount answerList ! [ ] for each (denomination in denominationList) (coinCount ! countCoins(currentAmount, denomination) currentAmount ! currentAmount – (denomination ! coinCount) answerList[denomination] ! coinCount) return answerList Expanding on our use of “[ ]” brackets to express lists, we show that we can put nothing in between those brackets to indicate an empty list Next, we have a new type of repetition: we use a “for each” phrase to indicate that we’re repeating some set of steps once for each element of the list We re-use “[ ]” brackets to designate individual items in a list — in this case, we want the list of answers to correspond to the list of denominations Russian Peasant Multiplication • Now let’s try the reverse — for makeChange(), we started with an algorithm that we know intuitively, and showed how it can be expressed in pseudocode • This time, let’s look at an algorithm that is already expressed in pseudocode, and see if we can follow its instructions to perform the desired computation • The algorithm is for Russian peasant multiplication — it’s the same multiplication that you know and love (or loathe?), but just done in a different way…and available in two versions… The version on the left builds a list of numbers to sum up in the end (making it easier to do by hand), while the version on the right adds the numbers up right away (making it easier to translate for a computer)…in the end, the result is the same — can you see why? Both versions use one more major tool in specifying algorithms: a conditional statement that does one thing if some condition is true, but does something else (or nothing at all) if that condition is false, indicated by an “if – then” or “if – then – else” construct procedure listRPM(factor1, factor2) if (factor1 > factor2) then (term1 ! factor2 term2 ! factor1) else (term1 ! factor1 term2 ! factor2) addendList ! [ ] while (term1 > 0) (if (term1 is odd) then (add term2 to addendList) term1 ! halveWithoutRemainder(term1) term2 ! double(term2)) product ! 0 for each (number in addendList) (product ! product + number) return product procedure rpm(factor1, factor2) if (factor1 > factor2) then (term1 ! factor2 term2 ! factor1) else (term1 ! factor1 term2 ! factor2) product ! 0 while (term1 > 0) (if (term1 is odd) then (product ! product + term2) term1 ! halveWithoutRemainder(term1) term2 ! double(term2)) return product
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved