Problem: RNG

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 problem sets is not permitted 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 to others, but you may not view theirs, so long as you and they respect this policy’s other constraints. Collaboration on the course’s test and quiz is not permitted at all. Collaboration on the course’s 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 the course’s heads. Acts considered not reasonable by the course are handled harshly. If the course refers some matter for disciplinary action and the outcome is punitive, the course reserves the right to impose local sanctions on top of that outcome that may include an unsatisfactory or failing grade for work submitted or for the course itself. The course ordinarily recommends exclusion (i.e., required withdrawal) from the course itself.

If you commit some act that is not reasonable but bring it to the attention of the course’s heads within 72 hours, the course may impose local sanctions that may include an unsatisfactory or failing grade for work submitted, but the course will not refer the matter for further disciplinary action except in cases of repeated acts.

Your work on this problem set will be evaluated along four axes primarily.

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: srand48 and drand48. srand48 and drand48 are similar in spirit to srand and rand, which you may recall using in Skittles, 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:

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.

Next, execute

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

to create a new chapter3 directory instead of your workspace. As we’ll soon see in this chapter, our programs are going to get a bit more complex and if continue to organize our programs in the same manner we did in Chapters 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 chapter3 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.

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

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.

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 0.041630, then 0.454492, then 0.834817. 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 0.912433, then 0.159083, then 0.573263.

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 0.041630, then 0.454492, then 0.834817! 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 chapter, 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.

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 Chapter 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 chapter, 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:

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.

Completing the submission process for Chapter 3 onward requires that you have turned in all problems from Chapters 0, 1, and 2.