how to count rows and columns of integers/doubles in a file?

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen wrote: -snip-


It may "work", but it's certainly a childish effort, at best. Let me
guess, you're a first year student? Your code sucks. Unclear,
unmaintainable, unportable. Amateur.

No, I'm not a first a first year student.

Very cute. I'm impressed. I think all of us are.

I see you have a very big problem with me telling you that this wasn't a
homework assignment. You don't have to be impressed by that. That is
nothing.

We all know why it doesn't compile. It's because you don't know what
you're talking about. Your code sucks. Most regulars here can write
the complete program you've been struggling with for 3 days in about 10
minutes.

Wauw... Am I supposed to be impressed now?

I have other things to do, than to program.

**** off. You are quite possibly the most worthless programmer (and
human being) I've ever seen. You'll get no further responses.

I have better things to do than waste my time dealing with morons like
you.


Mark F. Haigh
(e-mail address removed)

.... "with morons like you"... Look who's talking now...

What exactly is your problem?

"the most worthless programmer (and human being) I've ever seen".

"**** off".


Best regards / Med venlig hilsen
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

... snip ...



Now don't get all snippy with your panties in a knot, or you will
find your help rapidly disappears. We all have better things to do
than laboriously research a thread. Articles should stand by
themselves, and if something is unclear just explain it. Articles
should also be short.

I already explained it several times, pretty clear IMO, but if people
don't want to read what is very clear then it not my fault. Do I really
have to remind you, that Pedro already solved this problem without
whining like a pig like Mark who has a problem which I never understood
and probably never will understand.

I just answered his questions and assured him that this wasn't a
homework exercise - what else should I do? I really don't see his
problem and those stupid accusations is just too much.


Best regards / Med venlig hilsen
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Hi Martin,

I think you need to take a step back and consider making it about
1/3rd of the size and 100 times more readable. I really believe you
have overcomplicated this : as a result of you learning C as you go I suspect.

Some hints:

1) create a struct for representing rows & column count - then have an
array of these. all this n_x and n_y is not nice on the eye. And be
concistent in your naming conventions. "y" is not a proper
alternative for "number of columns".
2) Consider reading in the data a line at the time using fscanf/fgets or
something. Reading in by character is often inefficient.
3) What is "count" and why are you passing a reference to it when the
function always increments it? Sloppy. Return a success/fail code.
4) never call a function "getdata" and especially never make such a
function a void IMO : return a success code or a count or a pointer
to a result of interest.
5) stop exiting from the lower level funtions. If you *must* have a
function called "testwronginput" return a success code and
certainly do not pass in pointers to column & row data : it doesnt
need to know about them - it should only be interested in the
character it is checking. You have complicated this function and
made it heavy on the eye. Keep it simple.
6) I'm always suspicous of anything which counts anything in a "next"
line. It should be counting things in "current" line. Whenever I
see two calls to something like "countColsInNextLine" next to each
other I have to wonder if there is a better, clearer way to handle
it. Often turning the loop upside down works.
7) comment your functions : good clear C is self explanatory
manytimes, unfortunately functions like "testwronginput" are far
from clear - it seems an almost arbitrary attack on various forms
of white space etc. Hence a spec would be appreciated.

Finally : use google. I googled "reading lines in from file in c" ...

http://www.mrx.net/c/program.html

fgets might be helpful. fcanf even more so for a strict input
format. How "strict" is your input detail? Maybe its ok to assume the
format is rigid?

It is still far from clear what format the data file is in. Explain
this clearly in words - not as a c comment.

good luck!

-snip-

Hi Richard. Thanks for the professional and constructive contribution.
Those suggestions look pretty good to me. This thread has been
"polluted" a bit too much for me, I think.

The good thing is that I think I have the programming part under
control, more or less...


Best regards / Med venlig hilsen
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

... snip ...



As an example, lets just deal with the above extract, and see a
reasonable way to format it that will work everywhere.

void getdata(char *filename, /* room to describe */
unsigned *pCols, /* the various parameters */
unsigned *pRows, /* if desired */
int *count)
{
FILE *pFile;

unsigned rows, cols, oldcols;

printf("Opening file: %s.\n", filename);
if ( (pFile = fopen(filename, "r") ) == NULL) {
printf("Cannot open file %s.\n", filename);

/* give the user at chance to see this error */
/* before the windows shuts down */
system("PAUSE");
exit(1);
}

And, instead of the very questionable use of system("PAUSE") etc.,
I would use:

printf("Cannot open file %s.\n"
"Hit <enter> to continue",
filename);
fflush(stdout);

/* give the user at chance to see this error */
/* before the windows shuts down */
getchar();
exit(EXIT_FAILURE);
}

