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 1 of 2  [1] 2  Next page →

#98718 — Program to create csv file and write into it

Hello!

I have learned a lot (I understand that it's a lot for me but nothing for majority of you :) )
during these days thanks to great help I have received here. 

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

I have tested it with the following input:

Enter account number ( 1 to 3, 0 to end input )
? 89
Enter lastname, firstname, balance
? Brown James 109
Enter account number
? 4
Enter lastname, firstname, balance
? Hampton Kira 67
Enter account number
? 1        
Enter lastname, firstname, balance
? Ritz Rob 200
Enter account number
? 0

and..... I got a correct csv file )))))))))))))))))))))) Sorry for all these smiles, but that's
how I feel now ) Though I know that upon posting a program I will definitely be chastised
for some wrong coding and thinking )
Here is the result:

1,Ritz,Rob,200.00
4,Hampton,Kira,67.00
89,Brown,James,109.00

And it is even sorted! I didn't not expect that ) I shun using exclamation marks, but 
in this case I was truly surprised.

I am not sure that the first comment still holds - is in a random-access file?

// Writing data randomly to a random-access file
#include <stdio.h>

// clientData structure definition
struct clientData {
    unsigned int acctNum; // account number
    char lastName[ 15 ]; // account last name
    char firstName[ 10 ]; // account first name
    double balance; // account balance
};

int main( void )
{
    
    FILE *cfPtr; // credit.csv file pointer
    
    // create clientData with default information
    struct clientData client = { 0, "", "", 0.0 };
    
    // fopen opens the file; exits if file cannot be opened
    if ( ( cfPtr = fopen( "credit.csv", "w+" ) ) == NULL )
    {
        puts( "File could not be opened." );
    }
    else
    {
      // require user to specify account number
      printf( "%s", "Enter account number"
                " ( 1 to 3, 0 to end input )\n? " );
      while (scanf( "%u", &client.acctNum ) == 1 && client.acctNum != 0)
      {
          // user enters last name, first name and balance
          printf( "%s", "Enter lastname, firstname, balance\n? " );
          
          if(fscanf( stdin, "%14s%9s%lf", client.lastName,
                       client.firstName, &client.balance) != 3)
          {
              printf( "%s", "Incorrect input. Enter account number again\n? " );
              continue;
          }
          else
          {
              // seek position in file to user-specified record
              fseek( cfPtr, ( client.acctNum - 1 ) *
                    sizeof( struct clientData ), SEEK_SET );
              
              // write user-specified information in file
              fprintf( cfPtr, "%u,%s,%s,%.2f\n", client.acctNum, 
               client.lastName, client.firstName, client.balance);
              
             // enable user to input another account number
              printf( "%s", "Enter account number\n? " );
          }
          
       }
       fclose(cfPtr);
    }
}

Thank you!

[toc] | [next] | [standalone]

#98731

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

> I have learned a lot (I understand that it's a lot for me but nothing
> for majority of you :) ) during these days thanks to great help I have
> received here.
>
> 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
>
> I have tested it with the following input:
>
> Enter account number ( 1 to 3, 0 to end input )
> ? 89
> Enter lastname, firstname, balance
> ? Brown James 109
> Enter account number
> ? 4
> Enter lastname, firstname, balance
> ? Hampton Kira 67
> Enter account number
> ? 1        
> Enter lastname, firstname, balance
> ? Ritz Rob 200
> Enter account number
> ? 0
>
> and..... I got a correct csv file )))))))))))))))))))))) Sorry for all
> these smiles, but that's how I feel now )

Sorry to be the bearer of bad news, but that's not a CSV file.  A CSV
file is a text file and would not contain all those nulls.  The records
would simply be contiguous lines.

I'm not sure if you can see all the nulls, so to start you should find
something like a hex dump program and learn to read what its output
means.  If you are, as it seems, going to be writing binary
random-access files, you will need a hex dump program.

I won't comment on the code in detail because I don't know what you want
to write -- a binary random-access data file or a text-based CSV one.

