Hi,

For reference, I am using ANSI C.

I'm a complete noob when it comes to C and pretty much all programming, so please bare with me! I'm sure this will be extremely easy to you guys, but I'm pretty clueless.

I have 2 questions.

I am currently writing a program to use the Newton Raphson method to find a root to an equation. The equation is a non variable. All the user has to do is enter the starting value.

Basically, for those unfamiliar with this mathematical method, you enter a value for x, and the equation works out a new value for x. You keep doing this until your value of x becomes pretty much the same.

I want my program to keep doing the equation until the difference between the two x values is less than 0.001. I'm pretty sure I have to use a do while loop, but I have no idea how to go about it. Any help would be extremely appreciated.



Secondly, this is probably really simple, but I just don't know how to begin. I am writing a program where the user enters a date in the following fashion:

01 05

ie - the above date would be the first of May, or:

06 02

Would be the 6th of february. Then, the user enters a second date in the same manner. It is then calculated how many days are between the two dates the user enters, and it is displayed.

Feb can be taken to have 28 days, so the leap year isn't an issue. But I really don't know what to do with this. Help would, again, be massively appreciated.

Thanks for taking your time to read this.

This is a Good Thing; a Very Good Thing.
OK, First things first:

Before you start writing code, you should state precisely what problem you want the program to solve, and you should state how you think that you want the program to solve it. It's way too early to start thinking about what kind of loop you need. As you develop the program (before writing the code) you might change your mind anyhow. Or, more probably, if you had already made up your mind to use a do{}while(); loop, you might overlook the possibility that a for(){} loop might be more appropriate. Keep an open mind: define exactly what the program is going to do before you start writing the code for how it is going to do it(!)

So, you have stated the input requirements: Get a value from the user.

Your statement of the algorithm is good enough to work with pencil and paper, and is good enough to write program steps in a form that can be used as a guide for implementing the program. Some people call this "pseudo code", since it isn't actually program code (that is, the description is not in terms of C language statements).

Based on your description of your algorithm, I might create a description along the following lines:

Yep, we definitely need some kind of loop, since this is an iterative algorithm, and we don't know ahead of time how many iterations we will require to reach satsifaction.

So, here's the program outline:

1.
declare variables x1 and x2 (probably doubles). x1 will be the old value of x at each step in the program, and x2 will be the newly calculated value each time through the loop.

2.
define the function that takes a value of x and calculates a new value of x.

3.
Define the condition that we will accept as satisfactory: That is, we could define a constant, say absTolerance, to have a value of 0.001, and then we will quit if the absolute value of two successive values of x is less than absTolerance

4.
Go through the loop repeatedly until the exit condition is satisfied.

5.
print out the results (final value, absolute value of difference between last two iterations, maybe the number of iterations required, or whatever).


Now, here is a framework for the active part of the program:


You could create a C (or C++) program that implements the steps in the above description more-or-less exactly as shown.

Here's something to consider: What if, for some reason, we never get two successive values of x that satisfy the exit condition? Maybe we had better put a limit on the number of times the program steps through the loop. How would you add this condition to the pseudo code. Might this affect your decision on what kind of loop to use to implement the program?

How about it? Ready to get at it?

Regards,

Dave

Stop me if you have heard this before, but: This is a Very Good Thing.


The subjects of the questions (the programs themselves) are different, so I decided to make two different replies.

Note that the subject of the replies is the same: program design and development. And note: design (definition) is different from development (implementation). I recommend that you do them in that order. Design first, then development.


Well, "simple" is a matter of context as well as a matter of individual capabilities and attitude. To Mozart, writing a symphony was easy (he started at age four). To my good friend Bou Long Ho, speaking Chinese is easy (he started at age two). As for me, I haven't quite got the hang of either one of these. (Heck, I haven't got a clue about either.)

I doubt that Mozart could tell me how to write a symphony. My friend, Ho, actually tried to teach me a few words, and would have been willing to continue, but he sensed that I had no real passion for learning that at that particular time --- maybe some day???

