Programming

awk.

Code:

awk FS="[ ,]" 'NR>1 {for(N=3; N<=NF; N++) $2+=$N;  $2 /= (NF-1); NF=2 } 1' inputfile

With explanation:

Code:

awk FS="[ ,]" # Separate columns on spaces and commas \
        'NR > 1 { # Do not try to do math on the first line with column names
                 for(N=3; N<=NF; N++) # Loop over column 3 to the last column, adding them to column 2 in turn
                         $2 += $N ;
                 $2 /= (NF-1); # Divide the column by 1-number of columns
                 NF=2; # Strip off all columns beyond the second
                 } 1 # Print all lines' inputfile

Never a fan of strtok() or *scanf myself, debugging too many core dumps, I guess, especially in C++ (stateful subroutines in OO, ooooh!). I would fgets() lines into a char array and then process them as follows. If the byte is not a number part (strchr( " ,\t\n\r\f", this_char ), strchr( "1234567890-.", this_char) -- I like the positive test), set it to null and reset the in-number flag, else if it is, then if the in-number flag is not set, record the address in a char*[], increment the index on that array and set the in-number flag. When you are done, you have an array of pointers to null terminated character strings of numbers to atof() in the processing layer, with the index telling you the count of numbers found.

I would not read 4k into a 1k buf. fgets( buf, sizeof( buf ), stdin ) ?

Every fgets needs a "line too long" check to be stable. WHne this occurs, the last buffer byte is null and then preceeding one is not a line feed. Seed the buffer tail, rather than pawing over the line an additional time, for a quick check. Put it all in a nice subroutine p_fgets() (private fgets) with if ! fgets() if ferror() perror( "stdin" ); exit 1; else exit 0;

It definitely has its flaws. Doing further editing on the string after it's tokenized is a bad idea. It's not re-entrant. And other such gripes.

But seeing your description of how you'd do it, particularly the 'set it to null', that's exactly what strtok does, to the letter. I don't see what makes your way better -- bigger program, slower program, bigger chance for bugs.

Same goes for sscanf. It makes some really complicated problems simple, and vice versa.

If the problem wasn't this simple though, I certainly wouldn't have used those.

When I strtok, I put it in a for! Less magic, I guess! The positive test is more robust, as the world is just line feeds, numbers and not numbers.

I guess it might go awry with "- 1". Does *scanf() have more states to handle that? Can atof() deal with spaces after the sign? If you have them, check! The man says no: Man Page for strtod (all Section 3) - The UNIX and Linux Forums).

Sorry to repeat. But it sounds like you DO create the data file. Is that correct?

If so, what if you simply change the data file to something like the following, and then the programming to read the data would be trivial, using fscanf.

Code:

varA   cnt     varB 
-21      1     0  
-21.2    4     3 4 5 6 
-21.4    5     45 65 87 98 98 
-22.0    5     345677 349887 98766 877654 987543 
-23.0    3     76549 8764 9873

CSV might be nice, too -- just read with excel. However, differentiating numbers from not is pretty trivial. The major challenge here is the variable number of fields. A more normal form would have one varB per line, and downstream, assuming you do not lose the sort, you process when the two keys change or EOF. Normal could be put in RDBMS and processed in SQL. You are writing in two dimensions, sometimes across and sometimes down. But that's OK.

Thx for this code