Math Excellence

Empower With MathPower

Wednesday, December 7, 2011

Hitler Does Calculus!

Posted by Math Excellence at 9:10 PM No comments:

Email This BlogThis!Share to X Share to Facebook Share to Pinterest

Newer Posts Older Posts Home

Subscribe to: Posts (Atom)

Welcome To Math Excellence!

We are here to provide you with EXCEPTIONAL Math tutoring that will enable you to accomplish many great things in the future.

Please call us at 626.618.3815 and ask about our 2 hour block instruction programs that we offer from 3.30 pm - 5.30 pm, and 6.00 pm- 8.00pm, Mon- Fri.

Now is the time to take action and eliminate problems at school before they even begin.

Enroll today.

Call us today at 626.618.3815. Or, send us an email at:

ferndogster@yahoo.com

Thanks.

Math Excellence 626.618.3815

USNA

Boeing

Pulsar

EMPOWER

Math Log

CODE It Baby!

Powered by Python

MatLab by MathWorks

Feynman Diagrams

String Theory

Northrop Grumman

Lockheed Martin

President Kennedy

Lift Off! Apollo 11

Contact Us

We are located at :

9521 Flaherty Street

Temple City, CA 91780

626.618.3815

626.285.2405

email us at:

ferndogster@yahoo.com

Join Us On FB. Thanks!

Calculator

Followers

Blog Archive

► 2013 (1)
- ► April (1)

► 2012 (1)
- ► March (1)

▼ 2011 (19)
- ▼ December (1)
  - Hitler Does Calculus!
- ► November (11)
- ► October (2)
- ► September (2)
- ► August (3)

Feynman On Confusion

String Theory

Astronomers Delight!

Atacama Starry Nights: Episode I from Babak Tafreshi on Vimeo.

Hitler Does Calculus!

Feynman 1 - Relation of Mathematics & Physics

Feynman 2 - Relation of Mathematics & Physics

Man On The Moon!

Math Log

5 Ways To Program Faster

Learning to program isn't something you can do in an afternoon, but it doesn't have to be a life's work, either. There are lots of things you can do to make it easier on yourself when you are learning to program. You already know about The 5 Most Common Problems New Programmers Face--And How You Can Solve Them. Now, discover how to get the most out of your learning.

One common theme across many of these tips is:

don't go too fast; get it right before moving on.

When I was teaching C, there were always a few students who came into the class knowing a bit about programming. Inevitably, some of these students did great in the first few weeks only to fall further and further behind as the course went on. Why? They went too fast through the introductory part of the course, thinking they knew it all--but they rarely did. They knew some of the material, but not enough to have a strong grasp of the fundamentals.

At the same time, you must not stop making progress--you can go too slow as well as too fast. Don't avoid a topic after you've mastered everything leading up to it. By facing more challenging ideas, you'll help cement your grasp of the basics.

1. Look at the Example Code

Reading is usually about the words on the page, but learning to program is about code. When you're first learning to program, you should make sure to look at, and try to understand, every example. When I first learned to program, I would sometimes read the code examples before the text, and try to figure out what they did. It doesn't always work, but it did force me to look at the example very carefully, and it often helped make the writeups clearer.

If you want to see what sample code looks like, you can read this site's introductory programming tutorial. This tutorial spends a great deal of time talking about the sample code to help you work through exactly what the code does.

2. Don't Just Read Example Code--Run It

But when you're reading a programming tutorial (or book), it's easy to look at the sample code and say "I get it, I get it, that makes sense". Of course, you might get it, but you might not get it, and you just don't know it. There's only one way to find out--do something with that code.

If you haven't already, get a compiler like Code::Blocks set up.

Then type the sample code into a compiler--if you type it, instead of copying and pasting it, you will really force yourself to go through everything that is there. Typing the code will force you to pay attention to the details of the syntax of the language--things like those funny semicolons that seem to go after every line.

Then compile it and run it. Make sure it does what you think it does.

Then change it. Software is the most easily changed machinery on the planet. You can experiment easily, try new things, see what happens; the changes will happen almost immediately, and there is no risk of death or mayhem. The easiest way to learn new language features is to take some code that works one way, and change it.

3. Write your Own Code as Soon as Possible

Once you understand something about the language--or even if you're still getting your head around it--start writing sample programs that use it. Sometimes it's hard to find good ideas for what programs to write. That's OK, you don't have to come up with every idea at the beginning.

You can find some programming challenges on this site.

You can also reimplement the examples from the book or tutorial you are reading. Try to do so without looking back at the sample code; it won't be as easy as it seems. This technique can work especially well if you tweak the sample code.

