Wednesday, September 16, 2009

what to drop and what to keep: You got to know when to hold 'em, know when to fold 'em.







JUGGLING or TRADEOFFS of Engineering.

Sometimes we all spend 90% of their effort on a part of the program that only earns <5% of rewards/marks.
If you find that one aspect of the requirements takes too much time and sabotages your entire program (close to zero marks), then it may be worthwhile considering a simpler version that works and gets you more realistic marks. This is a tradeoff situation and only YOU can decide the level at which you are comfortable.




You will need to juggle the need for thoroughly meeting ALL specifications
with the need to keep your code simple enough to confidently reproduce it in the
lab test.
 



In programming a number of possible paths exist towards a solution.
Your challenge consists of meeting the requirements within a given time limit, within your ability to remember, understand and confidently reproduce, test and debug your code. 



With unlimited time and resources your program would look very different from the one you will submit for the lab test.
 Making such choices is difficult, but part of the educational process,
not only at this University but also in the University of life in which we are all enrolled... .
 



These tradeoff choices litter the highway (or jungle) of life.... at every stage.
Having said all that here is simple HINT - you don't have to take it - it is simply a SUGGESTION:  
Keep you code simple.


Is the error check for commas in input such as: 4,123.5
really worth it ? It is if you can do it elegantly and simply,
It is not if it takes up 90% of your code.



Learning is a social activity.

Programming is a kind of "social sport" it is a team sport.
Talk to other students, work with friends, ask around, use the internet to gain the skills you need.
Yes, testing WILL be on an individual basis, to make sure you actually HAVE learned the required skills.

It is a neccessary part of our University courses. Why ? Because when we don't test your INDIVIDUAL skills then we get the "Passenger effect" and that is not a good thing.

More on the "Passenger effect" in a future email, I think it's not too hard to figure out.

And even though we ostensibly teach: How to control Hardware with Software i.e. Engineering Software and programming, (using C++), we are really also teaching:

  • - how to juggle different demands
  • - tradeoffs (i.e. should I bother with the error check for commas in input such as: 4,123.5 ?? can I live with the loss in marks ? )
  • - getting ALL of 'it' working, not just a bits of 'it'.


Of course for those who  are keen to do more research on this question outside narrow Engineering: see/google: Ivan Illich and the 'hidden curriculum' :-) for a really eye opening ideas.




The same idea as I've expounded at length above has been put much more succinctly by Kenny Rogers as:
You got to know when to hold 'em, know when to fold 'em.
Know when to walk away, know when to run
You never count your money, when you're sittin' at the table.
There'll be time enough for countin', when the dealin's done.
 Students often ask me about the Comma in input strings question, so below is a simple, no guarantees piece of code:
#include
#include
#include
#include
#include
#include // leave this one in please, it is required !
#define TEMPSIZE 80 // assume input in always less than this number, professional code SHOULD really do error check to make sure this is the case...
using namespace std;
int main(int argc, char *argv[])
{
   if (argc == 2) {
        cout << "\n before removing commas: argv[1] is: " << argv[1];
        char temp[TEMPSIZE]; // assume input in always less than this number, professional code SHOULD really do error check to make sure this is the case...
        int inputstrlen = strlen(argv[1]);
        int tempIndex=0;
        for (int i=0;i < inputstrlen; i++) {
            if (argv[1][i]==',') { // found the comma, don't copy it to temp, ie. do nothing.
                // do nothing here, make it clear by using comments such as this.
                cout << "\nfound comma\n";  // handy debug comment, leave it IN for use later on.
                cout << "\n i " << i << "   tempIndes " << tempIndex;
            }
            else { // copy the input string to temp
                cout << "\n In else: i " << i << "   tempIndes " << tempIndex;
                temp[tempIndex]=argv[1][i];
                tempIndex++;
            }
        }
        temp[tempIndex]='\0'; // huh?? what's this for ? what happens if you don't do it ? (Answer: Bad things happen)
        cout << "\n AFTER removing commas: argv[1] has been moved to string temp and is: \n" << temp <<"\n\n\n\n";
        system("pause");
        return(0) ;
    }
    else {
        cout << " This program requires ONE and ONLY ONE command line parameter\n\n";
        system("pause");
        return(0) ;
}
return 0;
}