<snip>
-- 
Ben.

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

#98732

On Saturday December 10 2016 15:42, in comp.lang.c, "Ben Bacarisse"
<ben.usenet@bsb.me.uk> wrote:

> Alla _ <modelling.data@gmail.com> writes:
> 
>> I have learned a lot (I understand that it's a lot for me but nothing
>> for majority of you :) ) during these days thanks to great help I have
>> received here.
>>
>> 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
>>
>> I have tested it with the following input:
>>
>> Enter account number ( 1 to 3, 0 to end input )
>> ? 89
>> Enter lastname, firstname, balance
>> ? Brown James 109
>> Enter account number
>> ? 4
>> Enter lastname, firstname, balance
>> ? Hampton Kira 67
>> Enter account number
>> ? 1
>> Enter lastname, firstname, balance
>> ? Ritz Rob 200
>> Enter account number
>> ? 0
>>
>> and..... I got a correct csv file )))))))))))))))))))))) Sorry for all
>> these smiles, but that's how I feel now )
> 
> Sorry to be the bearer of bad news, but that's not a CSV file.  A CSV
> file is a text file and would not contain all those nulls.  The records
> would simply be contiguous lines.

At first, I couldn't figure out what you and Alla were talking about; in my
newsreader, her post terminated immediately after the
1,Ritz,Rob,200.00
line, and contained neither the nulls you refer to nor the source code that
she alluded to at the top of her post.

But, then, I captured the original posting (in base64 format) and extracted
the body text by hand. It appears that /my/ newsreader decided that the (now
apparent) nulls marked the end of the post, and showed me neither the nulls
nor anything that followed.

> I'm not sure if you can see all the nulls, so to start you should find
> something like a hex dump program and learn to read what its output
> means.  If you are, as it seems, going to be writing binary
> random-access files, you will need a hex dump program.

[snip]

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#98733

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Saturday December 10 2016 15:42, in comp.lang.c, "Ben Bacarisse"
> <ben.usenet@bsb.me.uk> wrote:
>
>> Alla _ <modelling.data@gmail.com> writes:
<snip>
>>> and..... I got a correct csv file )))))))))))))))))))))) Sorry for all
>>> these smiles, but that's how I feel now )
>> 
>> Sorry to be the bearer of bad news, but that's not a CSV file.  A CSV
>> file is a text file and would not contain all those nulls.  The records
>> would simply be contiguous lines.
>
> At first, I couldn't figure out what you and Alla were talking about; in my
> newsreader, her post terminated immediately after the
> 1,Ritz,Rob,200.00
> line, and contained neither the nulls you refer to nor the source code that
> she alluded to at the top of her post.
>
> But, then, I captured the original posting (in base64 format) and extracted
> the body text by hand. It appears that /my/ newsreader decided that the (now
> apparent) nulls marked the end of the post, and showed me neither the nulls
> nor anything that followed.

Ha.  I did not think that might happen!  I thought that maybe they would
simply be invisible.  They appear to me as ^@ so they were really
obvious.

I don't even know if nulls are permitted in news articles, but Google
certainly made the extra effort since it used a binary-safe
transfer-encoding to send the message.

<snip>
-- 
Ben.

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

#98757

On Saturday, December 10, 2016 at 11:42:20 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> 
> > I have learned a lot (I understand that it's a lot for me but nothing
> > for majority of you :) ) during these days thanks to great help I have
> > received here.
> >
> > 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
> >
> > I have tested it with the following input:
> >
> > Enter account number ( 1 to 3, 0 to end input )
> > ? 89
> > Enter lastname, firstname, balance
> > ? Brown James 109
> > Enter account number
> > ? 4
> > Enter lastname, firstname, balance
> > ? Hampton Kira 67
> > Enter account number
> > ? 1        
> > Enter lastname, firstname, balance
> > ? Ritz Rob 200
> > Enter account number
> > ? 0
> >
> > and..... I got a correct csv file )))))))))))))))))))))) Sorry for all
> > these smiles, but that's how I feel now )
> 
> Sorry to be the bearer of bad news, but that's not a CSV file.  A CSV
> file is a text file and would not contain all those nulls.  The records
> would simply be contiguous lines.
> 
> I'm not sure if you can see all the nulls, so to start you should find
> something like a hex dump program and learn to read what its output
> means.  If you are, as it seems, going to be writing binary
> random-access files, you will need a hex dump program.
> 
> I won't comment on the code in detail because I don't know what you want
> to write -- a binary random-access data file or a text-based CSV one.
> 
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
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 
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.

