Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #98718 > unrolled thread

Program to create csv file and write into it

Back to article view | Back to comp.lang.c

Contents

  Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-10 09:30 -0800
    Re: Program to create csv file and write into it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 20:42 +0000
      Re: Program to create csv file and write into it Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-10 15:56 -0500
        Re: Program to create csv file and write into it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 21:08 +0000
      Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-10 23:48 -0800
        Re: Program to create csv file and write into it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 00:01 -0800
        Re: Program to create csv file and write into it Keith Thompson <kst-u@mib.org> - 2016-12-11 01:12 -0800
        Re: Program to create csv file and write into it Keith Thompson <kst-u@mib.org> - 2016-12-11 01:27 -0800
          Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-11 04:50 -0800
            Re: Program to create csv file and write into it Barry Schwarz <schwarzb@dqel.com> - 2016-12-11 09:42 -0800
              Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-12 00:13 -0800
                Re: Program to create csv file and write into it Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:34 +0000
                  Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-12 00:50 -0800
                    Re: Program to create csv file and write into it Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 09:02 +0000
                      Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-12 02:52 -0800
                        Re: Program to create csv file and write into it Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 10:59 +0000
                          Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-12 03:23 -0800
            Re: Program to create csv file and write into it mx2927 <mx2927@gmail.com> - 2016-12-11 20:44 +0100
              Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-11 23:57 -0800
                Re: Program to create csv file and write into it Barry Schwarz <schwarzb@dqel.com> - 2016-12-12 01:06 -0800
        Re: Program to create csv file and write into it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 11:39 +0000
          Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-11 04:47 -0800
            Re: Program to create csv file and write into it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:43 +0000
              Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-12 00:56 -0800
        Re: Program to create csv file and write into it Barry Schwarz <schwarzb@dqel.com> - 2016-12-11 09:38 -0800
          Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-12 00:44 -0800
            Re: Program to create csv file and write into it Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:48 +0000
            Re: Program to create csv file and write into it Barry Schwarz <schwarzb@dqel.com> - 2016-12-12 01:19 -0800
              Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-12 02:30 -0800
              Re: Program to create csv file and write into it Manfred <noname@invalid.add> - 2016-12-12 15:10 +0100
                Re: Program to create csv file and write into it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 12:35 -0800
    Re: Program to create csv file and write into it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-10 14:29 -0800
      Re: Program to create csv file and write into it Alla _ <modelling.data@gmail.com> - 2016-12-10 23:57 -0800
        Re: Program to create csv file and write into it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 00:33 -0800
          Re: Program to create csv file and write into it Keith Thompson <kst-u@mib.org> - 2016-12-11 01:19 -0800

Page 2 of 2 — ← Prev page 1 [2]

#98781

Alla _ <modelling.data@gmail.com> writes:
<snip>
> Oh, great ))) I am still far off with my assumptions. 
>
> (1) Yes, I have not repeated my goal here; I should have.
> I am planning to:
> # take a few excel spreadsheets, which contain financial statements;
> convert them into csv format

OK.  This part is not in C right?

> # read data from those csv files using C language

OK.

> # process that data (a few functions) to compute pro forma financial
> statements, and, if I find that to be not big enough,

OK, stop!  For my sake, take a simple goal and run with it.  Can you
show me one of these pro forma financial statements?  You know what you
mean, but it would help keep things concrete if I knew what the output
might be like.

<snip>
> Therefore, the program I have posted here is supposed to be one of the 
> functions, which will later on take already computed pro forma data and
> write it into a csv file.

Here I get lost.  I don't see any connection between what you posted and
the goals above.  You posted a program that reads data interactively and
writes that date to a binary file in some rather odd format.  I realise
that that is probably just a mistake, but I can't know from the code
what you really planned to to.

> There will be no stdin input, like the one I have 
> in this program (I took the main program's frame from D&D, as discussed
> elsewhere), but the initial data will also come from csv file, as also being
> discussed in another thread.

So the posted program was a trial of some sort?  I see.  Do you want to
get it working before moving on?  If so, you need to describe the intent
of that trial program and we can forget (for the moment) the goals you've
set yourself above.

> (2) no, I don't see any nulls, but I see huge unexpected white spaces in 
> the part I copied from a file with csv extension (as I see not csv yet); 
> I assume these white spaces  = nulls. 
> Please, help me to understand (I know I have been told the same thing in 
> my previous post, but I didn't understand it): do these nulls come
> from ...

The nulls come from that fact that you use fseek.  When you skip to a
fixed position in an output file, any data not explicitly written gets
set to 0.  If you write 'a', then fseek(fp, 3) and write 'b' before
closing the file you will get 'a' '\0' '\0' 'b' in the file (i.e. four
bytes, two of them nulls).

If you want to write this sort of file (and at the moment I don't see
why you do) you need a way to see exactly what is in a file.  Keith gave
you some pointers.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#98787

On Sunday, December 11, 2016 at 2:39:51 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
> > Oh, great ))) I am still far off with my assumptions. 
> >
> > (1) Yes, I have not repeated my goal here; I should have.
> > I am planning to:
> > # take a few excel spreadsheets, which contain financial statements;
> > convert them into csv format
> 
> OK.  This part is not in C right?
> 
> > # read data from those csv files using C language
> 
> OK.
> 
> > # process that data (a few functions) to compute pro forma financial
> > statements, and, if I find that to be not big enough,
> 
> OK, stop!  For my sake, take a simple goal and run with it.  Can you
> show me one of these pro forma financial statements?  You know what you
> mean, but it would help keep things concrete if I knew what the output
> might be like.

