Random Numbers

Random Numbers

Write a function named randomBetween that returns a random floating point number between the two floating point limits you give it as arguments (lower limit first). In the final version, there may be no printf statements in randomBetween; your main function should call it (randomBetween) and print the result. Obviously when you're debugging you can print whereever you want; but I want to make sure you define randomBetween to return a (floating point) value so have main do the final printing, not randomBetween. My printout looks like so:

Enter lower and upper limits separated by a comma: -1.0, +2.0
Your random number is 1.070003

Have main handle the user interaction to obtain the limits for your random number. So randomBetween will be defined as a function with two floating point parameters (i.e., inputs) and returning a floating point value (which will be printed by main).

You'll have to learn to use the library function rand() for this problem. You'd think the interface to rand would be in the math library math.h but for some reason it isn't – it's in stdlib.h, don't ask me why (I'm sure there's a good reason, but I actually don't know it). There's a manual entry for the rand() function that will tell you more than you need to know. (You remember the Unix/Linux man command, right?) For this assignment, you can skip srand() completely – it's described in the manual entry for rand(), but I'm trying to give you a small break here by keeping this problem simple --- don't mess with srand().

There's not a lot of programming in this assignment, but you'll have to think a bit (engineering, remember?) and you'll probably have several steps of think-a-little, build-a-little, test-a-little. You'll also have to get some information you'll need from that manual entry using the man command. Learning to use the manual is an important skill for engineers; that's why RTFM is derogatory. But the first few times you use the Unix/Linux manual, it can appear confusing – it's written so that it can't possibly be misunderstood, which naturally makes it very difficult to understand. If you have trouble with it, come see me and I'll probably be merciful and help you out a bit. But you will need to eventually know how to use the manual on your own. It's a good professional practice, by the way, to prefer to use the man command on the machine you're actually working on rather than a web page somewhere. There are lots of web pages about rand(); they don't all necessarily pertain to the rand that's on your machine. I catch mistakes on web pages all the time, even the Wikipedia. Caveat emptor. But one hopes that the manual on your machine is at least intended to describe the environment on that machine and not some other environment completely.

Notes:

Your source file (e.g., hw5.c) will have two functions in it: main and randomBetween Remember that good style requires the main function to be first. That will create a problem for you that I want you to solve. Perhaps for your first version of this assignment, skip this problem and put randomBetween first and main second and don't mess with changing that around until after everything else works.
Remember: Build-a-little, test-a-little. I think that there are two things here that may give you trouble: (1) Defining a function with parameters that returns a value, and (2) Figuring out how to get a random floating point number (rand returns an integer; there is no function built in to C that returns a random floating point number; that's what you're doing here, writing such a function). So for your first step of build-a-little, test-a-little, try just writing a function that takes in two floating point numbers and returns their sum. After you've succeeded at that, move on to tackle the random number business, perhaps like so:
To get scanf to read two numbers separated by a comma, as these instructions require, put a comma in the format string itself, like so: scanf("%f,%f", …) scanf is a pattern matcher and the format string describes the pattern(s) you want it to look for. %f is the name of a pattern that matches a floating point number. Other characters (not format descriptors that start with a %percent sign) have other meanings --- most mean, "match me exactly". So a format string of "%d,%d" will only match two decimal integers separated by a comma. A format string of "(%d, %d, %d)" would only match a vector of 3 comma-separated integers enclosed in parentheses. Some patterns (e.g., "%f") cause scanf to convert and store values when a pattern is matched. Other patterns, e.g., the comma in "%d, "%d" are just discarded, but if they're not matched, the scanf fails --- e.g., if you type in 34 x 65 when scanf was looking for "%d, %d", scanf will never read the second integer, since the 'x' didn't match the comma that scanf was told to expect.
[This note is optional] You'll note that each time you run your program with the same lower and upper bounds, you'll get the same answer (1.070003, in my examples, above). So does that mean rand() isn't really random after all? Well, there are two issues here, one philosophical, one very practical:

Philosophical: "Random" and "computed by an algorithm" are almost contradictory concepts. Even without computers, the entire subject of the true nature of random numbers has been the subject of a lot of debate over the years. (see, for example, the second paragraph in Wolfram's definition of random number). For this reason, you'll often see computer-generated random numbers referred to as "pseudo-random" values.
Practical: Ignoring the philospophical issues, rand() is in fact fairly decent. But from an engineering standpoint, we often want two seemingly contradictory attributes for machine generated pseudo-random numbers:
1. We want the numbers to be mathematically random (whatever that means), but
2. We often need to be able to generate the same set of random numbers repeatedly so that we can debug our code. E.g., suppose some complex simulation seemed to work right the first time we ran it but malfunctioned the next time. Then when we tried to run it again to debug the problem, it worked properly again. So we might (should, really) suspect that our code has a data-dependent flaw in it somewhere but since we're getting "real" random values for our test data , we can't duplicate the data in that second run again to help us isolate our problem.

rand solves this problem with the concept of a "seed", which is what the srand function (that you needn't bother with for this assignment) is for. Given a seed value, each subsequent call to rand generates a new pseudo-random value. But you'll always get the exact same sequence of pseudo-randoms starting from the same seed value. Since there is a default seed value and our code for this assignment doesn't use srand, each time we execute our program, rand starts fresh from the default seed. If we put a loop in our program to generate a succession of pseudo-random values, we get get a bunch of nicely random looking pseudo-randoms, but then if we ran the same program again (with the same seed) we'd get the same set in the same order. If you ever need to get the most random stuff you can from rand, try using srand and seeding it with a value based on the exact time (to the microsecond) that your program starting running – that's likely to be a fairly random starting point, no? (The library function gettimeofday returns the current time down to the microsecond, although using it [gettimeofday] can be a bit of a pain – it uses some programming constructs we haven't covered yet, although we will before this semester is over.)