(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 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 
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
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?

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? 

> <snip>
> -- 
> Ben.

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

#98760

On Sunday, December 11, 2016 at 7:48:24 AM UTC, Alla _ wrote:
> 
> (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
>
Excel will produce csv files. But it will also produce very strange ones
unless you set it up correctly.

Make sure the spreadsheet is simple, and that the csv file is similarly
simple. Missing data and derived data (eg averages) is always a 
problem and that might be what the large blanks represent. However
presumably you don't have any really missing data and you can re-derive
all your derived data easily, so you should eliminate those problems
in the construction of the initial csv file.

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

#98767

Alla _ <modelling.data@gmail.com> writes:
[...]
> (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. 

Don't assume that.

A file whose contents you posted here recently did contain a lot of null
characters.  My newsreader displayed them as "^@"; someone else's didn't
show them, or anything following them, at all (it probably treated the
article internally as a null-terminated string).

If you want to examine a file and determine whether it contains null
characters, you need to use some tool that can view binary files and
display their contents in an unambiguous manner.

If you're on a Unix-like system, there are a number of options:
"od", "hexdump"/"hd", "cat -A".  If you're on Windows, there should be
some kind of binary file viewer you can install, or an option in
whatever text editor you're using.

[...]

-- 
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] | [next] | [standalone]

#98769

Alla _ <modelling.data@gmail.com> writes:
[...]
> (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

The obvious way to generate an Excel spreadsheet to CSV format is to use
Excel to save the file in that format.  (You might need to set a few
options to be sure you're getting the right format.)  Writing a C
program to read the .xls binary format is possible in principle, but
it's not not, in my opinion, either practical or necessary; the format
is, if I'm not mistaken, insanely complicated.

Which means that you *don't* need to write C code to generate as CSV
file (which is what much of this thread has been about).

> # read data from those csv files using C language

That's certainly feasible.  (There are existing libraries that will do
that for you, but of course that doesn't help if your goal is to learn
how to write the code yourself.)  But again, you need to be able to
*read* CSV files, but you don't need to be able to *write* them.

> # process that data (a few functions) to compute pro forma financial
> statements,
[snip]

That sounds feasible, but I don't know enough about financial statements
to comment further.  (I presume there's a well defined format you're
aiming for.)

[...]

-- 
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] | [next] | [standalone]

#98788

<snip>
> > # read data from those csv files using C language
> 
> That's certainly feasible.  (There are existing libraries that will do
> that for you, but of course that doesn't help if your goal is to learn
> how to write the code yourself.)  But again, you need to be able to
> *read* CSV files, but you don't need to be able to *write* them.
> 
But I have to output the result in a file, and I assume it also has to be 
csv one, so I will have to write the function to store the final data
in a csv file. Is this yet another wrong assumption?

> > # process that data (a few functions) to compute pro forma financial
> > statements,
> [snip]
> 
> That sounds feasible, but I don't know enough about financial statements
> to comment further.  (I presume there's a well defined format you're
> aiming for.)
> 
> [...]
> 
> -- 
> 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] | [next] | [standalone]

#98848

On Sun, 11 Dec 2016 04:50:23 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

><snip>
>> > # read data from those csv files using C language
>> 
>> That's certainly feasible.  (There are existing libraries that will do
>> that for you, but of course that doesn't help if your goal is to learn
>> how to write the code yourself.)  But again, you need to be able to
>> *read* CSV files, but you don't need to be able to *write* them.
>> 
>But I have to output the result in a file, and I assume it also has to be 
>csv one, so I will have to write the function to store the final data
>in a csv file. Is this yet another wrong assumption?