Of course. First in words (a simplified version):

1. based on the income statement forecast sales growth
   1.1. find the average growth rate of the previous 5 years (also simplifying)
       1.1.1. take income statements for the last 5 years; find Sales row
       1.1.2. compute sales growth rate for each year = 
       ( amount of sales this year - amount  of sales previous year ) / amount of sales previous year
       1.1.3. find the average of all results in 1.1.2
       This average will be used to compute the amount of sales during the next 5 years
    1.2. find industry's projected sales growth rate:
           - prompt the user for the input (lots of ifs can be, but I will stick with simplest 
          approach of expecting to get this from the "user" (if everything goes ok, I will 
          add "search the web for that rate" function, but most likely I will not do that - 
          might be too complicated for my current level of programming)
    1.3. compute sales numbers for the next 5 years using historical average from 1.1.3 =
     previous sales amount x rate
    1.4. compute sales numbers for 5 years beyond based on the industry average found in 1.2.
    Totally 10 forecasted years. 
2. Construct pro forma income statements:
   2.1. get data from common size income statements for the last 5 years (these are 
   statements where Sales = 100% and all other items represent percentage of sales;
   for example, Interest expense = Interest expense / Sales)
         2.1.1 compute (or maybe receive from the user's file) historic averages for the last 
         5 years;
I will skip a few items here not to make list too long (there are a few other things, which 
require additional computation based on some additional information but the overall 
idear is the same).
     ....
    2.n compute each row's column values based on computed Sales amounts and 
     all rates for each row.

Here is how common size statement looks like in csv format:

Income Statement,2011,2012,Avg
Sales,1.00,1.00,1.000
Cost of Goods Sold,0.62,0.65,0.635
  Gross Profit,0.38,0.35,0.365
SG&A,0.24,0.22,0.230
  Operating Income before Depr,0.14,0.13,0.135
Depreciation and Amortization,0.02,0.02,0.020
  Operating Profit,0.12,0.11,0.115
Interest Expense,0.00,0.00,0.000
Other Gains and Losses,0.00,0.01,0.005
  Pretax Income,0.12,0.10,0.110
Income Tax Expense,0.05,0.04,0.043
  Net Income,0.07,0.06,0.067

Here is part of the final pro forma statement (actually
these are just numbers, so formulas are not seen of
course):
INCOME STATEMENT,2016,2017,2018
Sales,"1,062","1,252","1,587"
Cost of Goods Sold,654,814,"1,009"
  Gross Profit,408,438,578
"Selling, General, and Admin Exp",254,271,364
  Operating Income before Depr,154,167,214
Depreciation and Amortization,25,31,38
  Operating Profit,129,136,176
Interest Expense,4,3,3
Other Gains and Losses,0,7,10
  Pretax Income,125,126,163
Income Tax Expense,55,52,65
  Net Income,70,74,98

I am not sure if I managed to explain what I would like to achieve. I will be 
happy to give more details if required. 
> 
> <snip>
> > Therefore, the program I have posted here is supposed to be one of the 
> > functions, which will later on take already computed pro forma data and
> > write it into a csv file.
> 
> Here I get lost.  I don't see any connection between what you posted and
> the goals above.  You posted a program that reads data interactively and
> writes that date to a binary file in some rather odd format.  I realise
> that that is probably just a mistake, but I can't know from the code
> what you really planned to to.
> 
> > There will be no stdin input, like the one I have 
> > in this program (I took the main program's frame from D&D, as discussed
> > elsewhere), but the initial data will also come from csv file, as also being
> > discussed in another thread.
> 
> So the posted program was a trial of some sort?  I see.  Do you want to
> get it working before moving on?  If so, you need to describe the intent
> of that trial program and we can forget (for the moment) the goals you've
> set yourself above.
> 
Yes, of course. Not only because I will use it, but also because this is how
I will learn. I need to make sure this program works the way it is intended. 

> > (2) no, I don't see any nulls, but I see huge unexpected white spaces in 
> > the part I copied from a file with csv extension (as I see not csv yet); 
> > I assume these white spaces  = nulls. 
> > Please, help me to understand (I know I have been told the same thing in 
> > my previous post, but I didn't understand it): do these nulls come
> > from ...
> 
> The nulls come from that fact that you use fseek.  When you skip to a
> fixed position in an output file, any data not explicitly written gets
> set to 0.  If you write 'a', then fseek(fp, 3) and write 'b' before
> closing the file you will get 'a' '\0' '\0' 'b' in the file (i.e. four
> bytes, two of them nulls).
> 
> If you want to write this sort of file (and at the moment I don't see
> why you do) you need a way to see exactly what is in a file.  Keith gave
> you some pointers.
> 
> -- 
> Ben.

[toc] | [prev] | [next] | [standalone]

#98801

Alla _ <modelling.data@gmail.com> writes:

> On Sunday, December 11, 2016 at 2:39:51 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>> <snip>
>> > Oh, great ))) I am still far off with my assumptions. 
>> >
>> > (1) Yes, I have not repeated my goal here; I should have.
>> > I am planning to:
>> > # take a few excel spreadsheets, which contain financial statements;
>> > convert them into csv format
>> 
>> OK.  This part is not in C right?
>> 
>> > # read data from those csv files using C language
>> 
>> OK.
>> 
>> > # process that data (a few functions) to compute pro forma financial
>> > statements, and, if I find that to be not big enough,
>> 
>> OK, stop!  For my sake, take a simple goal and run with it.  Can you
>> show me one of these pro forma financial statements?  You know what you
>> mean, but it would help keep things concrete if I knew what the output
>> might be like.
>
> Of course. First in words (a simplified version):
<snip>
> Here is how common size statement looks like in csv format:
>
> Income Statement,2011,2012,Avg
> Sales,1.00,1.00,1.000
> Cost of Goods Sold,0.62,0.65,0.635
>   Gross Profit,0.38,0.35,0.365
> SG&A,0.24,0.22,0.230
>   Operating Income before Depr,0.14,0.13,0.135
> Depreciation and Amortization,0.02,0.02,0.020
>   Operating Profit,0.12,0.11,0.115
> Interest Expense,0.00,0.00,0.000
> Other Gains and Losses,0.00,0.01,0.005
>   Pretax Income,0.12,0.10,0.110
> Income Tax Expense,0.05,0.04,0.043
>   Net Income,0.07,0.06,0.067
>
> Here is part of the final pro forma statement (actually
> these are just numbers, so formulas are not seen of
> course):
> INCOME STATEMENT,2016,2017,2018
> Sales,"1,062","1,252","1,587"
> Cost of Goods Sold,654,814,"1,009"
>   Gross Profit,408,438,578
> "Selling, General, and Admin Exp",254,271,364
>   Operating Income before Depr,154,167,214
> Depreciation and Amortization,25,31,38
>   Operating Profit,129,136,176
> Interest Expense,4,3,3
> Other Gains and Losses,0,7,10
>   Pretax Income,125,126,163
> Income Tax Expense,55,52,65
>   Net Income,70,74,98
>
> I am not sure if I managed to explain what I would like to achieve. I will be 
> happy to give more details if required.