Note the use of string concatenation to avoid long lines, and
simultaneously provide an image of the output screen in the source
code. Now that portion is also portable. You can also easily
change to using fprintf(stderr, "..., which is a preferable place
for error messages.

I get the idea, but don't be surprised about that I'm going to tell you
that I couldn't possible know that you felt that way about reading some
code I copy/pasted since I haven't subscribed to this group for long and
only have about 1,5 months of C programming experience.

I guess I have subscribed to this group for about 1,5 months and being
called "a moron", being told to "**** off" and being told that "You are
quite possibly the most worthless programmer (and human being) I've ever
seen" is just too childish.


Best regards / Med venlig hilsen
Martin Jørgensen

 

[Mark McIntyre]

void getdata(char *filename, /* room to describe */
unsigned *pCols, /* the various parameters */
unsigned *pRows, /* if desired */
int *count)

personally I consider this an abomination. The first form is way more
readable.

Please don't put comments to the right of your variable declarations,
if you have some comment to make, do it above the code where it can be
sensibly read and isn't going to end up bizarrely indented when
variable names get altered. .
Mark McIntyre

 

[Ben Pfaff]

personally I consider this an abomination. The first form is way more
readable.

I work for a company that has the latter as required style.
(If you violate it you get scorched in code reviews.)

 

[Michael Mair]

6) I'm always suspicous of anything which counts anything in a "next"
line. It should be counting things in "current" line. Whenever I
see two calls to something like "countColsInNextLine" next to each
other I have to wonder if there is a better, clearer way to handle
it. Often turning the loop upside down works.

The (potential) misnomer is my fault -- as long as it is not
clear that there is a line, I like to think of the potential
input line as "next line if any".
If we had some sort of readLine(&line, ....) and a check whether
a line has been read, then a subsequent call to a line counting
function could of course call countColsInCurrentLine(line, ....)
or countColsInLine().