How would we know?  You have said you are doing this for a course but
have not shown us the assignment.  If the real assignment is to write
a financial statement, I would expect CSV NOT to be the desired
format.

>> > # process that data (a few functions) to compute pro forma financial
>> > statements,

-- 
Remove del for email

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

#98997

On Sunday, December 11, 2016 at 8:42:17 PM UTC+3, Barry Schwarz wrote:
> On Sun, 11 Dec 2016 04:50:23 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
> 
> ><snip>
> >> > # read data from those csv files using C language
> >> 
> >> That's certainly feasible.  (There are existing libraries that will do
> >> that for you, but of course that doesn't help if your goal is to learn
> >> how to write the code yourself.)  But again, you need to be able to
> >> *read* CSV files, but you don't need to be able to *write* them.
> >> 
> >But I have to output the result in a file, and I assume it also has to be 
> >csv one, so I will have to write the function to store the final data
> >in a csv file. Is this yet another wrong assumption?
> 
> How would we know?  You have said you are doing this for a course but
> have not shown us the assignment.  If the real assignment is to write
> a financial statement, I would expect CSV NOT to be the desired
> format.
> 

Barry, I am very thankful for your help, truly; but sometimes it seems that 
you read my explanations only partially, or, maybe, my English is so poor that 
my goals are clear only to me, or, maybe, I lack the ability to clearly explain
what I am doing (I did my best to write in the list format, which is usually 
easier to see and understand). I also think that stressing out any words 
in the text is not a good habit, therefore I try not to do that, hoping that 
important parts stand out per se:

(1) yes, this is my assignment, but I have chosen it; the official assignment
is: "write a project of your choice" and that's it; well, not really - tiny addition
says that it has to be "more involved" than the ones I did during the course;

but I myself have chosen this project; it is my idea, and, as I have already explained
a few times in other different posts, the goal is to continue learning C, and not to
spend time on figuring out out of programming scripts, techniques, etc. Therefore
I have chosen the topic I know and which is very easy, i.e. computation of forecasted
fin statements (a simplified version with many assumptions). One more time - 
learning how to program in C, how to think as a programmer, develop these skills further
is the goal of this (and lots of further) exercises;

(2) steps:
- take excel file, convert to csv (nothing to do with C); so you can skip this part
- take csv file, read data from it (in the form I have shown in an other message here)
- process the data to compute forecasted income statement
- write the result to a new csv file
- convert that csv to excel (nothing to do with C, so you can skip this)

This is the plan I am not changing and to which I am committed.

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

#99004

On 12/12/16 08:13, Alla _ wrote:

<snip>

> but I myself have chosen this project; it is my idea, and, as I have already explained
> a few times in other different posts, the goal is to continue learning C, and not to
> spend time on figuring out out of programming scripts, techniques, etc. Therefore
> I have chosen the topic I know and which is very easy, i.e. computation of forecasted
> fin statements (a simplified version with many assumptions). One more time -
> learning how to program in C, how to think as a programmer, develop these skills further
> is the goal of this (and lots of further) exercises;
>
> (2) steps:
> - take excel file, convert to csv (nothing to do with C); so you can skip this part

Okay, no problem there.

> - take csv file, read data from it (in the form I have shown in an other message here)

No problem there.

> - process the data to compute forecasted income statement

Problem. Task not well-defined, at least not from our perspective. Now, 
it may well be that you have a very clear understanding of this step. 
That's fine. Write it down.

> - write the result to a new csv file

I thought you wanted to export into a mysql database? What happened to 
that idea?

Do you see why it's a good idea to write down the specification? 
Otherwise, it keeps changing!

-- 
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]

#99008