Thanks.  There some other inputs mentioned (a user file for example) so
I'm not sure I fully understand even the data sources, but the gist of
it is simple enough.

>> <snip>
>> > Therefore, the program I have posted here is supposed to be one of the 
>> > functions, which will later on take already computed pro forma data and
>> > write it into a csv file.

I would then have expected to see a function something like this:

  int write_data_in_csv_format(FILE *fp, const Data_Item *rows, size_t n_rows)

That's the part you will be able to take forward into the bigger program.

<snip>
>> So the posted program was a trial of some sort?  I see.  Do you want to
>> get it working before moving on?  If so, you need to describe the intent
>> of that trial program and we can forget (for the moment) the goals you've
>> set yourself above.
>> 
> Yes, of course. Not only because I will use it, but also because this is how
> I will learn. I need to make sure this program works the way it is
> intended.

Well I'd start with with a write_csv_file function of some sort.  It's
not obvious exactly how much sophistication you need in the data
structure, so you could start with just a simple array of rows like I
did above.

If the task gets complex enough, you can wrap the rows and the count of
the rows (and other stuff) into a fully-fledged data frame later, but
I'd start simple.

Can you come up with a suitable Data_Item structure?  And what about the
write_data_in_csv_format function -- can you write that?  Note that I
don't mean finish it.  I mean only the first refinement of it.  In
top-down design you write the function assuming that you have on or more
very useful functions to help you.  You speculate: "if only I had a
function that did X, I could write the current function very easily".
You write assuming a function that does X and move on to writing that
function.  Eventually you end up with things like "if only I have a
function that could output a string... oh, I do: fputs".

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#99010

