Showing posts with label Simple. Show all posts
Showing posts with label Simple. Show all posts

Wednesday, July 25, 2012

Industry-Standard Programming For Beginners: Lesson 4 (A Simple Program III)

Having to change the program whenever a different time is to be entered is tedious, and there is a much better way to organise things - by making timetaken a variable, and by supplying a value for it as data. In this way, the program can remain the same, and won't need to be recompiled each time. The data is completely distinct from the program, and depending on the compiler you are using, may be entered either via the keyboard or a data file. Whichever you choose, the data can be input into the program using the read statement. This principal is illustrated in the example program below, in which two values are read in as data:

Program SimpleInterest ( input, output );

{********************************************************************

Example Program 2

Calculation of simple interest on a principal at a given of interest

and over a given number of days.

*******************************************************************}

const

rate = 10; { percent }

year = 365; { days }

var

principal, interest, amount: real;

time: integer;

begin

read ( principal, time );

interest:= time / year * rate / 100 * principal

amount:= principal + interest

writeln ( 'Example Program 2: Computation of simple interest' );

writeln ( '=================================================' );

writeln;

writeln ( 'principal = $', principal:7:2 );

writeln ( 'interest rate = ', rate:4, ' %' );

writeln ( 'term = ', time:4, ' days' );

writeln;

writeln ( 'interest = $', interest:7:2 );

writeln ( 'new value of principal = $', amount:7:2 );

end.

Before we look at the purpose of the program, try comparing its general format with that of Example Program 1. Again, there is an initial comment; but this time, in addition, there are further comments interspersed with the code. Comments may appear anywhere, except in a quoted piece of text, or in the middle of a multi-character symbol (multi-character symbols include names, numbers and the assignment operated ':='). Apart from the comments, the general structure is the same as that of Example Program 1. There is a program heading, followed by a series of declarations, i.e. lists of constant variable names to be used. (Comparing a computer program with a recipe, the declarations can be likened to a list of ingredients preceding the instructions.) Then comes a set of statements to be executed, enclosed between the words begin and end - the statement part. All Pascal programs have these three parts: heading, declarations, and statement part, and all are terminated by '.'. The section of the program consisting of the declarations and statement part is known as the program body, or block.

Certain words occur in both Example Program 1 and 2. These include program, var, begin and end, which always have a special meaning in Pascal. These are known as reserved words. In this program, they have been highlighted by bold lettering, and if you are lucky, your compiler will format your code in the same way for you, automatically.

The title and names used to identify quantities within a program are invented by the programmer. Any suitable names may be chosen, with the exception of reserved words. Formally, a name (or 'identifier') in a program may consist of any sequence of letters or digits, as long as it begins with a letter.

The purpose of Example Program 2 is to calculate the interest paid on a sum of money over a given number of days, with a given rate of interest.

Now that we're aware of how the two programs are similar, and we have a better understanding of how a program should be constructed, we will move on to how Example Program 2 is so different (and so much more powerful) than Example Program 1, in the next lesson.

-Jonathan

This is a guest article, brought to you by http://www.gorard.co.uk/.


View the original article here

Tuesday, July 24, 2012

When It Comes to Modern Weapon Systems, Keep It Simple Stupid, and Never Forget That Rule

KISS - Keep It Simple Stupid has always been considered a phrase of wisdom, and anyone who's ever tried to do anything complicated in their lives knows this to inherently be true. The other rule of thumb would be Murphy's Law, which also seems to be quite valid, more so than not. Okay so let's talk about this when it comes to choosing the best modern weapons systems or our military.

There was an interesting paper I recently read by Doug Bodner of Enterprise Systems Engineering at the Tennenbaum Institute titled; "Addressing Risk in the Acquisition and Lifecycle with Enterprise Simulation" which was of particular interest. In one part of the text Bodner postulates the need for computational model simulation to help aid in the decision making process, while focusing on the main or primary objectives such as; "aging portfolios, fiscal constraints, complexity of new systems, and potential and emerging threats."

Now then, using an artificial intelligent decision making program - a decision tree with logic gates to come to the final outcome could help in the complexity of the decision making process, however, perhaps one might surmise that we've placed far too many false parameters already along the process pathways unnecessarily. Perhaps, we've put too much emphasis on nonsensical things, which have little to do with the primary objective to acquiring a weapons system in the first place; namely to do its job and help you win battles, thus, hopefully if you win enough battles, you will win the war.

Okay, let me give you a for instance of an irrelevant stipulation passed onto the acquisition and contracting process if I might. When it comes to government contracting, they have all sorts of rules and regulation which really do not belong in military contracting. I'm talking about such things as the percentage of all contracts that must be awarded to small businesses, and other such nonsensical regulations which are put up onto the process. This just clouds the issue and complicates the process. By having these stipulations, we are making it more difficult to come to the right decision on which weapons our military should buy.

Further, it probably doesn't matter if you put more stipulations on a computer, no matter how artificially intelligent it is, or how well you programmed it, if we are putting up false parameters to choosing the best contractor or weapons system - then all we have is garbage in, and garbage out. Until we fix the underlining problems in this process, and this is just one of many that I used as an example here today, it won't matter how great the decision-making software is, it will be filled with bogus and false parameters.

Therefore the answer it spits out is guaranteed to not be the best for all concerned, namely our men and women in uniform that will be using this equipment when their lives depends on it. Indeed I hope you will please consider all this and think on it.

Lance Winslow has launched a new provocative series of eBooks on Future Military Technologies. Lance Winslow is a retired Founder of a Nationwide Franchise Chain, and now runs the Online Think Tank; http://www.worldthinktank.net/


View the original article here