On Monday, December 12, 2016 at 11:34:34 AM UTC+3, Richard Heathfield wrote:
> On 12/12/16 08:13, Alla _ wrote:
> 
> <snip>
> 
> > but I myself have chosen this project; it is my idea, and, as I have already explained
> > a few times in other different posts, the goal is to continue learning C, and not to
> > spend time on figuring out out of programming scripts, techniques, etc. Therefore
> > I have chosen the topic I know and which is very easy, i.e. computation of forecasted
> > fin statements (a simplified version with many assumptions). One more time -
> > learning how to program in C, how to think as a programmer, develop these skills further
> > is the goal of this (and lots of further) exercises;
> >
> > (2) steps:
> > - take excel file, convert to csv (nothing to do with C); so you can skip this part
> 
> Okay, no problem there.
> 
> > - take csv file, read data from it (in the form I have shown in an other message here)
> 
> No problem there.
> 
> > - process the data to compute forecasted income statement
> 
> Problem. Task not well-defined, at least not from our perspective. Now, 
> it may well be that you have a very clear understanding of this step. 
> That's fine. Write it down.
No problem here ) You have not seen the post I have written here yesterday, 
in which I have described every step of this part. I don't know how to 
attach links to previous posts in GG. 

> 
> > - write the result to a new csv file
> 
> I thought you wanted to export into a mysql database? What happened to 
> that idea?
I have addressed this issue yesterday as well. I have thought of using mysql
because I hoped that it will help me to escape csv stage and convert excel 
to mysql, get data from mysql (with c), process that data (with c), write back
to mysql, then to excel. As far as csv stage is unescapable, I am not sure 
I will need to use mysql; maybe I will but only for training purposes, to make
the program more complex and to learn more c features. 
> 
> Do you see why it's a good idea to write down the specification? 
> Otherwise, it keeps changing!
> 
> -- 
> 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]

#99013

On 12/12/16 08:50, Alla _ wrote:
> On Monday, December 12, 2016 at 11:34:34 AM UTC+3, Richard Heathfield wrote:
>> On 12/12/16 08:13, Alla _ wrote:
>>
>>> - process the data to compute forecasted income statement
>>
>> Problem. Task not well-defined, at least not from our perspective. Now,
>> it may well be that you have a very clear understanding of this step.
>> That's fine. Write it down.
> No problem here ) You have not seen the post I have written here yesterday,
> in which I have described every step of this part. I don't know how to
> attach links to previous posts in GG.

I've read the whole newsfeed, but I must have overlooked that article. 
The most detailed description I can find is "already computed pro forma 
data" which you plan to write to a CSV file. If your data are 
pre-computed I don't see why you need to write a program at all! 
Presumably there is more to it than that.

But the most important thing is that you have the spec written down 
somewhere where you can refer to it and answer questions about it.

>>> - write the result to a new csv file
>>
>> I thought you wanted to export into a mysql database? What happened to
>> that idea?
> I have addressed this issue yesterday as well. I have thought of using mysql
> because I hoped that it will help me to escape csv stage

"She swallowed the spider to catch the fly. I don't know why she 
swallowed the fly."

So SQL is out? Pity. Would have been interesting. But okay.

So you now know exactly what program you're writing. (If I sound 
sceptical, it's because I /am/ sceptical.)

-- 
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]

#99030

On Monday, December 12, 2016 at 12:02:29 PM UTC+3, Richard Heathfield wrote:
> On 12/12/16 08:50, Alla _ wrote:
> > On Monday, December 12, 2016 at 11:34:34 AM UTC+3, Richard Heathfield wrote:
> >> On 12/12/16 08:13, Alla _ wrote:
> >>
<skip>
> But the most important thing is that you have the spec written down 
> somewhere where you can refer to it and answer questions about it.
> 
> >>> - write the result to a new csv file
> >>
> >> I thought you wanted to export into a mysql database? What happened to
> >> that idea?
> > I have addressed this issue yesterday as well. I have thought of using mysql
> > because I hoped that it will help me to escape csv stage
> 
> "She swallowed the spider to catch the fly. I don't know why she 
> swallowed the fly."
> 
> So SQL is out? Pity. Would have been interesting. But okay.
> 
I am not saying it's totally out of consideration. Let's see.
Maybe I will do that. 