On Sunday, December 11, 2016 at 5:43:52 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> 
> > On Sunday, December 11, 2016 at 2:39:51 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >> <snip>
> >> > Oh, great ))) I am still far off with my assumptions. 
> >> >
> >> > (1) Yes, I have not repeated my goal here; I should have.
> >> > I am planning to:
> >> > # take a few excel spreadsheets, which contain financial statements;
> >> > convert them into csv format
> >> 
> >> OK.  This part is not in C right?
> >> 
> >> > # read data from those csv files using C language
> >> 
> >> OK.
> >> 
> >> > # process that data (a few functions) to compute pro forma financial
> >> > statements, and, if I find that to be not big enough,
> >> 
> >> OK, stop!  For my sake, take a simple goal and run with it.  Can you
> >> show me one of these pro forma financial statements?  You know what you
> >> mean, but it would help keep things concrete if I knew what the output
> >> might be like.
> >
> > Of course. First in words (a simplified version):
> <snip>
> > Here is how common size statement looks like in csv format:
> >
> > Income Statement,2011,2012,Avg
> > Sales,1.00,1.00,1.000
> > Cost of Goods Sold,0.62,0.65,0.635
> >   Gross Profit,0.38,0.35,0.365
> > SG&A,0.24,0.22,0.230
> >   Operating Income before Depr,0.14,0.13,0.135
> > Depreciation and Amortization,0.02,0.02,0.020
> >   Operating Profit,0.12,0.11,0.115
> > Interest Expense,0.00,0.00,0.000
> > Other Gains and Losses,0.00,0.01,0.005
> >   Pretax Income,0.12,0.10,0.110
> > Income Tax Expense,0.05,0.04,0.043
> >   Net Income,0.07,0.06,0.067
> >
> > Here is part of the final pro forma statement (actually
> > these are just numbers, so formulas are not seen of
> > course):
> > INCOME STATEMENT,2016,2017,2018
> > Sales,"1,062","1,252","1,587"
> > Cost of Goods Sold,654,814,"1,009"
> >   Gross Profit,408,438,578
> > "Selling, General, and Admin Exp",254,271,364
> >   Operating Income before Depr,154,167,214
> > Depreciation and Amortization,25,31,38
> >   Operating Profit,129,136,176
> > Interest Expense,4,3,3
> > Other Gains and Losses,0,7,10
> >   Pretax Income,125,126,163
> > Income Tax Expense,55,52,65
> >   Net Income,70,74,98
> >
> > I am not sure if I managed to explain what I would like to achieve. I will be 
> > happy to give more details if required.
> 
> Thanks.  There some other inputs mentioned (a user file for example) so
> I'm not sure I fully understand even the data sources, but the gist of
> it is simple enough.
Yes, the gist is very simple, that is why I have chosen it; but C implementation
is not easy for me, and this is also why I have chosen it ))) 
Nothing confusing about inputs:
(I have decided to completely omit even mentioning excel - people get so 
distracted by this, and it has caused such a mess of confusion, very unexpected
to me)
- take csv file provided by the "user" - the user should provide the path to the file;
- read data from the csv file; store it
- process data according to the described plan
- store processed data
- write processed data to csv file

> 
> >> <snip>
> >> > Therefore, the program I have posted here is supposed to be one of the 
> >> > functions, which will later on take already computed pro forma data and
> >> > write it into a csv file.
> 
> I would then have expected to see a function something like this:
> 
>   int write_data_in_csv_format(FILE *fp, const Data_Item *rows, size_t n_rows)
> 
> That's the part you will be able to take forward into the bigger program.
> 
> <snip>
> >> So the posted program was a trial of some sort?  I see.  Do you want to
> >> get it working before moving on?  If so, you need to describe the intent
> >> of that trial program and we can forget (for the moment) the goals you've
> >> set yourself above.
> >> 
> > Yes, of course. Not only because I will use it, but also because this is how
> > I will learn. I need to make sure this program works the way it is
> > intended.
> 
> Well I'd start with with a write_csv_file function of some sort.  It's
> not obvious exactly how much sophistication you need in the data
> structure, so you could start with just a simple array of rows like I
> did above.
> 
> If the task gets complex enough, you can wrap the rows and the count of
> the rows (and other stuff) into a fully-fledged data frame later, but
> I'd start simple.
> 
> Can you come up with a suitable Data_Item structure?  And what about the
> write_data_in_csv_format function -- can you write that?  Note that I
> don't mean finish it.  I mean only the first refinement of it.  In
> top-down design you write the function assuming that you have on or more
> very useful functions to help you.  You speculate: "if only I had a
> function that did X, I could write the current function very easily".
> You write assuming a function that does X and move on to writing that
> function.  Eventually you end up with things like "if only I have a
> function that could output a string... oh, I do: fputs".
> 
> <snip>
> -- 
> Ben.

[toc] | [prev] | [next] | [standalone]

#98845

On Sat, 10 Dec 2016 23:48:18 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>Oh, great ))) I am still far off with my assumptions. 
>
>(1) Yes, I have not repeated my goal here; I should have.
>I am planning to:
># take a few excel spreadsheets, which contain financial statements;
>convert them into csv format
># read data from those csv files using C language
># process that data (a few functions) to compute pro forma financial
>statements, and, if I find that to be not big enough, add one - two valuation

I have some idea of what a financial statement means to me (I receive
them from various financial institutions periodically) but I have no
idea what a pro forma statement means to you.  In the real world,
these reports would be stored on the computer in some print/display
friendly format such as html or xml or in a database which included
some kind of report writer capability.  

I hope neither of these applies to this exercise.  So my question is:
How do you plan to store the data that makes up a report?  Not how do
you plan to present the data to the user but how will you save the
data before it is presented?  The two simple methods that come to my
mind are:
   1 - A text file that is already formatted line by line with leading
blanks for centered or indented text, columns aligned, etc and ready
to be printed with a simple fgets/printf loop.
   2 - A true CSV file where the first field of each line identifies
the line type (for example, header vs detail data) and the remaining
fields contain the data appropriate for that type of line.  To print
this, you would read each line, determine its type, build a print line
appropriate for that type, and print the line.

If neither of these are close to your intent, tell us what "compute
pro forma financial statements" really means.