The original code is from me (<[email protected]>):
,---
rows = 0;
if (countColsInNextLine(pFile, &oldcols) != EOF) {
rows++;
while (countColsInNextLine(pFile, &cols) != EOF) {
rows++;
if (cols != oldcols) {
isConsistent = 0;
/* Your error message here */
}
}
}
`---
The two calls "next to each other" maybe could be done
in a nicer way -- the alternative to differentiate between
"oldcols unset because we have not yet read in the first
line" and "oldcols set" within the loop IMO is a poor one.
I went with the obvious course: "If there is no line, ...;
if there is at least one line, set oldcols; if there are
further lines, compare oldcols with the new line's number
of columns".
How would you express that differently in C without putting
tests that do not structurally belong there inside the
loop?

Cheers
Michael

 

[CBFalconer]

.... snip ...

I guess I have subscribed to this group for about 1,5 months and
being called "a moron", being told to "**** off" and being told
that "You are quite possibly the most worthless programmer (and
human being) I've ever seen" is just too childish.

You didn't get that from me, and usenet is full of ignorant boors.
Ignore them, or at least their boorish behaviour.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Vladimir S. Oka]

CBFalconer opined:

You only got that from one person (I can vouch for two out of three),
on one occasion, and they have already been criticised for it (by
me ;-) ).

You didn't get that from me, and usenet is full of ignorant boors.
Ignore them, or at least their boorish behaviour.

Good advice. Heed it.

 

[Jordan Abel]

I work for a company that has the latter as required style.
(If you violate it you get scorched in code reviews.)

Required always, or required for non-self-explanatory argument lists
and/or argument lists over a certain length?

In other words, are we talking about

void f(void /* room to describe void */
)

or is there some wiggle room here?

 

[CBFalconer]

I work for a company that has the latter as required style.
(If you violate it you get scorched in code reviews.)

As usual, it depends. If there are many parameters, the second
style is almost mandatory. If very few, and the parameter names
are descriptive, the first is preferable. A mongrel is useful to
group associated parameters, such as array pointer and array size.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Barry Schwarz]

Okay, forget about this wrapping thing. Guess you're right. I just can't
restrict Visual studio from making lines longer than 65 characters or

It's not a Visual Studio thing. It's a matter of personal discipline.

so. I went through all the options and help. The following should be
better in that I don't think it inserts ekstra linebreaks in places
never intended to have linebreaks. So what's important is what's inside
main() and I hope that copy/pasting should work - I manually fixed some
comments etc.

I compiled your code. I received only two types of errors:

count is unsigned but you pass its address to getdata which is
expecting an int*. Change the prototype and definition.

You define T and T_new twice within the same block, once at
the top of the function and once when you are ready to call malloc.
The latter should be replaced with a simple assignment statement.

After these changes your code compiled fine. Now you get to test.

snip

void getdata(char *filename, unsigned *pCols, unsigned *pRows, int *count); snip
int main(void)
{ snip
unsigned count, n_x[max_input_files], n_y[max_input_files];
/* and a lot more var's, not necessary in this example */
double **T, **T_new; snip

double **T = malloc((n_y[0]+1)*sizeof(double*)); /* n_y = rows */
double **T_new = malloc((n_y[0]+1)*sizeof(double*)); /* n_y = rows */ snip
}

delete


Remove del for email

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

On Sun, 19 Mar 2006 03:22:39 +0100, Martin Jørgensen

I compiled your code. I received only two types of errors:

count is unsigned but you pass its address to getdata which is
expecting an int*. Change the prototype and definition.

Yes, stupid mistake - I think I would have found that myself, if I could
just figure out how to make the program compile at that time.

You define T and T_new twice within the same block, once at
the top of the function and once when you are ready to call malloc.
The latter should be replaced with a simple assignment statement.

Yes, I can see that now... I never thought about it before but now it's
ofcourse very clear. This was actually the biggest problem - figuring
out that I should just remove the definition in the line where malloc
was called...

After these changes your code compiled fine. Now you get to test.

Yes, Pedro already mailed it to me and wrote what caused the problems to
this group... So I just needed a small push in the right direction and
that was all. Thanks for helping... Looks like I have everything under
control finally...



Best regards / Med venlig hilsen
Martin Jørgensen

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Martin Jørgensen wrote:

... snip ...



You didn't get that from me, and usenet is full of ignorant boors.
Ignore them, or at least their boorish behaviour.

Yeah, you're right. But you know how it is...... I've been on usenet for
a couple of years and have been using it practically every day. It still
pisses you off when you try to behave nice to somebody and that person
repays your gratitude with loads of bullshit, like I've seldom seen.


Best regards / Med venlig hilsen
Martin Jørgensen

 

[Ben Pfaff]

Required always, or required for non-self-explanatory argument lists
and/or argument lists over a certain length?

It's always required. Some old code doesn't follow the coding
standard, but new code must.

The argument comments are stylized: each one must start with IN,
OUT, or IN/OUT according to its usage.

In other words, are we talking about

void f(void /* room to describe void */
)

There'd be no comment on (void) because that's not an argument;
it's a marker that indicates the absence of arguments.

 

[Keith Thompson]

I guess I have subscribed to this group for about 1,5 months and being
called "a moron", being told to "**** off" and being told that "You
are quite possibly the most worthless programmer (and human being)
I've ever seen" is just too childish.

Yes, it is. Most of us try not to be such jerks, though.

 

[Keith Thompson]

No, I'm not a first a first year student.


I see you have a very big problem with me telling you that this wasn't
a homework assignment. You don't have to be impressed by that. That is
nothing.

Not to defend Mark's rudeness, but it might be nice if you told us
just why you're trying to write this program. Is it part of a larger
project? Is it just a personal exercise? A number of people have
spent considerable time helping you with this; knowing what the goal
is might be helpful. (Sorry if you've already explained this; I
haven't followed the thread very closely.)

 

[Jordan Abel]

It's always required. Some old code doesn't follow the coding
standard, but new code must.

The argument comments are stylized: each one must start with IN,
OUT, or IN/OUT according to its usage.

What exactly is an "OUT" argument? a pointer? what would you call a FILE
* argument that is supposed to be read to / written from?

 

[Ben Pfaff]

What exactly is an "OUT" argument? a pointer?

A pointer that is written to.
A pointer that is only read from would be an IN argument (and
would generally be marked `const'.)

what would you call a FILE * argument that is supposed to be
read to / written from?

It's debatable. Generally this sort of thing would be clarified
elsewhere. Comments are (generally) meant for consumption by
humans, not computers, so you don't need rules for them that can
be evaluated by computers.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

Keith Thompson wrote:
-snip-

Not to defend Mark's rudeness, but it might be nice if you told us
just why you're trying to write this program. Is it part of a larger
project? Is it just a personal exercise? A number of people have
spent considerable time helping you with this; knowing what the goal
is might be helpful. (Sorry if you've already explained this; I
haven't followed the thread very closely.)

I think this is off-topic, at least I consider the on-topic discussion
finished.

However, since you absolutely must ask: I'm trying to learn and figure
out how to do basic things in C since I'll graduate as an engineer this
summer (I'm on eigth semester, not a first first year student as "Mark
the child" suggested). Since I'm writing my bachelor project now, I have
plenty of time to learn, to do and make my own exercises or do whatever
I want to learn, (including doing nothing). Usually Matlab is the
preferred choice here but I think C is important to learn, especially
for doing loops. You don't have a problem with me trying to learn C, now
do you?

Because if not, then everything is fine even though this is off-topic.


Best regards / Med venlig hilsen
Martin Jørgensen