> So you now know exactly what program you're writing. (If I sound 
> sceptical, it's because I /am/ sceptical.)
> 
Here is the quotation from my post above in this thread:
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 a truncated 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 

> -- 
> 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]

#99031

On 12/12/16 10:52, Alla _ wrote:
> On Monday, December 12, 2016 at 12:02:29 PM UTC+3, Richard Heathfield wrote:
>> On 12/12/16 08:50, Alla _ wrote:
>>> On Monday, December 12, 2016 at 11:34:34 AM UTC+3, Richard Heathfield wrote:
>>>> On 12/12/16 08:13, Alla _ wrote:
>>>>
> <skip>
>> But the most important thing is that you have the spec written down
>> somewhere where you can refer to it and answer questions about it.
>>
>>>>> - write the result to a new csv file
>>>>
>>>> I thought you wanted to export into a mysql database? What happened to
>>>> that idea?
>>> I have addressed this issue yesterday as well. I have thought of using mysql
>>> because I hoped that it will help me to escape csv stage
>>
>> "She swallowed the spider to catch the fly. I don't know why she
>> swallowed the fly."
>>
>> So SQL is out? Pity. Would have been interesting. But okay.
>>
> I am not saying it's totally out of consideration. Let's see.
> Maybe I will do that.
>
>> So you now know exactly what program you're writing. (If I sound
>> sceptical, it's because I /am/ sceptical.)
>>
> Here is the quotation from my post above in this thread:
> 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

Which average are you going to use? Arithmetic mean? Geometric mean? 
Harmonic mean? Median? Mode? I'm guessing you intend to use the 
arithmetic mean, but it's as well to specify these things precisely. 
Note that the arithmetic mean is probably about the worst measure you 
could choose here!

Anyway, it seems that you have gone to some trouble to specify the 
problem. That's good. Thank you for posting your specification -- I will 
save it for future reference.

-- 
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]

#99033

On Monday, December 12, 2016 at 1:59:12 PM UTC+3, Richard Heathfield wrote:
> On 12/12/16 10:52, Alla _ wrote:
> > On Monday, December 12, 2016 at 12:02:29 PM UTC+3, Richard Heathfield wrote:
> >> On 12/12/16 08:50, Alla _ wrote:
> >>> On Monday, December 12, 2016 at 11:34:34 AM UTC+3, Richard Heathfield wrote:
> >>>> On 12/12/16 08:13, Alla _ wrote:
> >>>>
> > <skip>
<skip>
> >        1.1.3. find the average of all results in 1.1.2
> 
> Which average are you going to use? Arithmetic mean? Geometric mean? 
> Harmonic mean? Median? Mode? I'm guessing you intend to use the 
> arithmetic mean, but it's as well to specify these things precisely. 
> Note that the arithmetic mean is probably about the worst measure you 
> could choose here!
I agree that rithmetic mean is not a good measure; geometric is a more 
telling one. But none of them is important for the task. I will use an arithmetic 
one; these are simplified statements, so I don't plan to bother with any accuracy
other than in C programming. For the real world application none of these
rates, used separately as I intend to do in this program, would make much sense.
Anyway any forecasted model is just someone's fantasy; and is useful only
for scenario constructing, but not per se. 
> 
> Anyway, it seems that you have gone to some trouble to specify the 
> problem. That's good. Thank you for posting your specification -- I will 
> save it for future reference.
> 
> -- 
> 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]

#98869

On 12/11/2016 01:50 PM, Alla _ wrote:
> <snip>
>>> > > # read data from those csv files using C language
>> >
>> > That's certainly feasible.  (There are existing libraries that will do
>> > that for you, but of course that doesn't help if your goal is to learn
>> > how to write the code yourself.)  But again, you need to be able to
>> > *read* CSV files, but you don't need to be able to *write* them.
>> >
> But I have to output the result in a file, and I assume it also has to be
> csv one, so I will have to write the function to store the final data
> in a csv file. Is this yet another wrong assumption?
>

