Questions? Feel free to head to CS50 on Reddit, CS50 on StackExchange, the #cs50ap channel on CS50x Slack (after signing up), or the CS50 Facebook group.


  • 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.

Academic Honesty

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.

Not Reasonable

  • 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.

Getting Ready

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: srand48 and drand48. srand48 and drand48 are similar in spirit to srand and 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, rand and 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 < and > do, respectively?

  • At the command line, what does | do?

Getting Started

Enough reading and watching. Time for some coding! Log into your CS50 IDE at 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.

Next, execute

cd ~/workspace

at your prompt to ensure that you’re inside of workspace (which is inside of your home directory). Then execute

mkdir unit3

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:

cd unit3

And then, once inside, create another directory inside of that one:

mkdir rng

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!

Planting a Seed

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 srand48 and 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 rng.c file:


It turns out that sometimes it is not quite enough to #include a file to incorporate certain functions therein. Some functions, such as srand48 and 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 _XOPEN_SOURCE).

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 1), if 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.

The Greatest Generation

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 2728, then 29785, then 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 59797, then 10425, then 37569.

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 2728, then 29785, then 54710! See, not so random.

When compiled, 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!

Hmm… Now What?

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) max, and

  • 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.