bad karma time...

1. your question title is non-descriptive
2. we are not here to do your homework
3. do some work, show us what you've done and ask us for help with what you are stuck on

--

cLive ;-)

When trying to solve a problem that is totally intimidating, I try breaking it down into smaller parts. This has the benefits of A) making the problems smaller (yay!), and B) increasing the likelihood that I can solve one of the problems. Try it!

(One of the small problems in your request for help is 'how do I compute an average?' Can you manage that one at least? What are the other problems?)

Once you've solved one or several small problems, you A) gain confidence that helps fuel further progress, and B) end up with a better intuitive sense of the shape and size of problems you haven't yet solved, and C) you've given your brain time to mull over some of the other parts, something that often comes in quite handy.

"divide and conquer!"

Sometimes though, the problem with splitting a problem into many smaller parts is that A) you've created a lot more problems, and B) this is not a good feeling if you can't seem to solve any of them.

Thankfully there is a way out.

Then I try starting with the very first task I have to achieve in order to make any further progress. (In your case, this would be reading in the .dat file and sticking it into some variable(s).) This helps A) make the problem more manageable, since the task you have to solve is much smaller than the problem as a whole, B) greatly simplifies the process of chosing what to work on, and C) provides a foundation for future work to build on top of. Try it!

Once you've solved the very first sliver of the problem, you can test that you've gotten that right, and when you have, hey, you've accomplished something! Progress! Now just tackle the next small piece. This is called the "iterate and test" approach to software development.

"A journey of a thousand miles begins with a single step!"

That's a good way indeed...
Rather that's a good point to start with,
but take care, this will only give you a way to go on further.
It won't assure you to reach what you want...

Breaking a problem into the right smaller parts isn't so obvious,
there are often several ways and few good ones...
Often the difficulty is more to make the good choices
than just breaking into several simpler tasks.

Let's take a dumb example (I'll let smart people find smart example ;-) :

You have to write a small program to make two host communicate (in batch) via several means; what will you do ?

• Write a client and a server ?
• Write a single client/server prog ?
Depending of the constaint the first one may not be so stupid
(even if the second one is more likely...)

Then as the prog has to be configurable,
writing the prameters handling part you wonder : how will it take its parameter ?

• Via the command line ?
• Via a conf file ?
And those of you who just think
'If the amount of argunents is important just use a file
otherwise the command line is the best'
could just miss several possible aspect (security, file constraint...)

Now that you have your data, you'll write the com routines;
of course you know what protocol to use :

• TCP ?
• UDP ?

...

Of course this example is dumb, the (few) questions are over-simplified
but the idea is although apparent :
Breaking into smaller parts is usually easy
but making the right choices doing so isn't so obvious
Decomposing a client/server prog into several parts is easy but depending on how you do it,
it will be more or less easy to maintain, easy to upgrade, easy to understand...

The choice of your structure, data, algorithm (among a lot of other things) is important too, in my humble opinion.

"Only Bad Coders Badly Code In Perl" (OBC2IP)

The first program you should write is:

## open data file
## slurp in lines from data file
## foreach your way through the data 
      ## print lines back to verify it was slurped.
[download]

## open data file
## slurp in lines from data file
## foreach your way through the data 
      ## parse the line into two scalars
      ## print the two scalars to verify parsing.
[download]

## open data file
## slurp in lines from data file
## foreach your way through the data 
      ## parse the line into two scalars
      ## stuff the two scalars into two arrays

## print the two arrays to verify stuffing.
[download]

## open data file
## slurp in lines from data file
## foreach your way through the data 
      ## parse the line into two scalars
      ## stuff the two scalars into two arrays

## sum all grades
## print the sum
## count the number of grades
## print the number of grades
## calculate the averate
## print the average
[download]

Later you can go back into the final program and remove unnecessary 'inbetween' variables and do general clean up.

For the moment your questions may resolve around simple things like: "How in the heck do I 'slurp' (a.k.a. read in) a file?" or such things as: "How do I step through a file line by line?"

Good luck.

Claude
p.s. Individual tastes will vary when it comes to selecting which baby steps to take in sneaking up on a program. In general you can bet that trying to do it all at once will introduce too many problems and bugs to deal with.