>models; my goal is not to repeat excel functionality, but to write a program
>in C that is capable of doing these tasks (though with numerous assumptions
> to make it suitable for the student's project) - nothing fancy or overcomplicated;
>I have chosen these financial statements only because this is a very easy topic
>and I don't need to spend time thinking how to work with the data or learn 
>some new techniques, and can concentrate only on programming issues;
>
>Therefore, the program I have posted here is supposed to be one of the 
>functions, which will later on take already computed pro forma data and
>write it into a csv file. There will be no stdin input, like the one I have 

Now I'm confused.  Does this mean that Excel has already done the
computations?  If so, why are you converting it to CSV and not letting
Excel do it as you imply in (1) above.  If not, what form are you
receiving the data in so that your program can convert it to CSV?

>in this program (I took the main program's frame from D&D, as discussed
>elsewhere), but the initial data will also come from csv file, as also being
>discussed in another thread.

The programs you posted from D&D did not deal with CSV.  One of your
later posts did create a CSV but I have not seen anything that would
allow you to accept a CSV as input.

>(2) no, I don't see any nulls, but I see huge unexpected white spaces in 
>the part I copied from a file with csv extension (as I see not csv yet); 

Where were you looking for nulls.  The program that wrote the entire
structure to your file contained thousands of nulls.  If you create a
CSV file, there will be ABSOLUTELY NO nulls in it.

>I assume these white spaces  = nulls. 
>Please, help me to understand (I know I have been told the same thing in 
>my previous post, but I didn't understand it): do these nulls come from 
>the fact that I have two arrays in the structure with a certain allocated 
>memory; thus when I get an input from stdin and write it into those arrays,
>and if this input is shorter that the allocated space, then all free bytes have 

Its worse than that.  When you were processing your input, you stored
all the data in the same structure.  If your first input contained a
10 character last name, then the structure member lastname would
contain the 15 characters "ABCDEFGHIJ\0\0\0\0\0".  If your second
input contained a 5 character last name, then lastname would end up
containing the 15 characters "SMITH\0GHIJ\0\0\0\0\0".  Depending on
how you chose to process the members after reading the structure back,
this may not cause problems.  But you need to remember that when you
write a structure using fwrite, the entire byte count is sent to the
file, not just the parts of the structure you are using at the moment.

>zero values; and these zeros are staying there and being written into the 
>final file by fprintf I call at the end? Do I understand correctly that if not

I doubt that fprintf will ever write a null.  The later program you
wrote that used fprintf created a valid CSV file and it did not
contain any nulls.


>these fixed memory spaces, then I wouldn't face this type of problem?
>If so, shall I opt for mallocing the memory (dynamic memory allocation)
>to make sure that I write into the file only the amount of required data?

You have completely missed the point.  Dynamic allocation will do
nothing to solve this issue.  It is strictly a function of how you
choose to create the file:
     If you build a CSV, there will be no extra data in the file.  
     If you write the structure, there will be unused bytes consuming
space.  But since each character array contains a properly terminated
string, that should not cause any problems.  But you will still need
to convert the int and double to printable text when you produce the
report.

>If yes, (even if no :) ), when filling in the array I still have a null terminating 
>character at the end; how's this character affects the format I need my 
>data to be in? 

Since you say you are creating at least two different products, I
cannot determine which format you are talking about.  If your input is
a CSV, the comma will terminate the name and there will be no nulls.
If your input is the structure, then each array will contain a
terminating null.  Any characters after that null are irrelevant and
not part of the string.  In fact, the next character after the
terminating null begins a new string but you don't care about that.
You will only process the first string in the array.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#99005

On Sunday, December 11, 2016 at 8:38:29 PM UTC+3, Barry Schwarz wrote:
> On Sat, 10 Dec 2016 23:48:18 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
> 
> >Oh, great ))) I am still far off with my assumptions. 
> >
> >(1) Yes, I have not repeated my goal here; I should have.
> >I am planning to:
> ># take a few excel spreadsheets, which contain financial statements;
> >convert them into csv format
> ># read data from those csv files using C language
> ># process that data (a few functions) to compute pro forma financial
> >statements, and, if I find that to be not big enough, add one - two valuation
> 
> I have some idea of what a financial statement means to me (I receive
> them from various financial institutions periodically) but I have no
> idea what a pro forma statement means to you.  In the real world,
> these reports would be stored on the computer in some print/display
> friendly format such as html or xml or in a database which included
> some kind of report writer capability.  
> 
> I hope neither of these applies to this exercise.  So my question is:
> How do you plan to store the data that makes up a report?  Not how do
> you plan to present the data to the user but how will you save the
> data before it is presented?  The two simple methods that come to my
> mind are:
>    1 - A text file that is already formatted line by line with leading
> blanks for centered or indented text, columns aligned, etc and ready
> to be printed with a simple fgets/printf loop.
>    2 - A true CSV file where the first field of each line identifies
> the line type (for example, header vs detail data) and the remaining
> fields contain the data appropriate for that type of line.  To print
> this, you would read each line, determine its type, build a print line
> appropriate for that type, and print the line.
> 
> If neither of these are close to your intent, tell us what "compute
> pro forma financial statements" really means.
> 
> >models; my goal is not to repeat excel functionality, but to write a program
> >in C that is capable of doing these tasks (though with numerous assumptions
> > to make it suitable for the student's project) - nothing fancy or overcomplicated;
> >I have chosen these financial statements only because this is a very easy topic
> >and I don't need to spend time thinking how to work with the data or learn 
> >some new techniques, and can concentrate only on programming issues;
> >
> >Therefore, the program I have posted here is supposed to be one of the 
> >functions, which will later on take already computed pro forma data and
> >write it into a csv file. There will be no stdin input, like the one I have 
> 
> Now I'm confused.  Does this mean that Excel has already done the
> computations?  If so, why are you converting it to CSV and not letting
> Excel do it as you imply in (1) above.  If not, what form are you
> receiving the data in so that your program can convert it to CSV?
> 
> >in this program (I took the main program's frame from D&D, as discussed
> >elsewhere), but the initial data will also come from csv file, as also being
> >discussed in another thread.
> 
> The programs you posted from D&D did not deal with CSV.  One of your
> later posts did create a CSV but I have not seen anything that would
> allow you to accept a CSV as input.
> 
> >(2) no, I don't see any nulls, but I see huge unexpected white spaces in 
> >the part I copied from a file with csv extension (as I see not csv yet); 
> 
> Where were you looking for nulls.  The program that wrote the entire
> structure to your file contained thousands of nulls.  If you create a
> CSV file, there will be ABSOLUTELY NO nulls in it.
> 
> >I assume these white spaces  = nulls. 
> >Please, help me to understand (I know I have been told the same thing in 
> >my previous post, but I didn't understand it): do these nulls come from 
> >the fact that I have two arrays in the structure with a certain allocated 
> >memory; thus when I get an input from stdin and write it into those arrays,
> >and if this input is shorter that the allocated space, then all free bytes have 
> 
> Its worse than that.  When you were processing your input, you stored
> all the data in the same structure.  If your first input contained a
> 10 character last name, then the structure member lastname would
> contain the 15 characters "ABCDEFGHIJ\0\0\0\0\0".  If your second
> input contained a 5 character last name, then lastname would end up
> containing the 15 characters "SMITH\0GHIJ\0\0\0\0\0".  Depending on
> how you chose to process the members after reading the structure back,
> this may not cause problems.  But you need to remember that when you
> write a structure using fwrite, the entire byte count is sent to the
> file, not just the parts of the structure you are using at the moment.
> 
> >zero values; and these zeros are staying there and being written into the 
> >final file by fprintf I call at the end? Do I understand correctly that if not
> 
> I doubt that fprintf will ever write a null.  The later program you
> wrote that used fprintf created a valid CSV file and it did not
> contain any nulls.
> 
> 
> >these fixed memory spaces, then I wouldn't face this type of problem?
> >If so, shall I opt for mallocing the memory (dynamic memory allocation)
> >to make sure that I write into the file only the amount of required data?
> 
> You have completely missed the point.  Dynamic allocation will do
> nothing to solve this issue.  It is strictly a function of how you
> choose to create the file:
>      If you build a CSV, there will be no extra data in the file.  
>      If you write the structure, there will be unused bytes consuming
> space.  But since each character array contains a properly terminated
> string, that should not cause any problems.  But you will still need
> to convert the int and double to printable text when you produce the
> report.
> 
> >If yes, (even if no :) ), when filling in the array I still have a null terminating 
> >character at the end; how's this character affects the format I need my 
> >data to be in? 
> 
> Since you say you are creating at least two different products, I
> cannot determine which format you are talking about.  If your input is
> a CSV, the comma will terminate the name and there will be no nulls.
> If your input is the structure, then each array will contain a
> terminating null.  Any characters after that null are irrelevant and
> not part of the string.  In fact, the next character after the
> terminating null begins a new string but you don't care about that.
> You will only process the first string in the array.
> 
This last paragraph is confusing again, although the ones before it
are very helpful. I have addressed your questions on formats, I hope
it is clear now. 
My goal is to get data from csv file, process it, write to another csv file.
Structure is what I thought is the appropriate format to store the data 
the program reads from the csv file, and then extract that data for 
processing, store the results in structure, and write to csv file. 
Now I understand that the choice of the structure to read the data
from csv file is not the best one, because I do not need to separate
data into different variables' types; csv will give data line by line.
But then to process that data, I think I will need the structure to 
separate character arrays from numerical arrays. When the processing
is done, I will need to convert each structure back to a character 
array and write those into csv file.  
> -- 
> Remove del for email

[toc] | [prev] | [next] | [standalone]

#99007

On 12/12/16 08:44, Alla _ wrote:
<snip>
> My goal is to get data from csv file, process it, write to another csv file.
> Structure is what I thought is the appropriate format to store the data
> the program reads from the csv file, and then extract that data for
> processing, store the results in structure, and write to csv file.
> Now I understand that the choice of the structure to read the data
> from csv file is not the best one, because I do not need to separate
> data into different variables' types; csv will give data line by line.

This sounds very confused.

Have you written down your specification unambiguously? I think that's 
where we should start.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#99018

On Mon, 12 Dec 2016 00:44:45 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

<snip>

>This last paragraph is confusing again, although the ones before it
>are very helpful. I have addressed your questions on formats, I hope
>it is clear now. 
>My goal is to get data from csv file, process it, write to another csv file.
>Structure is what I thought is the appropriate format to store the data 
>the program reads from the csv file, and then extract that data for 

There is nothing wrong with storing the data you read from the CSV
file in a structure.  Just be aware that having a structure with
members of type int, char[15], char[10], and double is no different
than having four variables stand-alone variables of type int,
char[15], char[10], and double.  If you use the structure, every
reference in your code a member will have to include the name of the
structure object.  So will you find it more meaningful to refer to the
last name as clientData.lastname or as lastname?

>processing, store the results in structure, and write to csv file. 

As long as you don't use fwrite to write the structure to the CSV file
but write each member to the file with the appropriate format
specification (as with fprintf), my previous comment applies here
also.

>Now I understand that the choice of the structure to read the data
>from csv file is not the best one, because I do not need to separate
>data into different variables' types; csv will give data line by line.
>But then to process that data, I think I will need the structure to 
>separate character arrays from numerical arrays. When the processing

Once again, having members of a structure is no different than having
individual variables.

>is done, I will need to convert each structure back to a character 
>array and write those into csv file.  

Actually, you will need to convert each member of the structure to the
proper text.  If you use fprintf, the conversion happens as part of
the output process.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#99024

On Monday, December 12, 2016 at 12:19:54 PM UTC+3, Barry Schwarz wrote:
> On Mon, 12 Dec 2016 00:44:45 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
> 
> <snip>
> 
> >This last paragraph is confusing again, although the ones before it
> >are very helpful. I have addressed your questions on formats, I hope
> >it is clear now. 
> >My goal is to get data from csv file, process it, write to another csv file.
> >Structure is what I thought is the appropriate format to store the data 
> >the program reads from the csv file, and then extract that data for 
> 
> There is nothing wrong with storing the data you read from the CSV
> file in a structure.  Just be aware that having a structure with
> members of type int, char[15], char[10], and double is no different
> than having four variables stand-alone variables of type int,
> char[15], char[10], and double.  If you use the structure, every
> reference in your code a member will have to include the name of the
> structure object.  So will you find it more meaningful to refer to the
> last name as clientData.lastname or as lastname?
> 
> >processing, store the results in structure, and write to csv file. 
> 
> As long as you don't use fwrite to write the structure to the CSV file
> but write each member to the file with the appropriate format
> specification (as with fprintf), my previous comment applies here
> also.
> 
> >Now I understand that the choice of the structure to read the data
> >from csv file is not the best one, because I do not need to separate
> >data into different variables' types; csv will give data line by line.
> >But then to process that data, I think I will need the structure to 
> >separate character arrays from numerical arrays. When the processing
> 
> Once again, having members of a structure is no different than having
> individual variables.
> 
> >is done, I will need to convert each structure back to a character 
> >array and write those into csv file.  
> 
> Actually, you will need to convert each member of the structure to the
> proper text.  If you use fprintf, the conversion happens as part of
> the output process.
>
I see. Thank you very much. I will do my best to implement this. 

[toc] | [prev] | [next] | [standalone]

#99042

On 12/12/2016 10:19 AM, Barry Schwarz wrote:
> Once again, having members of a structure is no different than having
> individual variables.

This is true for what is concerned with the result.
 From the software design point of view, there is a difference in that 
structures allow to clearly group together data items that belong to the 
same conceptual set.
Obviously this is a help for the programmer (and code 
reviewers/maintainers), it has no impact on the resulting executable.

In the case of the D&D random access example, it was on the other hand 
required in order to ensure that the data items be contiguously stored 
in memory, and transferred via fread/fwrite.

[toc] | [prev] | [next] | [standalone]

#99127

On Monday, December 12, 2016 at 2:10:34 PM UTC, Manfred wrote:
> On 12/12/2016 10:19 AM, Barry Schwarz wrote:
> > Once again, having members of a structure is no different than having
> > individual variables.
> 
> This is true for what is concerned with the result.
>  From the software design point of view, there is a difference in that 
> structures allow to clearly group together data items that belong to the 
> same conceptual set.
> Obviously this is a help for the programmer (and code 
> reviewers/maintainers), it has no impact on the resulting executable.
> 
With CSV files and C, the question is whether we know what the
columns of the CSV file will be at compile time. If we know that
employees always have first name, last name, payroll id and salary,
the logical thing is to set up an Employee structure with those 
fields.

But often you need to be more flexible than that. So you need something
which will allow you to add fields of arbitrary type, at runtime.
Javascript allows that, in C you need to build support for it by
hand.

[toc] | [prev] | [next] | [standalone]

#98741

On Saturday, December 10, 2016 at 5:30:20 PM UTC, Alla _ wrote:
>
> Here is a corrected version of a program that:
> (1) creates an csv file
> (2) gets data from the user
> (3) writes the received data into a file
> 
You need to understand the concept of the "data frame".
The columns represents observations or measurements, the rows represent
subjects. So an employee will have a first name, a surname, a payroll id,
and a salary. A schoolchild might have name, surname, date of birth, and
marks in maths, physics, chemistry, English.

Generally it's rare to add or delete columns, common to add or delete
rows. 

A CSV file is basically a textual representation of a data frame. If
you know the columns at compile time, which is the most common situation,
it's very easy to write one. Just write out the header, then call 
printf() in a loop for the records. The only problem is in escaping 
the strings. But usually names are constrained to be alpha-only, or 
maybe alpha with hyphens, so escaping isn't difficult.

Reading is harder, especially if you want to accept data where you
know all the columns at compile time.

But the trick is to keep the data frame together as a single object,
then write it as a single object. In C it is normally an array of
structs, but the structs are simple structs, with only strings, reals,
and enumerated types as members.

[toc] | [prev] | [next] | [standalone]

#98759

On Sunday, December 11, 2016 at 1:30:01 AM UTC+3, Malcolm McLean wrote:
> On Saturday, December 10, 2016 at 5:30:20 PM UTC, Alla _ wrote:
> >
> > Here is a corrected version of a program that:
> > (1) creates an csv file
> > (2) gets data from the user
> > (3) writes the received data into a file
> > 
> You need to understand the concept of the "data frame".
> The columns represents observations or measurements, the rows represent
> subjects. So an employee will have a first name, a surname, a payroll id,
> and a salary. A schoolchild might have name, surname, date of birth, and
> marks in maths, physics, chemistry, English.
> 
Yes, thank you. I guess I understand what a data frame is, at least to some 
extent when it comes to working with financial data. What I still don't understand
is how to write the data from and to the csv file; this particular program was
supposed to write the final data into csv file. I still fail to understand a few
nuances about connecting C and csv format. Learning. 
> Generally it's rare to add or delete columns, common to add or delete
> rows. 
> 
Depending on a data your work with, I can assure you it is not rare to 
add/delete columns - depends on what type of data one works with,
on the stage one is at, and on lots of other parameters and goals.
 

> A CSV file is basically a textual representation of a data frame. If
> you know the columns at compile time, which is the most common situation,
> it's very easy to write one. Just write out the header, then call 
> printf() in a loop for the records. The only problem is in escaping 
> the strings. But usually names are constrained to be alpha-only, or 
> maybe alpha with hyphens, so escaping isn't difficult.

I love this word "just" ) I am sorry, but for me "just write out the header"
doesn't ring a bell at all. And how can I escape strings, if I have to have
names of fields? It seems I also have yet no idea how to write alpha words
not in a string variable.
> 
> Reading is harder, especially if you want to accept data where you
> know all the columns at compile time.
> 
> But the trick is to keep the data frame together as a single object,
> then write it as a single object. In C it is normally an array of
> structs, but the structs are simple structs, with only strings, reals,
> and enumerated types as members.