If you can't think of a small program to write, but you have in mind a larger program you want to implement, like a game, you could start building small pieces that you can later use for a game. Whether you use them later or not, you will get the same useful experience.

4. Learn to Use a Debugger

I already talked about the importance of debugging in The 5 Most Common Problems New Programmers Face--And How You Can Solve Them. But it bears repeating; the sooner you learn good debugging techniques, easier it will be to learn to program.

The first step in doing so is to learn how to use a tool called a debugger, which allows you to step through your code.

A debugger will allow you to step line by line through a piece of code. It will let you see the values of variables, and whether the code inside an if statement is executed.

A debugger can help you quickly answer questions about what your code is doing.

int main() {         int x;         int y;         if( x > 4 )  // <-- what is the value of x here?         {                 y = 5;   // <-- did this line of code execute?         } }

A final word about debuggers: the first time you learn about a debugger, it will take you longer to fix the problems with your code. After the tenth or so bug, it will really start to pay off. And believe me, you will have way more than ten bugs in your programming career.

I often saw students unwilling to use a debugger. These students really made life hard on themselves, taking ages to find very simple bugs. The sooner you learn to use a debugger, the sooner it will pay off.

5. Seek out More Sources

If you don't understand something, there's a good possibility the way it was explained just didn't click.

First, look for alternative explanations. The internet is filled with information about programming, and some explanations work better for different people; you might need pictures, someone else might not. There are also lots of good books with detailed explanations.

But if that doesn't work, the easiest way to figure out where your misunderstanding lies is to ask someone else. But try to go beyond saying, "I don't understand. Please explain." You're likely to get a link back to the same text you didn't understand. Instead, rephrase your understanding of the text in your words. The more your question reveals about what you are thinking, the easier it will be for a knowledgeable expert to answer it. Programmers sometimes have a reputation for being grumpy about answering questions, but I think the reason is that they want to make progress in a conversation, and that requires both sides to put in effort. If you ask a smart, detailed question that shows you are thinking, you will generally get good results.

Earth Flyby From ISS

Earth | Time Lapse View from Space, Fly Over | NASA, ISS from Michael König on Vimeo.

5 Common Problems For New Programmers

When you're just starting out with programming, it's easy to run into problems that make you wonder how anyone has ever managed to write a computer program. But the fact is, just about everyone else who's learned to code has had that experience and wondered the same thing, when they were starting out. I've helped teach several introductory programming classes, and there are some problems that trip up nearly every student--everything from getting started to dealing with program design.

I'll prepare you to get past these challenges--none of them are insurmountable.

Getting set up

Learning to program is hard enough, but it's easy to get tripped up before you even begin. First you need to chose a programming language (I recommend C++), then You need a compiler and a programming tutorial that covers the language you chose and that works with the compiler that you set up. This is all very complicated, and all before you even start to get to the fun parts.

If you're still struggling with getting the initial setup, then check out our page on setting up a compiler and development environment (Code::Blocks and MINGW) which walks you through setting up a compiler with a lot of screenshots, and gets you up to the point of having an actual running program.

Thinking Like a Programmer

Have you seen the State Farm commercials where the car wash company returns the cars to customers with the soap suds still on the car? The company washes the car, but it didn't rinse it. This is a perfect metaphor for computer programs. Computers, like that car wash company, are very very literal. They do exactly, and only, what you tell them to do; they do not understand implicit intentions. The level of detail required can be daunting at first because it requires thinking through every single step of the process, making sure that no steps are missing.

This can make programming seem to be a tough slog at first, but don't despair. Not everything must be specified--only what is not something the computer can already do. The header files and libraries that come with your compiler (for example, the iostream header file that allows you to interact with the user) provide a lot of pre-existing functionality. You can use websites like http://www.cppreference.com or our own function reference to find information on these pre-existing libraries of functionality. By using these, you can focus on precisely specifying only what is unique about your program. And even once you do that, you will begin to see patterns that can be turned into functions that wrap up a bunch of steps into a single function that you can call from everywhere. Suddenly complex problems will begin to look simple. It's the difference between:

Walk forward ten feet Move your hand to the wall Move your hand to the right until you hit an obstacle ... Press upward on indentation

and

Walk to door Find light switch Turn on light

The magic thing about programming is that you can box up a complex behavior into a simple subroutine (often, into a function) that you can reuse. Sometimes it's hard to get the subroutine done up just right at first, but once you've got it, you no longer need to worry about it.

You can go here to read more about how to think about programming, written for beginners.

Compiler Error Messages

This may seem like a small thing, but because most beginners aren't familiar with the strictness of the format of the program (the syntax), beginners tend to run into lots of complaints generated by the compiler. Compiler errors are notoriously cryptic and verbose, and by no means were written with newbies in mind.

That said, there are a few basic principles you can use to navigate the thicket of messages. First, often times a single error causes the compiler to get so confused that it generates dozens of messages--always start with the first error message. Second, the line number is a lie. Well, maybe not a lie, but you can't trust it completely. The compiler complains when it first realizes there is a problem, not at the point where the problem actually occurred. However, the line number does indicate the last possible line where the error could have occurred--the real error may be earlier, but it will never be later.

Finally, have hope! You'll eventually get really really good at figuring out what the compiler actually means. There will be a few error messages that today seem completely cryptic, even once you know what the real problem was, that in a few months time you will know like an old (if confused) friend. I've actually written more about this in the past; if you want more detailed help, check out my article on deciphering compiler and linker errors.

Debugging

Debugging is a critical skill, but most people aren't born with a mastery of it. Debugging is hard for a few reasons; first, it's frustrating. You just wrote a bunch of code, and it doesn't work even though you're pretty sure it should. Damn! Second, it can be tedious; debugging often requires a lot of effort to narrow in on the problem, and until you have some practice, it can be hard to efficiently narrow it down. One type of problem, segmentation faults, are a particularly good example of this--many programmers try to narrow in on the problem by adding in print statements to show how far the program gets before crashing, even though the debugger can tell them exactly where the problem occurred. Which actually leads to the last problem--debuggers are yet another confused, difficult to set up tool, just like the compiler. If all you want is your program to work, the last thing you want to do is go set up ANOTHER tool just to find out why.

To learn more about debugging techniques, check out this article on debugging strategies.

Designing a Program

When you're just starting to program, design is a real challenge. Knowing how to think about programming is one piece, but the other piece is knowing how to put programs together in a way that makes it easy to modify them later. Ideas like "commenting your code", "encapsulation and data hiding" and "inheritance" don't really mean anything when you haven't felt the pain of not having them. The problem is that program design is all about making things easier for your future self--sort of like eating your vegetables. Bad designs make your program inflexible to future changes, or impossible to understand after you've written. Frequently, bad design exposes too many details of how something is implemented, so that every part of the program has to know all the details of each other section of the program.

One great example is writing a checkers game. You need some way to represent the board--so you pick one. A fixed-sized global array: int checkers_board[8][8]. Your accesses to the board all go directly through the array: checkers_board[x][y] = ....; Is there anything wrong with this approach? You betcha. Notice that I wrote your accesses to the board all go directly through the array. The board is the conceptual entity--the thing you care about. The array happens to be, at this particular moment, how you implement the board. Again, two things: the thing you represent, and the way you represent it. By making all accesses to the board use the array directly, you entangle the two concepts. What happens when you decide to change the way you represent the board? You have an awful lot of code to change. But what's the solution?

If you create a function that performs the types of basic operations you perform on the checkers board (perhaps a get_piece_on_square() method and a set_piece_to_square() method), every access to the board can go through this interface. If you change the implementation, the interface is the same. And that's what people mean when they talk about "encapsulation" and "data hiding". Many aspects of program design, such as inheritance, are there to allow you to hide the details of an implementation (the array) of a particular interface or concept (the board).

Solving Common Programming Errors

What's wrong with my program - Common Programming Errors

This article is an attempt to explain the basic programming errors that beginners often make. It is an ongoing project that attempts to cover all the basic errors I get when people email me. If you're just starting out programming, looking through it might be a good way to solidify your programming knowledge.

Undeclared Variables

int main() {   cin>>x;   cout<                 "Huh? Why do I get an error?"
               
                Your compiler doesn't know what x means. You need to declare it                  as a variable.                  int main() {   int x;   cin>>x;   cout< Uninitialized variables
                 int count; while(count<100) {   cout<                 "Why doesn't my program enter the while loop?"
               
                In C++ variables are not initialized to zero. In the above snippet                  of code, count could be any value in the range of int. It might,                  for example, be 586, and in that situation the while loop's condition                  would never be true. Perhaps the output of the program would be                  to print the numbers from -1000 to 99. In that case, once again,                  the variable was assigned a memory location with garbage data                  that happened to evaluate to -1000.
               
                Remember to initialize your variables.
               
              Setting a variable to an uninitialized value
                 int a, b; int sum=a+b; cout<<"Enter two numbers to add: "; cin>>a; cin>>b; cout<<"The sum is: "<                 "What's wrong with my program?"
               
                Often beginning programmers believe that variables work like equations                  - if you assign a variable to equal the result of an operation                  on several other variables that whenever those variables change                  (a and b in this example), the value of the variable will change.                  In C++ assignment does not work this way: it's a one shot deal.                  Once you assign a value to a variable, it's that value until you                  reassign the values. In the example program, because a and b are                  not initialized, sum will equal an unknown random number, no matter                  what the user inputs.
               
                To fix this error, move the addition step after the input line.                  int a, b; int sum; cout<<"Enter two numbers to add: "; cin>>b; cin>>a; sum=a+b; cout<<"The sum is: "<               Using a single equal sign to check equality
                 char x='Y'; while(x='Y') {   //...   cout<<"Continue? (Y/N)";   cin>>x; } 
                 "Why doesn't my loop ever end?"
               
                If you use a single equal sign to check equality, your program                  will instead assign the value on the right side of the expression                  to the variable on the left hand side, and the result of this                  statement is TRUE. Therefore, the loop will never end. Use ==                  to check for equality; furthermore, to avoid accidental assignment,                  put variables on the left hand side of the expression and you'll                  get a compiler error if you accidentally use a single equal sign                  as you can't assign a value to something that isn't a variable.                  char x='Y'; while('Y'==x) {   //...   cout<<"Continue? (Y/N)";   cin>>x; } 
               Undeclared Functions
                 int main() {   menu(); } void menu() {   //... } 
                 "Why do I get an error about menu being unknown?"
               
                The compiler doesn't know what menu() stands for until you've                  told it, and if you wait until after using it to tell it that                  there's a function named menu, it will get confused. Always remember                  to put either a prototype for the function or the entire definition                  of the function above the first time you use the function.                  void menu(); int main() {   menu(); } void menu() {   ... } 
               Extra Semicolons
                 int x; for(x=0; x<100; x++);   cout<                 "Why does it output 100?"
               
                You put in an extra semicolon. Remember, semicolons don't go after                  if statements, loops, or function definitions. If you put one                  in any of those places, your program will function improperly.                  int x; for(x=0; x<100; x++)   cout<               Overstepping array boundaries
                 int array[10]; //... for(int x=1; x<=10; x++)   cout<                 "Why doesn't it output the correct values?"
               
                Arrays begin indexing at 0; they end indexing at length-1. For                  example, if you have a ten element array, the first element is                  at position zero and the last element is at position 9.                  int array[10]; //... for(int x=0; x<10; x++)   cout<               Misusing the && and || operators
                 int value; do {   //...   value=10; }while(!(value==10) || !(value==20)) 
                 "Huh? Even though value is 10 the program loops. Why?"                 
               
                Consider the only time the while loop condition could be false:                  both value==10 and value==20 would have to be true so that the                  negation of each would be false in order to make the || operation                  return false. In fact, the statement given above is a tautology;                  it is always true that value is not equal to 10 or not equal to                  20 as it can't be both values at once. Yet, if the intention is                  for the program only to loop if value has neither the value of                  ten nor the value of 20, it is necessary to use && : !(value==10)                  && !(value==20), which reads much more nicely: "if value is not                  equal to 10 and value is not equal to 20", which means if value                  is some number other than ten or twenty (and therein is the mistake                  the programmer makes - he reads that it is when it is "this" or                  "that", when he forgets that the "other than" applies to the entire                  statement "ten or twenty" and not to the two terms - "ten", "twenty"                  - individually). A quick bit of boolean algebra will help you                  immensely: !(A || B) is the equivalent of !A && !B (Try it and                  see). The sentence "value is other than [ten or twenty]" (brackets                  added to show grouping) is translatable to !(value==10 || value==20),                  and when you distribute the !, it becomes !(value==10) && !(value==20).                 
               
                The proper way to rewrite the program:                  int value; do {   //...   value=10; }while(!(value==10) && !(value==20))

Pulsar

Genetic Algorithms

Solving Cool Problems with Genetic Algorithms

Genetic algorithms are useful for solving problems having solutions representable as strings (hence the name Genetic Algorithm - the programming model is based on DNA). In terms of practical value, genetic algorithms are useful for solving problems in which the solutions are difficult to find by following a specific algorithm designed to solve the problem (using genetic algorithms in place of predesigned algorithms such as Djikstra's algorithm for path finding just wouldn't make sense). It functions as a sort of systematized brute force approach. Problems genetic algorithms are valuable for solving include scheduling problems, constraint satisfaction problems, and other problems that require searching a large number of possibilities. Genetic algorithms can be applied to protein folding or even tuning Linux kernel performance.

A simpler example just to get the point across is finding a five digit number that acts as the best solution to an expression; for example, if you wish to find the number that makes the expression x^2+2x-11 equal to 0, you could of course use brute force to solve the equation, but a genetic algorithm can also be used, and if you have a very complex expression, it may be of great value to use a genetic algorithm, especially when one considers the time saved over brute force. In a sense, all genetic algorithm problems boil down to solving complex expressions or sets of expressions, as all problems are representable in that fashion.

Genetic algorithms work from the same basis as evolutionary theory. A genetic algorithm has several components: a pool of solutions, a method of evaluating the effectiveness of each solution, a breeding function that combines the best solutions into new solutions, and a mutation function. The pool of solutions do not compete for resources; rather, each solution is tested by an evaluation function (called the "fitness" function), which then gives it a ranking based on its effectiveness at solving the problem compared to the other solutions.

The best solution strings are the ones that are ranked highest (that are the most "fit"); the breeding function takes two of the better performing solutions and combines them together into a new solution. The breeding function should repeat the process of randomly selecting two solutions and breeding them; the better performing functions should be given the higher percentage chance of being selected.

The breeding function generally works by taking slices of each solution and splicing them together into a new one. Solutions are often represented as strings, so generally, a breeding function will take fragments of random lengths from each string and concatenate them together to form a new string. Each fragment should be placed into the location in the new string that corresponds to its location in the old string. For example, if a string fragment is from positions 5 to 8 in the first string being bred, it should be placed into positions 5 through 8 in the new child solution.

After the strings have been bred, and the set of potential solutions has been refilled, it is important to have the mutation function. The mutation function is important because it introduces an element of randomness that allows variation in the solution sets, which otherwise would stagnate and have no advantage over a hand-crafted solution. Mutations may diminish the strength of some solutions, but in general it will increase the overall value of the solution set; by including a very small mutation rate, you introduce new traits that might never have otherwise existed within the pool. This allows you to explore a larger group of possibilities and avoid stagnation. In fact, many other AI techniques forgo the idea of breeding solutions and work simply by making small "mutations" or changes to a potential solution to a problem.

Genetic algorithms can do some amazing things and solve very complex problems. Nevertheless, this techniques will require having way of evaluating possible solutions -- this is one of the most difficult problems with genetic algorithms. The second challenge is finding a good way to represent solutions to the problem as strings. Once these are sorted out, a genetic algorithm may be a good approach to your problem.

NASA Astrophysics

You Can Learn Anything!

The Secret to Learning Anything

Some of the most important lessons I learned in college came from one professor, Michael Mitzenmacher. Now, this was a guy with a lot of papers to his name, tenured at Harvard, working on some pretty darn complicated computer science theory (I took his algorithms class). So you'd expect that I'd learn something important. But as it turned out, the biggest lessons I learned from him weren't on the topics he taught. I learned a secret that helped me learn much more effectively.

At one point when describing the problem sets in the class, he gave some advice that stuck with me:

Don't suffer from Math Major syndrome

So, what you ask, is Math Major syndrome? Well, think of it this way--if you are studying a hard problem, what's your first tendency? To get lost in thought? To start at it, mulling over ideas in your head, waiting for a flash of insight? If so, that's math major syndrome. It's the idea that you can (or have to) solve problems entirely through a brilliant flash of insight, without doing any actual work.

The alternative is quite simple:

Hard problems become easier by working through them with diagrams, effort and patience

In other words, don't just wait for answers to come to you--go out and find them. Don't just use what's in your head--use paper, or the computer, or a whiteboard, to draw out the ideas, try experiments, make the patterns visible rather than waiting for a flash of insight.

I remember really learning this lesson during the first problem set--I'd started it when it was handed out, but the night before it was due I still had one problem left. I spent hours on that problem, but I spent it drawing out equations, working through possibilities. Each one ended in failure, until I had a flash of insight in the middle of writing out an equation. If I hadn't worked through (and discarded) all those possibilities, I'd have had no hope of solving that problem.

So how do you apply this principle in practice?

Program Program Program

If you're learning to program, you should be programming. Work practice problems while you read tutorials--in fact, you're probably better off in most cases working practice problems than you are reading about programming. (You will need to read, but without practice, that reading means nothing.)

In fact, if you're just learning to program, then I suggest that you stop reading this article right now and go write some code (or get yourself set up with a compiler and then go write some code). But not something you know how to solve--try to write a program that is just a little bit scary or hard. You should feel just a bit scared that you won't be able to do it.

Draw it Out

A second corollary to the principle is that you're better off using paper than trying to imagine everything. In fact, I can't say enough about the importance of drawing diagrams. A lot of things in programming sound very abstract or difficult to describe in words, but they can be quickly shown with a picture. Computer memory, for example, can be thought of as a long block of cells (almost like in an Excel spreadsheet). Drawing out each piece of memory in your program (when dealing with pointers or data structures) can really help visualize what is going on. You can also write out recursion manually by showing each recursive call with its arguments and return value.

But even simpler concepts become clear when you draw them or work through them step by step--having trouble understanding a complex piece of code? Write out the different variables and how they are modified. For example, the boolean expression

! a || b

(in other words, NOT a OR b)

has a very specific meaning in English: "if a is true, then b must be true"; this could be useful for checking user inputs ("if the user pressed exit, then the game must be over--otherwise, print out an error"). But it's not at all obvious what ! a || b means unless you actually work through it. What do I mean?

The statement "if a is true, then b must be true" requires that:

if a = true, b must be true if a = false, b can be either true or false

How does that work for the expression "! a || b? You can draw out the table by writing a in one column, b in a second, and whether the condition is satisfied result in a third:

a	b	! a \|\| b
0	0	1
0	1	1
1	1	1
1	0	0

Now you can more quickly see that the table expresses the English condition. The condition is satisfied in all the cases except when a is true and b is false (clearly, that can't satisfy an expression that says, "if as is true, then b is true"!)

Being able to look at the data really helps!

Think Like A Programmer

A Beginner's Guide to Thinking Like a Programmer

A lot of people email me asking the way to start some program or another. Perhaps the best advice is simply to start writing down a layout for the program: once you start writing down ideas or code you'll start to get a feel for your project. There are two standard methods of program design: the top-down approach and the bottom-up approach. Top-down programming involves writing code that calls functions you haven't defined and working through the general algorithm before writing the functions that do the processing. Top-down programming is, to a good degree, a very abstract way of writing code because it starts out by using functions you haven't designed, and that you perhaps do not know how to design. The bottom-up approach to programming is the opposite: the programmer writes the basic functions she realizes will be necessary at some point in the programming and then work up to the more complex parts of the program.

It's interesting that both of these approaches focus on the actions of the program rather than the objects the program manipulates - variables. Many times, the best way to write a program is to figure out the variables you need to work with and then progress with a top-down approach to the program that manipulates those variables. By defining variables first and then working with functions that work on them, you will always maintain a basic foundation of what your program should be doing. Once you have an idea of what variables you will be using, then you can write functions to perform the operations you need to perform on the variables while maintaining sight of the goal. Finally you can write the code for each individual function.

Another value to defining variables before writing code is that many times you can accomplish an entire program without many functions; this fact is especially true when you are a beginner making simple programs. The variables give you the raw materials you need to begin working with the tools: loops, if statements, library functions, and perhaps user defined functions.

Let's take a look at an example of how to go about thinking about a program. If you were to write a program to simulate a video store rental system that calculates the gross revenue from rentals, you might be asked to write a program that accepts a code telling you whether a certain video was rented at $2.00 (input as 2) a day or $3.00 (input as 3) a day and then asks for how many days it was rented out for; finally, if the code for the cost of rental is 0 the program should terminate. You should also count the number of days videos were rented at $3.00 per day and $2.00 per day. The best way to think about the design for a program such as this one is to imagine what information you need to store in order to calculate the revenue:

you need a variable to store the total dollar amount at the end of the program;
you need a temporary variable to store the code for the cost of a transaction;
you need a temporary variable to store the number of days a specific video was rented;
you need a variable to store the number of days each video was rented;
you need a variable to count the total number of days $3.00 videos were rented;
finally, you need a variable to count the total number of days $2.00 videos were rented.

Once you realize you need these variables, you can easily imagine how to translate them in terms of each other: for example, you know the total amount of revenue is the number of days videos at $2.00 were rented times $2.00; in similar fashion, you know the relationship for $3.00 a day videos. You should understand that the transaction 'code' determines which variables are manipulated when the user inputs the number of days a specific video was rented (for example, whether to add to the count of days for $2.00 videos or $3.00 videos). You'll probably need a loop in your program (although you can't necessarily infer this from the variables).

The code might look as follows:

int main() {   int total_dollars = 0;   int total_days_at_3_dollars = 0;   int total_days_at_2_dollars = 0;   int transaction_code = 0;   int days_for_one_video = 0;   do   {     if(transaction_code==2)       total_days_at_2_dollars+=days_for_one_video;     if(transaction_code==3)       total_days_at_3_dollars+=days_for_one_video;     cout<<"Please enter a transaction code and number of days a video was rented: ";     cin>>transaction_code>>days_for_one_video;   }while(transaction_code!=0) }

Hopefully, you now have a basic idea of how to lay out your program structure in your mind before you begin to write code.

I Want To Be A Mathematician

Mr.MathMan

Building Math Champs!

Stay On The Path, And Don't Get Lost!

How to Avoid Getting Lost When Writing Programs, or, The Power of Incremental Development

In daily life, we're all constantly making small corrections. Even walking in a straight line is a difficult task when there is no feedback on whether you are, in fact, going straight. If you're making sauce, you'll constantly be checking the consistency of the mixture to make sure it's not too watery. You may find that even when writing, you go back and revise your sentences or restructure paragraphs before you've finished your piece.

In short, in daily life, almost everything we do involves constant feedback on whether we're doing it right. Why would programming be any different? Very few of us, especially when just starting out, will create a program that Just Works. Instead, we'll get a ton of compiler errors, and once we've worked through them, the program will probably not work correctly. If you've written hundreds of lines of code, then you might have dozens or even hundreds of compiler errors to sort through and once you've managed to get through them, you'll still be faced with a frustrating debugging chore because you won't know where in that 200 lines of code your error resides.

Start Small

The key to avoiding this frustration is to start small--unless I have an extremely good idea of what needs to be done, the first thing I do when starting any program is to get a simple program that I can run. This program probably doesn't do much; it might just display the welcome screen. But it does something, and it means that I've got no compiler errors to deal with in that part of the code. Better still, I know it works because I can see it and test it.

What makes a good initial framework? I like to have some basic output and possibly some input. If I'm working on a network application, my first goal is just to send one packet over the network from one computer to the other. Doing these things helps to test your basic assumptions about how things work. If you can't get the basic input to work, then it's unlikely you'll even be able to test the rest of your program.

Build In Increments

Once I've got a simple program running, I try to add small pieces of code that are self-contained enough to be easily tested. This gives me the confidence that my new addition will actually work correctly. Another advantage is that if I have only small additions to my code, then I will limit the number of annoying error messages I have to deal with at one time. I hate dealing with fifty error messages just as much as anyone else, but I'd rather deal with fifty errors in chunks of three or four than all at once!

In many cases, it will be obvious which part of your program you should write next (perhaps because everything else will depend on that piece of code). In some cases, you might have the luxury of choosing between two or more possible next steps. In these cases, I generally like to solve the easiest problem first because I don't want it sitting around bothering me while I try to think about the harder problem. I want to devote all of my mental energy to the hard problem, whereas I can afford to worry a bit about the hard problem while I solve the easier one.

If you're not sure what to write next, don't be afraid to write simpler code than you expect will actually be necessary. It's fine to write some basic functionality without filling in all the details if it's sufficient to let you test an assumption about a part of the code that's more important. Of course, it's not always clear what's most important, but generally it would be whatever is at the core of the program. In a game, it might be the game engine; in an AI program, it might be the learning algorithm. In a network application, it might be the ability to create a network connection. Prioritize the core of the program over features that might never be used!

Finally, once I've added a chunk of code, I test it to make sure that it works as expected. If it doesn't, then at least I know that the mistake has to be in the code that I just added. (There are, of course, times when this isn't the case, but for the most part, it's true.) This means that when I'm debugging, I can ignore most of my old, working code, and focus on looking at what happens when the new code is executing.

Backtracking

One of the great things about building incrementally is that you get feedback on whether you're actually solving the problem. After every small change, you're able to test your implicit assumptions about what should be happening. Sometimes, you might find out that what you expected to happen is very different from what really happened. For instance, you might have incorrect assumptions about how fast your program will be. If it takes an hour to start up, then that's an indication of something wrong! Better to catch it when you first start out than once you've written an entire program based on that assumption.

Better still, even if you don't need to actually back track, you will have a firmer grasp of what you're doing. Once you can actually play with the framework of your program, it's much easier to get a picture for what the rest of it should be doing.

Staying Focused

A major reason for building incrementally is that it lets you focus on a single part of your program at a time. You don't need to worry about whether every line of code will work because you'll have experience with most of it actually working. This lets you focus all of your energy on the new problem you are solving rather than worrying about hundreds of lines of untested code.

Along similar lines, when you're working on a program, it helps to stay focused and work on a single discrete part of the program at a time. If you go back and forth between multiple parts of the code, you'll have to keep more stuff in your head at once (or load and unload information every time you switch what you're working on). You'll also run into the problem of having to come to a stopping place in multiple parts of your code at once before you can test it. If your addition in one place would break some other code, then you have to finish that addition before testing your semi-functional program again.

Pulsar

Hours of Operation

Topics

Fly The Friendly Skies!

String Theory

EMPOWER

The Meeting

Flying Delight!

Clear for take-off!

Math Empowerment

Steve Jobs- Adios Amigo!

An Extraordinary Entrepreneur

USNA

Return To Fligt After Columbia STS-107

As part of NASA’s Return to Flight effort following the loss of the space shuttle Columbia and its crew during mission STS-107 on Feb. 1, 2003, NASA’s Johnson Space Center approached NASA's Dryden Flight Research Center for help in modeling thermal protection system foam loss from the shuttle’s external fuel tank.

The Columbia Accident Investigation Board, convened following that vehicle’s breakup during re-entry, found that the primary cause of the tragedy was a breach in the shuttle’s thermal protection system resulting from a piece of insulating foam that separated from the external tank’s left bipod ramp area.

Panels on the F-15B's flight test fixture show five divots of TPS foam were successfully ejected during the LIFT experiment.

A close-up of the panels on the F-15B's flight test fixture shows five divots of TPS foam were successfully ejected during the LIFT experiment flight #2, the first flight with TPS foam that was used as insulation on the space shuttles' external tanks. (NASA / Tony Landis) The detached piece of foam struck the shuttle’s left wing near its leading edge, in the vicinity of the lower half of Reinforced Carbon Panel number eight. The foam strike occurred about 81 seconds after launch, punching an estimated 10-inch diameter hole in the panel. This damage went undiscovered throughout the mission.

During the shuttle’s fiery re-entry, the hole allowed the super-heated air surrounding the vehicle, called plasma, to penetrate through the gap in the thermal protection panel. The plasma melted the orbiter’s aluminum wing structure to the point of sufficient structural failure to cause an aerodynamic loss of control as it descended thhrough the upper reaches of the atmosphere, resulting in the breakup of Columbia. Heartbreak rolled across the nation and the world as a second space shuttle crew was lost.

Following the accident, Dryden geared up to provide flight data on foam loss requested by NASA engineers at the Johnson Space Center. Called the Lifting Insulating Foam Trajectory (LIFT) project, this effort utilized the center's F-15B Research Testbed aircraft to acquire data on how insulating foam debris or "divots" behaved when the small pieces were shed from the shuttle's external fuel tank during launch.

The unique capabilities of NASA’s supersonic F-15B Research test bed aircraft enabled it to garner the LIFT data in a real flight environment at altitudes up to 50,000 ft. and at speeds up to Mach 2. The project continued NASA Dryden’s shuttle program support of testing shuttle insulating materials begun with F-104 and F-15 test bed aircraft early in the program.

Though the fatal piece of foam that broke off the bipod ramp area of STS-107’s external tank was significantly larger, small-scale foam loss called divoting, or “popcorning,” had occurred throughout the entire space shuttle program. Immediately after the loss of Columbia, all foam-shedding issues took front-and-center attention in the shuttle program’s return to flight effort.

Panels on the F-15B's flight test fixture have five divots of TPS foam that were successfully ejected during the LIFT experiment .

A post-flight inspection of the panels on the F-15B's flight test fixture shows five divots of TPS foam were successfully ejected during the LIFT experiment flight #2, the first flight with TPS foam used for insulation on the space shuttles' external tanks. (NASA / Tony Landis) Divoting, as with most forms of shuttle foam loss, occurred when the foam’s adhesive failed. This happened as a result of decreasing atmospheric pressure combined with increased heating during Shuttle ascents, causing air trapped in or beneath the insulating foam to expand.

The LIFT flight tests on NASA’s F-15B required two new capabilities: an in-flight foam divot ejection system and a high-speed video system to track and record the paths of the divots in flight. Both capabilities were developed rapidly by Dryden engineers in just over two months.

Dryden's LIFT team designed, built and ground-tested four different divot ejection systems, completing 70 ground tests to determine and refine the best approach to use.

In addition, NASA Dryden engineers designed a digital video synchronization system used in the tests that linked the high-speed cameras with the divot ejection system. They also developed video analysis techniques to help track the foam.

Two primary questions were to be answered by the LIFT tests: understanding whether the divots broke up once they came off the external tank, and secondly, whether they trimmed and began to fly, or if they tumbled instead. The difference between trimming (flying) or tumbling made a huge difference in the amount of kinetic energy that a foam divot could impart to the shuttle, as tumbling pieces exerted more energy than trimmed divots, posing a greater risk of damage.

Following the rapid LIFT system design phase, ground test and flight test hardware construction and validation, Dryden successfully flight-tested the LIFT system on the F-15B, providing the much-needed divot trajectory test data.

Analysis of the high-speed video data showed that of the 36 successful supersonic foam divot ejections, all of the divots trimmed. This data helped engineers at Johnson validate the models that they used for debris transport analysis.

NASA' s Space Shuttle Systems Engineering and Integration office at the Johnson Space Center in Houston, Texas, funded the LIFT flight tests.