I do know that many (most?) people can learn to write programs and can be successful in writing good programs if they want to. You don't have to be a prodigy (geniuses don't necessarily make the best programmers, anyhow), and you don't have to be raised in a household speaking C as its first language (no one was born knowing this stuff, you know).

Now as far as telling someone how to write a program??? Well, I can try to give a little narrative so that a person could get started and get to the point where he/she can ask specific questions (about C, for example; about "what does this error message mean", for example; about "why does the output look like this, when I expected the output to be that" for example) that someone here might actually be able to answer.

So: I look at a program in most elementary terms like this:

input==>processing==>output

Here's a high-altitude view of the roadmap: (No program steps yet. Nothing at this stage even depends on what programming language we will use. Don't start writing C or C++ yet. Please.)

1.
Define the input. The user is going to enter from the keyboard two decimal integers, right? The first is going to represent a day of a month and the second is going to represent the month of the year, right? Now, let's get a little specific. The month will be a number between 1 and 12, right? (With 1 for January, 2 for February, etc., right?) Does the user have to enter the leading '0' for January through September? What happens if the user enters "13" for the month. What happens if the user enters "June"? What happens if the user enters "31 06"? What about "06 31"? Remember that you are defining the program, and you can put whatever requirements you want ---unless this is an assignment or contract or whatever, that has been given to you. Also note that in the implementation some validity checking will be part of the Processing phase, rather than the Input phase. Maybe the input phase just tests to see that the required number of numerical inputs are given for the variables and the processing phase will actually test for invalid days and invalid months.

The important point is to know (and state) exactly how the input will be presented. It's not too early to keep in mind that you are going to have to test the program, so be making a list of "good" and "bad" inputs that your program will have to handle.

Anyhow, the user will enter a day and month for two different dates, right?

By the way, you indicated that the first number is the day and the second is the month. Be sure that you make this part of the program specification, since in some certain backwards countries the convention is to state the month first, then the day. Make sure that users of your program know the required input format. (I suggest that you prompt them to enter numeric values for day and month, rather than just saying, "Enter the starting date: ")

2. Define the processing that the program will do with the inputs. Calculate the number of days between the two dates, right?

Now, since there was no indication of how the user would enter a number for the year, can we assume that the two dates are in the same year? What if the starting month and day is later than the ending month and day? Do we reject this as an error? Or do we just assume a roll over to the next year? Define this, and write it as part of the program specification, before you start writing code.

Note that we haven't yet decided how actually count the number of days. Suppose the starting date is June 6 ("06 06", I think) and the ending date is June 8. ("08 06"). How many days are there between the starting date and the ending date? 1? 2? 3? I can think of some cases where the desired answer is 1. I can think of other cases where the desired answer is 2. I can think of other cases where the answer is 3. It's no easier or harder to calculate whichever one of these is required, but you must state what is required. In other words, you have define what you mean by "between".

3. Decide how to present the results to the user.

Printing the results seems not to be a problem once you decide how do calculate the results. You might give some thought on how to report invalid inputs.


Now, once the three steps (input==>processing==>output) have been defined, you can start on the implementation.

Decide on which step to start with. Sometimes people like to get to the "good stuff" first. That is, assume that you have valid inputs (just assign values to the starting month and day and to the ending month and day) and go through the calculations. That's what I call bottom-up implementation, and sometimes I do that myself. You have to recompile the program every time you change an starting or ending date, but for a small program like this, that's not horribly wasteful. Maybe you just run a few tests with a few dates before going to the next step (implementing the user input stuff).

Sometimes people like to start with the input section and get it working before going to the "good stuff". That's not a bad way to do things either. If you do this first, just make sure you can get user input reliably and that you can pass the starting month-day and ending month-day to the calculation phase before you actually work on the calculations. Otherwise (if you write everything before you start testing) you will be debugging input and calculations at the same time. As you make changes to one or the other, you have to test the whole mess all together every time, since --- believe it or not--- changes in one section can affect results in the other section.

I really recommend implement programs a step at a time. Test, test, test each step before going to the next.

Regards,

Dave

"I was born not knowing, and have only had
a little time to change that, here and there."
---Richard Feynman