[toc] | [prev] | [next] | [standalone]

#98763

On Sunday, December 11, 2016 at 7:57:06 AM UTC, Alla _ wrote:
>
> I love this word "just" ) I am sorry, but for me "just write
> out the header doesn't ring a bell at all. And how can I escape 
> strings, if I have to have names of fields? It seems I also have 
> yet no idea how to write alpha words not in a string variable.
> 
We have 

struct employee
{
   char *fname;
   char *sname;
   long payrollid;
   float salary;
}

We want a CSV file that looks like this

First name, Surname, ID, Salary
"Fred", "Bloggs", 1234567, 32000.00
"Joe", "Sixpack", 2345678, 29000.00
"Dilbert", "Smith", 7654321, 45000,00

You have to know what names you will give the columns.
Whilst they will bear a relation to the struct field
names, it's unlikely they will be all identical.

Then the names have to be wrapped in quotes, and the 
salaries formatted so that there are exactly two figures 
after the decimal place.

It gets harder if commas or other punctuation is allowed 
in names. That's what "escaping the string" means. However
most databases disallow commas in people's names.

[toc] | [prev] | [next] | [standalone]

#98768

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, December 11, 2016 at 7:57:06 AM UTC, Alla _ wrote:
>> I love this word "just" ) I am sorry, but for me "just write
>> out the header doesn't ring a bell at all. And how can I escape 
>> strings, if I have to have names of fields? It seems I also have 
>> yet no idea how to write alpha words not in a string variable.
>> 
> We have 
>
> struct employee
> {
>    char *fname;
>    char *sname;
>    long payrollid;
>    float salary;
> }
>
> We want a CSV file that looks like this
>
> First name, Surname, ID, Salary
> "Fred", "Bloggs", 1234567, 32000.00
> "Joe", "Sixpack", 2345678, 29000.00
> "Dilbert", "Smith", 7654321, 45000,00

No, a CSV file normally doesn't have spaces after the commas, unless the
spaces are part of the fields.  (And you have a typo on the last line.)

I'd expect that to look like:

First name,Surname,ID,Salary
Fred,Bloggs,1234567,32000.00
Joe,Sixpack,2345678,29000.00
Dilbert,Smith,7654321,45000.00

> You have to know what names you will give the columns.
> Whilst they will bear a relation to the struct field
> names, it's unlikely they will be all identical.
>
> Then the names have to be wrapped in quotes, and the 
> salaries formatted so that there are exactly two figures 
> after the decimal place.

Why do the names have to be wrapped in quotes?  CSV formats require
quotes only for fields that contain special characters, particularly
embedded commas.

Why do the salaries in the CSV file have to have exactly two digits
after the decimal?  All that should really matter is that the correct
value is represented.

> It gets harder if commas or other punctuation is allowed 
> in names. That's what "escaping the string" means. However
> most databases disallow commas in people's names.

I find that difficult to believe.  Is "John Smith, Junior" just out of
luck?  A database should make as few assumptions as possible about
people's names.  You might want to take a look at this:
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web