OK, now that you made clear to start with the last part of the 
assignment (writing the csv file), which by the way seems reasonable, 
because as someone else already pointed out writing the csv is much 
easier than reading it, I suggest you rethink carefully why you used the 
following combination (from the source you posted earlier)

<snip>
           {
               // seek position in file to user-specified record
               fseek( cfPtr, ( client.acctNum - 1 ) *
                     sizeof( struct clientData ), SEEK_SET );

               // write user-specified information in file
               fprintf( cfPtr, "%u,%s,%s,%.2f\n", client.acctNum,
                client.lastName, client.firstName, client.balance);
           }
<snip>

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

#98995

On Sunday, December 11, 2016 at 10:44:28 PM UTC+3, mx2927 wrote:
> On 12/11/2016 01:50 PM, Alla _ wrote:
> > <snip>
> >>> > > # read data from those csv files using C language
> >> >
> >> > That's certainly feasible.  (There are existing libraries that will do
> >> > that for you, but of course that doesn't help if your goal is to learn
> >> > how to write the code yourself.)  But again, you need to be able to
> >> > *read* CSV files, but you don't need to be able to *write* them.
> >> >
> > But I have to output the result in a file, and I assume it also has to be
> > csv one, so I will have to write the function to store the final data
> > in a csv file. Is this yet another wrong assumption?
> >
> 
> OK, now that you made clear to start with the last part of the 
> assignment (writing the csv file), which by the way seems reasonable, 
> because as someone else already pointed out writing the csv is much 
> easier than reading it, I suggest you rethink carefully why you used the 
> following combination (from the source you posted earlier)
> 
> <snip>
>            {
>                // seek position in file to user-specified record
>                fseek( cfPtr, ( client.acctNum - 1 ) *
>                      sizeof( struct clientData ), SEEK_SET );
> 
>                // write user-specified information in file
>                fprintf( cfPtr, "%u,%s,%s,%.2f\n", client.acctNum,
>                 client.lastName, client.firstName, client.balance);
>            }
> <snip>
Thank you. Yes, indeed, I have to work on this part, which I have copied from the original
book; it is not yet completely clear to me that I need fseek function. 

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

#99014

On Sun, 11 Dec 2016 23:57:23 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>On Sunday, December 11, 2016 at 10:44:28 PM UTC+3, mx2927 wrote:
>> On 12/11/2016 01:50 PM, Alla _ wrote:
>> > <snip>
>> >>> > > # read data from those csv files using C language
>> >> >
>> >> > That's certainly feasible.  (There are existing libraries that will do
>> >> > that for you, but of course that doesn't help if your goal is to learn
>> >> > how to write the code yourself.)  But again, you need to be able to
>> >> > *read* CSV files, but you don't need to be able to *write* them.
>> >> >
>> > But I have to output the result in a file, and I assume it also has to be
>> > csv one, so I will have to write the function to store the final data
>> > in a csv file. Is this yet another wrong assumption?
>> >
>> 
>> OK, now that you made clear to start with the last part of the 
>> assignment (writing the csv file), which by the way seems reasonable, 
>> because as someone else already pointed out writing the csv is much 
>> easier than reading it, I suggest you rethink carefully why you used the 
>> following combination (from the source you posted earlier)
>> 
>> <snip>
>>            {
>>                // seek position in file to user-specified record
>>                fseek( cfPtr, ( client.acctNum - 1 ) *
>>                      sizeof( struct clientData ), SEEK_SET );
>> 
>>                // write user-specified information in file
>>                fprintf( cfPtr, "%u,%s,%s,%.2f\n", client.acctNum,
>>                 client.lastName, client.firstName, client.balance);
>>            }
>> <snip>
>Thank you. Yes, indeed, I have to work on this part, which I have copied from the original
>book; it is not yet completely clear to me that I need fseek function. 

Not only do you not need the call to fseek but if you leave it in you
will no longer have a properly formatted CSV file.

(fseek was only useful when you were writing out the complete
structure.  You are no longer doing that.)

-- 
Remove del for email

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web