Learn more about pseudorandom numbers.
Begin to introduce you to larger programs and programs with multiple source files.
Learn about rudimentary file input and output via redirection.
Page 17 of http://www.howstuffworks.com/c.htm.
Chapters 20 and 23 of Absolute Beginner’s Guide to C.
Chapters 13, 15, and 18 of Programming in C.
This course’s philosophy on academic honesty is best stated as "be reasonable." The course recognizes that interactions with classmates and others can facilitate mastery of the course’s material. However, there remains a line between enlisting the help of another and submitting the work of another. This policy characterizes both sides of that line.
The essence of all work that you submit to this course must be your own. Collaboration on problems is not permitted (unless explicitly stated otherwise) except to the extent that you may ask classmates and others for help so long as that help does not reduce to another doing your work for you. Generally speaking, when asking for help, you may show your code or writing to others, but you may not view theirs, so long as you and they respect this policy’s other constraints. Collaboration on quizzes and tests is not permitted at all. Collaboration on the final project is permitted to the extent prescribed by its specification.
Below are rules of thumb that (inexhaustively) characterize acts that the course considers reasonable and not reasonable. If in doubt as to whether some act is reasonable, do not commit it until you solicit and receive approval in writing from your instructor. If a violation of this policy is suspected and confirmed, your instructor reserves the right to impose local sanctions on top of any disciplinary outcome that may include an unsatisfactory or failing grade for work submitted or for the course itself.
Communicating with classmates about problems in English (or some other spoken language).
Discussing the course’s material with others in order to understand it better.
Helping a classmate identify a bug in his or her code, such as by viewing, compiling, or running his or her code, even on your own computer.
Incorporating snippets of code that you find online or elsewhere into your own code, provided that those snippets are not themselves solutions to assigned problems and that you cite the snippets' origins.
Reviewing past years' quizzes, tests, and solutions thereto.
Sending or showing code that you’ve written to someone, possibly a classmate, so that he or she might help you identify and fix a bug.
Sharing snippets of your own solutions to problems online so that others might help you identify and fix a bug or other issue.
Turning to the web or elsewhere for instruction beyond the course’s own, for references, and for solutions to technical difficulties, but not for outright solutions to problems or your own final project.
Whiteboarding solutions to problems with others using diagrams or pseudocode but not actual code.
Working with (and even paying) a tutor to help you with the course, provided the tutor does not do your work for you.
Accessing a solution to some problem prior to (re-)submitting your own.
Asking a classmate to see his or her solution to a problem before (re-)submitting your own.
Decompiling, deobfuscating, or disassembling the staff’s solutions to problems.
Failing to cite (as with comments) the origins of code, writing, or techniques that you discover outside of the course’s own lessons and integrate into your own work, even while respecting this policy’s other constraints.
Giving or showing to a classmate a solution to a problem when it is he or she, and not you, who is struggling to solve it.
Looking at another individual’s work during a quiz or test.
Paying or offering to pay an individual for work that you may submit as (part of) your own.
Providing or making available solutions to problems to individuals who might take this course in the future.
Searching for, soliciting, or viewing a quiz’s questions or answers prior to taking the quiz.
Searching for or soliciting outright solutions to problems online or elsewhere.
Splitting a problem’s workload with another individual and combining your work (unless explicitly authorized by the problem itself).
Submitting (after possibly modifying) the work of another individual beyond allowed snippets.
Submitting the same or similar work to this course that you have submitted or will submit to another.
Using resources during a quiz beyond those explicitly allowed in the quiz’s instructions.
Viewing another’s solution to a problem and basing your own solution on it.
Your work on this problem set will be evaluated along four axes primarily.
To what extent does your code implement the features required by our specification?
To what extent is your code consistent with our specifications and free of bugs?
To what extent is your code written well (i.e., clearly, efficiently, elegantly, and/or logically)?
To what extent is your code readable (i.e., commented and indented with variables aptly named)?
To obtain a passing grade in this course, all students must ordinarily submit all assigned problems unless granted an exception in writing by the instructor.
First, say hello to Tommy, who’s here to teach you a bit about some basic file input and output techniques using the command line.
Next, read up on two functions you’ll probably want to know a thing or two about for this problem:
drand48 are similar in spirit to
rand, which you may recall using in Problem 1-4, but perform their calculations using 48-bit arithmetic. Suffice it to say, given identical seeds,
drand48 will generate different sets of pseudorandom numbers.
Before moving on, be sure you’re comfortable answering the following questions:
What is a "seed" to a random number generator (RNG)?
Why do we describe the numbers generated by an RNG as pseudorandom and not truly "random"?
At the command line, what do
At the command line, what does
Enough reading and watching. Time for some coding! Log into your CS50 IDE at cs50.io and execute
within a terminal window to make sure your workspace is up-to-date.
If you somehow closed your terminal window (and can’t find it!), make sure that Console is checked under the View menu, then click the green, circled plus (+) in CS50 IDE’s bottom half, then select New Terminal.
at your prompt to ensure that you’re inside of
workspace (which is inside of your home directory). Then execute
to create a new
unit3 directory instead of your workspace. As we’ll soon see in this unit, our programs are going to get a bit more complex and if continue to organize our programs in the same manner we did in Units 1 and 2, our directory will rapidly become cluttered. To that end, we’re going to add an additional level to our directory’s hierarchy so as to help us keep things a bit more organized. So, navigate inside of your
unit3 directory, as with:
And then, once inside, create another directory inside of that one:
Then navigate into that folder (remember how?) and create a new file therein (remember how?) called
rng.c. You’re now ready to write a (pseudo)random number generator!
In this program, you’ll be implementing a program that allows the user to specify how many numbers they would like generated, each of which is capped at some maximum value, with the user optionally able to seed the generator with a seed of their choosing, otherwise relying on some other seed that is always changing, the canonical example being the current time. The user will be providing all of this information to you at the command line.
Notice the important keyword in the above paragraph: optionally. This program, unlike those you’ve written so far, can accept a variable number of command line arguments, and depending on how many command line arguments the user provides, you’ll either seed the random number generator with the user-specified seed or with the current time.
In particular, this should be the correct use case of your program, and if the user does not adhere to this usage, you should exit the program (returning
1) after informing the user of the correct usage.
Usage: rng n max [s]
In general, we’re going to take a hands-off approach here, as we’d like you to start muddling through some documentation to determine the correct way to use some built-in functions. But we will point out two things your program needs to do to conform to our specifications.
First, in order to use the
drand48 functions, you not only need to include the library specified in their manual pages, you also need to place the following line of code near the very top of your
It turns out that sometimes it is not quite enough to
#include a file to incorporate certain functions therein. Some functions, such as
drand48, require you to also place in your program a so-called feature test macro. In CS50 AP, we don’t particularly care what that means and won’t elaborate on it (though you are welcome and encouraged to explore on your own!) The important takeaway here though is that we learned as much by perusing the manual pages for those functions and saw therein that we were required to
#define _XOPEN_SOURCE (or
#define _SVID_SOURCE, but conventionally in this course when we encounter the choice we will default to
The other thing we would like you to do is to
#define LIMIT 65536
for reasons that have absolutely no relevance now, but rather is a setup for something in the future. Read to the end of the spec for more info! You should, however, exit your program (returning
max (provided by the user at the command line) exceeds the defined constant
LIMIT, and of course should inform the user as to why your program has terminated.
As this program’s usage suggests, this program expects two or three command-line arguments. The first,
n, is required; it indicates how many pseudorandom numbers you’d like to generate. The second,
max, is also required; it indicates the maximum possible value a number that is generated by your program can be (in other words, an "upper bound". The third argument
s, is optional, as the brackets are meant to imply; if supplied, it represents the value that the pseudorandom-number generator should use as its "seed." A seed is simply an input to a pseudorandom-number generator that influences its outputs.
For instance, if you seed
drand48 by first calling
srand48 with an argument of, say,
1, and then call
drand48 itself three times,
drand48 might return
54710. But if you instead seed
drand48 by first calling
srand48 with an argument of, say,
2, and then call
drand48 itself three times,
drand48 might instead return
But if you re-seed
drand48 by calling
srand48 again with an argument of
1, the next three times you call
drand48, you’ll again get
54710! See, not so random.
rng should print out the numbers it generates, one per line, to the terminal window. But what if we wanted to save that list of numbers for whatever reason? We’ll learn about some more rich techniques for "file I/O" in the coming unit, but fortunately Linux has a very simple way of writing information more permanently to files. You can "redirect" `rng’s terminal output to a file with a command like the below.
./rng 1000 60000 > numbers.txt
We’ll be using this feature soon enough!
Incidentally, this program isn’t terribly interesting. In fact, you’re probably thinking that we’ve asked you to write more complex programs in Unit 2 than what you’ve just written. Well, you’d be right. But this won’t be the last time we see
rng. Later on in this unit, you’ll be using the work you’ve done on this problem to help test out your solution to another problem. But more on that soon.
When ready to check the correctness of your program officially with
check50… well, you can’t. Reason being that the way the staff solution generates random numbers might in fact be different from your own, even though both do properly generate sets of random numbers. It’s up to you to determine that your program produces:
the correct number of pseudorandomly generated numbers,
each of which is greater than or equal to 0 and also less than (and not equal to)
that if your program is run with the same seed value multiple times, the list of numbers it generates is identical from run to run.
Not having access to
check50 for this problem is actually a good thing. It’s a bad idea to get into the habit of testing your code with
check50 before testing it yourself. (And definitely don’t get into an even worse habit of only testing your code with
check50!) Suffice it to say
check50 doesn’t exist in the real world, so running your code with your own sample inputs, comparing actual output against expected output, is the best habit to get into sooner rather than later.
Truly, don’t do yourself a long-term disservice!
Anyhow, if you’d like to play with the staff’s own implementation of
rng (which may generate a different set of numbers than your own implementation even given identical inputs, and that’s okay!), you may execute the below.
This was Problem 3-0.