Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100280 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-12-26 00:31 -0800 |
| Last post | 2016-12-26 14:38 -0800 |
| Articles | 20 on this page of 252 — 20 participants |
Back to article view | Back to comp.lang.c
Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 00:31 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 01:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 02:25 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 14:04 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 12:04 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 05:49 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 15:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 07:31 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <mx2927@gmail.com> - 2016-12-26 16:44 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 08:00 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 17:43 +0000
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-26 12:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 23:56 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 09:33 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <mx2927@gmail.com> - 2016-12-26 17:06 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 09:48 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-26 19:03 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 10:39 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 19:49 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-26 20:56 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-26 13:50 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 00:27 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 09:35 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:33 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 20:48 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 15:31 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 18:56 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 01:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:33 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 00:16 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 14:05 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 23:49 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-28 15:34 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-28 08:49 -0800
Re: Reading lines from a file, eliminating CR and LF "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 12:55 -0500
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 00:19 -0800
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:01 -0800
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 07:35 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2016-12-29 08:58 -0800
Re: Reading lines from a file, eliminating CR and LF raltbos@xs4all.nl (Richard Bos) - 2017-01-01 15:21 +0000
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-29 09:19 -0800
Re: Reading lines from a file, eliminating CR and LF Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-30 08:39 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-30 09:02 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:22 -0800
Re: Reading lines from a file, eliminating CR and LF "Peter \"Shaggy\" Haywood" <phaywood@alphalink.com.au> - 2016-12-31 00:22 +1100
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 03:29 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 10:09 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 14:01 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 16:35 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 16:49 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-03 05:32 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-03 08:47 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 15:39 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 17:35 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 20:00 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 08:24 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 13:15 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 17:00 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 19:48 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 09:32 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-13 12:52 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 15:46 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-15 16:54 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 11:25 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-30 14:06 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2016-12-29 06:07 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:11 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 09:37 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-27 19:29 +0100
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2016-12-27 11:41 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:30 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2016-12-28 16:08 -0800
Re: Reading lines from a file, eliminating CR and LF fir <profesor.fir@gmail.com> - 2016-12-27 12:50 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 09:59 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-27 10:56 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-27 12:24 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 08:35 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-28 09:16 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:08 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-27 22:34 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 08:39 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 02:20 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:11 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 00:20 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-29 14:56 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 22:35 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-30 22:45 +0100
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 00:01 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-31 03:19 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:20 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:23 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:29 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 11:10 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 10:53 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 20:24 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 00:53 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:28 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-29 14:48 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 22:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:55 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 10:14 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-29 11:44 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 02:02 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:13 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 14:49 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:28 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:45 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 13:53 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 08:23 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:50 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 13:35 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-30 15:22 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 08:29 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 16:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 10:50 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-31 19:02 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 20:10 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 04:08 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 12:38 +0000
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2017-01-01 13:45 +0000
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2017-01-01 13:54 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:26 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 16:46 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 17:08 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 08:13 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 16:47 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 16:53 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 09:18 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2017-01-01 19:20 +0100
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-01 15:18 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 03:41 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:07 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 09:05 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 19:16 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 03:39 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 04:02 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 13:48 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 13:47 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 07:21 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 18:38 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 10:57 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 21:48 +0000
POSIX, was: Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 15:58 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-31 21:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 11:30 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-02 19:45 +0000
Re: Reading lines from a file, eliminating CR and LF Ike Naar <ike@iceland.freeshell.org> - 2017-01-02 19:56 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-02 21:09 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 11:01 +1300
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 12:45 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:09 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 15:07 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-04 09:13 +1300
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 11:53 +1300
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 15:40 -0800
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:16 +1300
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 00:01 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:21 +1300
Re: Reading lines from a file, eliminating CR and LF Ike Naar <ike@iceland.freeshell.org> - 2017-01-03 08:40 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 12:50 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:42 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 15:11 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 16:32 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 17:24 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 17:48 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 18:56 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 19:46 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 13:37 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-02 13:56 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 03:52 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 13:19 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 03:30 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 02:23 -0800
Re: Reading lines from a file, eliminating CR and LF mark.bluemel@gmail.com - 2017-01-04 02:56 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 07:06 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:21 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 03:01 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 11:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 04:04 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:23 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 12:26 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 13:38 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:25 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 12:21 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:52 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:13 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 07:54 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 07:59 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 08:12 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:15 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 09:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 08:28 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 10:45 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 09:02 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 19:49 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 13:28 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:14 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-06 00:50 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-06 06:11 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-06 16:33 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-06 12:14 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 02:15 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 03:32 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:57 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 01:51 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 02:09 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 04:09 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 22:05 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 03:43 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-08 21:36 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 04:33 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-09 21:44 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 23:54 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 02:04 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 11:28 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 04:25 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 14:14 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-10 14:52 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 07:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 00:11 -0800
Re: Reading lines from a file, eliminating CR and LF mark.bluemel@gmail.com - 2017-01-12 01:13 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 01:41 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 09:55 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 10:25 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-08 19:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 05:27 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2017-01-07 17:06 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 08:11 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:04 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 12:36 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-04 12:49 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 05:19 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:14 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:57 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-05 08:24 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:58 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 13:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 03:37 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 02:46 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 11:25 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 02:43 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 22:45 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 10:17 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 00:42 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 00:51 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 11:25 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-28 20:57 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 23:16 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 14:38 -0800
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-06 06:11 -0800 |
| Message-ID | <401c510b-cfe5-4c91-a348-c2f290d96a91@googlegroups.com> |
| In reply to | #101210 |
On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
> Let's move on to number 3...
>
Please, take a look at exercise 3.
(1) this is a "shortened" version, in which I do not print
incorrect input at each incorrect line; I have a longer
version with all that messaging; but for now the code
without additional messages looks clearer to work with;
(2) I have added a function valid_input, and this function
returns a pointer, which I then use in the program; I am
worried about assigning the value NULL to the pointer
in case I don't get a valid input, because I have to repeat !=NULL
twice in the while loop (please, see the code for clarity);
I have not yet found a better value to assign to this pointer
in case of invalid input;
(3) Note to Barry: I have not yet worked with error messages
nuances we have discussed. Please, excuse me, I will get
to that.
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#include <errno.h>
#define BUFFER_SIZE 100
#define TEXT "../files/ex_1.csv"
bool get_numbers(FILE *input_file, double *sum, size_t *index_n);
char *valid_input(char *buffer);
int main(int argc, char *argv[])
{
//Check for correct number of arguments
if(argc > 2)
{
fputs("Sorry, the program processes only one file.\n", stderr);
return EXIT_FAILURE;
}
//Determine a file to use
const char *data_file = (argc == 2)? argv[1] : TEXT;
errno = 0;
FILE *fp = fopen(data_file, "r");
//Couldn't open the file
if ( !fp )
{
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
return EXIT_FAILURE;
}
double sum = 0;
size_t index_n = 0;
double average_num;
if( !get_numbers(fp, &sum, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Compute average only if index_n > 0
if(index_n == 0)
{
fprintf(stderr, "No input to process\n");
fclose(fp);
return EXIT_FAILURE;
}
average_num = sum/index_n;
printf("%.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
/** Function to read and process numbers
from the file line by line
**/
bool get_numbers (FILE *input_file, double *sum, size_t *index_n)
{
char buffer[BUFFER_SIZE] = "";
size_t line = 0;
//Parse file data, store only numbers
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
char *not_converted = NULL;
char *ptr = NULL;
double difference = 0;
double number = strtod(buffer, ¬_converted);
/* Process lines that contain only 2 numbers,
commas and spaces */
if ( not_converted > buffer)
{
if( (ptr = valid_input(not_converted)) != NULL
&& *ptr == ',')
{
ptr++;
difference = number - strtod(ptr, ¬_converted);
if( not_converted > ptr &&
(ptr = valid_input(not_converted)) != NULL &&
*ptr == '\0')
{
*sum += difference;
(*index_n)++;
}
}
}
line++;
}
if (ferror(input_file))
{
if(*index_n != 0)
fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
fprintf(stderr, "The function detected an error in reading a file; no data has been processed");
return false;
}
return true;
}
/** Function to determine valid input **/
char *valid_input(char *buffer)
{
char *ptr = NULL;
while(isspace(*buffer))
buffer++;
return ptr = (*buffer == ',' || *buffer == '\0')? buffer : NULL;
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-06 16:33 +0000 |
| Message-ID | <87eg0ggnbu.fsf@bsb.me.uk> |
| In reply to | #101215 |
Alla _ <modelling.data@gmail.com> writes:
> On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
> <snip>
>> Let's move on to number 3...
>>
> Please, take a look at exercise 3.
Well done! I think this is correct. It took me a little while longer
than perhaps if should for me to be sure it was correct, so I think a
little tidying-up would help. In particular, you are doing some rather
odd duplicate testing for commas and null.
> (1) this is a "shortened" version, in which I do not print
> incorrect input at each incorrect line; I have a longer
> version with all that messaging; but for now the code
> without additional messages looks clearer to work with;
I think that's a very good idea. It focuses on the main part of this
exercise.
> (2) I have added a function valid_input, and this function
> returns a pointer, which I then use in the program; I am
> worried about assigning the value NULL to the pointer
> in case I don't get a valid input, because I have to repeat !=NULL
> twice in the while loop (please, see the code for clarity);
> I have not yet found a better value to assign to this pointer
> in case of invalid input;
You are right be worried. Using null complicates matter more than
necessary. I'll make a suggestion about that below in my comments about
the code.
Also, "valid_input" is a terrible name. The trouble is that what the
function is rather fussy -- skip spaces and return a pointer to a comma
or a null if one was found, other wise return NULL. There's not very
good name for that rather specific function, but "valid_input" gives no
help about it at all.
When you find it hard to name a function, consider that a big hint that
make the function it not quite right. The valid_input is doing too much
ta have simple explanatory name, yet it's only three lines long.
(You've used four, but that's because of an unneeded local variable
called ptr.)
<snip>
This time, since you are moving faster now, I'm going to comment on
things that don't really pertain to the exercise, but which bother me a
bit. Please don't worry about the large number of them.
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
> #include <string.h>
> #include <stdbool.h>
> #include <errno.h>
>
> #define BUFFER_SIZE 100
> #define TEXT "../files/ex_1.csv"
I'd try to think of a better name.
> bool get_numbers(FILE *input_file, double *sum, size_t *index_n);
> char *valid_input(char *buffer);
>
> int main(int argc, char *argv[])
> {
> //Check for correct number of arguments
> if(argc > 2)
> {
> fputs("Sorry, the program processes only one file.\n", stderr);
> return EXIT_FAILURE;
> }
> //Determine a file to use
> const char *data_file = (argc == 2)? argv[1] : TEXT;
> errno = 0;
> FILE *fp = fopen(data_file, "r");
> //Couldn't open the file
This should either be a question ("Couldn't open the file?") of the
comment belongs in the block below the if.
> if ( !fp )
In other places you test for not NULL using != NULL but here you just
write !fp. Personally, I have no problem with the sort form but, as you
might have seen in a recent thread, there are a wide range of opinions
about this. Whatever you do, pick one and stick with it, at in any one
program. It's fine to try out different styles in different programs.
> {
> fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
> return EXIT_FAILURE;
> }
>
> double sum = 0;
> size_t index_n = 0;
> double average_num;
No initialisation? I'm not sure what style you are using here. You
sometimes initialise when it's not needed for correctness but not here,
though the issue will vanish if you take my next suggestion.
> if( !get_numbers(fp, &sum, &index_n) )
> {
> fclose(fp);
> return EXIT_FAILURE;
> }
> //Compute average only if index_n > 0
> if(index_n == 0)
> {
> fprintf(stderr, "No input to process\n");
> fclose(fp);
> return EXIT_FAILURE;
> }
> average_num = sum/index_n;
Why not declare average_num here? If you are happy to mix declarations
and statements (as C99 permits) then it's a good idea to put the
declaration as close to the first use as you can. I.e. be consistent.
> printf("%.2f\n", average_num);
Or, frankly, just print sum/index_n here.
> fclose(fp);
> return EXIT_SUCCESS;
> }
I like a blank line (or two even) between functions.
> /** Function to read and process numbers
> from the file line by line
> **/
> bool get_numbers (FILE *input_file, double *sum, size_t *index_n)
> {
> char buffer[BUFFER_SIZE] = "";
> size_t line = 0;
Do you really want the first line to be reported as line zero?
> //Parse file data, store only numbers
> while( fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
> char *not_converted = NULL;
> char *ptr = NULL;
> double difference = 0;
> double number = strtod(buffer, ¬_converted);
>
> /* Process lines that contain only 2 numbers,
> commas and spaces */
> if ( not_converted > buffer)
> {
You could declare ptr here and then the initial value could be the one
you really want it to have! What's more, the if then becomes simpler.
> if( (ptr = valid_input(not_converted)) != NULL
> && *ptr == ',')
> {
> ptr++;
> difference = number - strtod(ptr, ¬_converted);
And difference can be declared here.
> if( not_converted > ptr &&
> (ptr = valid_input(not_converted)) != NULL &&
> *ptr == '\0')
> {
> *sum += difference;
> (*index_n)++;
> }
> }
> }
> line++;
Ah, I see you've spotted this. I saw in a previous version that line
was incremented only on success, but you need to could all lines
including invalid ones so this is the right place for the increment.
> }
> if (ferror(input_file))
> {
> if(*index_n != 0)
> fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
> fprintf(stderr, "The function detected an error in reading a
> file; no data has been processed");
That's a lot of error reporting for a situation that you will almost
never see, and I don't think "The function detected an error" is very
helpful way to phrase it. I'd go with something snappy like "IO error
after line %zu.\n";
> return false;
> }
> return true;
> }
>
> /** Function to determine valid input **/
> char *valid_input(char *buffer)
> {
> char *ptr = NULL;
This variable serves no purpose.
> while(isspace(*buffer))
> buffer++;
> return ptr = (*buffer == ',' || *buffer == '\0')? buffer : NULL;
> }
Now for my hint. Don't look down if you don't want to see it yet...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
You can avoid the hassle of returning (and therefore test for) NULL
simply by making this a "skip_space" function that returns a pointer to
the first character that follows a run of isspace characters. Try that
out and see how that makes the main function look.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-06 12:14 -0800 |
| Message-ID | <c6380df2-99aa-4f37-a036-f13bc5eaf9d3@googlegroups.com> |
| In reply to | #101219 |
On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> > > <snip> > >> Let's move on to number 3... > >> > > Please, take a look at exercise 3. > > Well done! I think this is correct. I have not yet read the whole comment, but I hope you will forgive me for jumping in with my response - I am shocked to see these words ) Truly. Though I guess more ones of a more usual nature are to come below ) <snip>
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-07 02:15 -0800 |
| Message-ID | <1ba04525-7641-4dd0-9a7b-f23977ab7345@googlegroups.com> |
| In reply to | #101219 |
On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> > <snip>
> ><snip>
> <snip>
>
> This time, since you are moving faster now, I'm going to comment on
> things that don't really pertain to the exercise, but which bother me a
> bit. Please don't worry about the large number of them.
>
I have been sort of moving faster because I had a great chance
to be in a much better atmosphere and even had enough
sleep for the last three days - an exception case during the last
almost 3 years. Today I am back into a largely stressful
atmosphere, but anyway I do hope that what we have reached
thus far will only get better, independently of outer circumstances.
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <ctype.h>
> > #include <string.h>
> > #include <stdbool.h>
> > #include <errno.h>
> >
> > #define BUFFER_SIZE 100
> > #define TEXT "../files/ex_1.csv"
>
> I'd try to think of a better name.
>
Are you referring to the TEXT? If so,
then I'd suggest INPUT.
Or are you referring to the function name? If so, what
do you think about:
process_input
get_file_data
> > bool get_numbers(FILE *input_file, double *sum, size_t *index_n);
> > char *valid_input(char *buffer);
> >
> > int main(int argc, char *argv[])
> > {
> > //Check for correct number of arguments
> > if(argc > 2)
> > {
> > fputs("Sorry, the program processes only one file.\n", stderr);
> > return EXIT_FAILURE;
> > }
> > //Determine a file to use
> > const char *data_file = (argc == 2)? argv[1] : TEXT;
> > errno = 0;
> > FILE *fp = fopen(data_file, "r");
> > //Couldn't open the file
>
> This should either be a question ("Couldn't open the file?") of the
> comment belongs in the block below the if.
>
> > if ( !fp )
>
> In other places you test for not NULL using != NULL but here you just
> write !fp. Personally, I have no problem with the sort form but, as you
> might have seen in a recent thread, there are a wide range of opinions
> about this. Whatever you do, pick one and stick with it, at in any one
> program. It's fine to try out different styles in different programs.
I prefer this shortcut version. In this program there are only 2 places
where I use !=NULL and those are the ones I wanted to highlight
also with this longer form because these places have to be corrected,
as you have confirmed. Also !ptr doesn't work. Anyway, this has to
be done differently.
is
>
> > {
> > fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
> > return EXIT_FAILURE;
> > }
> >
> > double sum = 0;
> > size_t index_n = 0;
> > double average_num;
>
> No initialisation? I'm not sure what style you are using here. You
> sometimes initialise when it's not needed for correctness but not here,
> though the issue will vanish if you take my next suggestion.
>
> > if( !get_numbers(fp, &sum, &index_n) )
> > {
> > fclose(fp);
> > return EXIT_FAILURE;
> > }
> > //Compute average only if index_n > 0
> > if(index_n == 0)
> > {
> > fprintf(stderr, "No input to process\n");
> > fclose(fp);
> > return EXIT_FAILURE;
> > }
> > average_num = sum/index_n;
>
> Why not declare average_num here? If you are happy to mix declarations
> and statements (as C99 permits) then it's a good idea to put the
> declaration as close to the first use as you can. I.e. be consistent.
>
Agree. You have mentioned this elsewhere, and I have corrected it
there, but have missed this part. Done.
> > printf("%.2f\n", average_num);
>
> Or, frankly, just print sum/index_n here.
>
Yes, as an option. I know you prefer this style, and I agree
that it is more concise. I use it sometimes, but it is far too
early to talk about any of my preferences )
> > fclose(fp);
> > return EXIT_SUCCESS;
> > }
>
> I like a blank line (or two even) between functions.
Yes yes, I do too, but people here often complain when
too much of vertical space is occupied, so sometimes
I delete additional blanks, which I would normally have.
>
> > /** Function to read and process numbers
> > from the file line by line
> > **/
> > bool get_numbers (FILE *input_file, double *sum, size_t *index_n)
> > {
> > char buffer[BUFFER_SIZE] = "";
> > size_t line = 0;
>
> Do you really want the first line to be reported as line zero?
>
> > //Parse file data, store only numbers
> > while( fgets(buffer, sizeof(buffer), input_file) != NULL)
> > {
> > char *not_converted = NULL;
> > char *ptr = NULL;
> > double difference = 0;
> > double number = strtod(buffer, ¬_converted);
> >
> > /* Process lines that contain only 2 numbers,
> > commas and spaces */
> > if ( not_converted > buffer)
> > {
>
> You could declare ptr here and then the initial value could be the one
> you really want it to have! What's more, the if then becomes simpler.
Yes, I thought about it, but decided to show the way I did because
I still believed it has to be corrected.
>
> > if( (ptr = valid_input(not_converted)) != NULL
> > && *ptr == ',')
> > {
> > ptr++;
> > difference = number - strtod(ptr, ¬_converted);
>
> And difference can be declared here.
Yes )
>
> > if( not_converted > ptr &&
> > (ptr = valid_input(not_converted)) != NULL &&
> > *ptr == '\0')
> > {
> > *sum += difference;
> > (*index_n)++;
> > }
> > }
> > }
> > line++;
>
> Ah, I see you've spotted this. I saw in a previous version that line
> was incremented only on success, but you need to could all lines
> including invalid ones so this is the right place for the increment.
No, in all versions I did increment the line in all cases, because
I have reported the number of the line with an incorrect input,
not only the ones with successful input. Here I followed one of the advices
I got - to report the lines' numbers starting from 1 as it is close to
human convention.
>
> > }
> > if (ferror(input_file))
> > {
> > if(*index_n != 0)
> > fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
> > fprintf(stderr, "The function detected an error in reading a
> > file; no data has been processed");
>
> That's a lot of error reporting for a situation that you will almost
> never see, and I don't think "The function detected an error" is very
> helpful way to phrase it. I'd go with something snappy like "IO error
> after line %zu.\n";
I see. I have decided to leave the first error message as well, because
I think it can be helpful to see what was the last line successfully processed,
if any, in case i/o error occurs. I have corrected the second error message.
>
> > return false;
> > }
> > return true;
> > }
> >
> > /** Function to determine valid input **/
> > char *valid_input(char *buffer)
> > {
> > char *ptr = NULL;
>
> This variable serves no purpose.
>
> > while(isspace(*buffer))
> > buffer++;
> > return ptr = (*buffer == ',' || *buffer == '\0')? buffer : NULL;
> > }
>
> Now for my hint. Don't look down if you don't want to see it yet...
I have not yet looked at your hint (oh, and I have not yet deciphered
your previous ROT 13 one, as well :) ), but I have changed something
and now I think the result is much better. What do you think?
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#include <errno.h>
#define BUFFER_SIZE 100
#define TEXT "../files/ex_1.csv"
bool get_numbers(FILE *input_file, double *sum, size_t *index_n);
char *skip_spaces(char *buffer);
int main(int argc, char *argv[])
{
//Check for correct number of arguments
if(argc > 2)
{
fputs("Sorry, the program processes only one file.\n", stderr);
return EXIT_FAILURE;
}
//Determine a file to use
const char *data_file = (argc == 2)? argv[1] : TEXT;
errno = 0;
FILE *fp = fopen(data_file, "r");
//Couldn't open the file?
if ( !fp )
{
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
return EXIT_FAILURE;
}
double sum = 0;
size_t index_n = 0;
if( !get_numbers(fp, &sum, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Compute average only if index_n > 0
if(index_n == 0)
{
fprintf(stderr, "No input to process: the file is empty, or no valid data in the file.\n");
fclose(fp);
return EXIT_FAILURE;
}
double average_num = sum/index_n;
printf("%.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
/** Function to read and process numbers
from the file line by line
**/
bool get_numbers (FILE *input_file, double *sum, size_t *index_n)
{
char buffer[BUFFER_SIZE] = "";
size_t line = 0;
//Parse file data, store only numbers
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
char *not_converted = NULL;
double number = strtod(buffer, ¬_converted);
/* Process lines that contain only 2 numbers,
commas and spaces */
if ( not_converted > buffer)
{
char *ptr = skip_spaces(not_converted);
if( *ptr == ',')
{
ptr++;
double difference = number - strtod(ptr, ¬_converted);
if( not_converted > ptr)
{
ptr = skip_spaces(not_converted);
if( *ptr == '\0')
{
*sum += difference;
(*index_n)++;
}
}
}
}
line++;
}
if (ferror(input_file))
{
if(*index_n != 0)
fprintf(stderr, "Error: last input processed at line '%zu': %s\n", line, buffer);
fprintf(stderr, "IO error after line %zu.\n", line);
return false;
}
return true;
}
/** Function to skip spaces in the input **/
char *skip_spaces(char *buffer)
{
while(isspace(*buffer))
buffer++;
return buffer;
}
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> You can avoid the hassle of returning (and therefore test for) NULL
> simply by making this a "skip_space" function that returns a pointer to
> the first character that follows a run of isspace characters. Try that
> out and see how that makes the main function look.
>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-07 21:51 +0000 |
| Message-ID | <87shouo7xm.fsf@bsb.me.uk> |
| In reply to | #101226 |
Alla _ <modelling.data@gmail.com> writes:
> On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote:
>> >> Alla _ <modelling.data@gmail.com> writes:
>> >>
>> > <snip>
>> ><snip>
>> <snip>
>>
>> This time, since you are moving faster now, I'm going to comment on
>> things that don't really pertain to the exercise, but which bother me a
>> bit. Please don't worry about the large number of them.
>>
> I have been sort of moving faster because I had a great chance
> to be in a much better atmosphere and even had enough
> sleep for the last three days - an exception case during the last
> almost 3 years. Today I am back into a largely stressful
> atmosphere, but anyway I do hope that what we have reached
> thus far will only get better, independently of outer circumstances.
>> > #include <stdio.h>
>> > #include <stdlib.h>
>> > #include <ctype.h>
>> > #include <string.h>
>> > #include <stdbool.h>
>> > #include <errno.h>
>> >
>> > #define BUFFER_SIZE 100
>> > #define TEXT "../files/ex_1.csv"
>>
>> I'd try to think of a better name.
>>
> Are you referring to the TEXT? If so,
Yes, I usually put comments after the text I'm commenting on.
> then I'd suggest INPUT.
But it is not the INPUT to the program. It is not even the name of the
input to the program. I would call it DEFAULT_INPUT_FILE_NAME (or maybe
DEFAULT_FILE_NAME since the program is all about input).
<snip>
>> > bool get_numbers(FILE *input_file, double *sum, size_t *index_n);
>> > char *valid_input(char *buffer);
>> >
>> > int main(int argc, char *argv[])
>> > {
>> > //Check for correct number of arguments
>> > if(argc > 2)
>> > {
>> > fputs("Sorry, the program processes only one file.\n", stderr);
>> > return EXIT_FAILURE;
>> > }
>> > //Determine a file to use
>> > const char *data_file = (argc == 2)? argv[1] : TEXT;
>> > errno = 0;
>> > FILE *fp = fopen(data_file, "r");
>> > //Couldn't open the file
>>
>> This should either be a question ("Couldn't open the file?") of the
>> comment belongs in the block below the if.
>>
>> > if ( !fp )
>>
>> In other places you test for not NULL using != NULL but here you just
>> write !fp. Personally, I have no problem with the sort form but, as you
>> might have seen in a recent thread, there are a wide range of opinions
>> about this. Whatever you do, pick one and stick with it, at in any one
>> program. It's fine to try out different styles in different programs.
> I prefer this shortcut version. In this program there are only 2 places
> where I use !=NULL and those are the ones I wanted to highlight
OK, I agree that, there are sometimes reasons to emphasise the test. I
don't really get why that's the case here, but I don't want to make a
big issue of it.
> also with this longer form because these places have to be corrected,
> as you have confirmed. Also !ptr doesn't work. Anyway, this has to
> be done differently.
I don't understand this bit but since all the tests have gone in the new
version, it's probably not worth pursuing.
<snip>
>> I like a blank line (or two even) between functions.
> Yes yes, I do too, but people here often complain when
> too much of vertical space is occupied, so sometimes
> I delete additional blanks, which I would normally have.
I don't think anyone has objected to blank lines between functions. I
think there is a problem when a function's body takes up too many lines
but that's another matter altogether and the biggest culprit there is
putting {s on a line by themselves! (I do that at the opening of a
function but not elsewhere.)
<snip>
>> Now for my hint. Don't look down if you don't want to see it yet...
> I have not yet looked at your hint (oh, and I have not yet deciphered
> your previous ROT 13 one, as well :) ), but I have changed something
> and now I think the result is much better. What do you think?
Yes, that (as you have subsequently found out) was exactly what I was
suggesting.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-07 03:32 -0800 |
| Message-ID | <1ad79cea-958c-4236-a306-45c08f62c699@googlegroups.com> |
| In reply to | #101219 |
On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > <snip> > . > . > You can avoid the hassle of returning (and therefore test for) NULL > simply by making this a "skip_space" function that returns a pointer to > the first character that follows a run of isspace characters. Try that > out and see how that makes the main function look. While waiting for your reply, I have finally decided to look at the hint. I don't want to allow myself to jump around in a surge of happiness, but that is exactly what I came up with - without looking at the hint ) Oh, please, let it be a sign of improvement. I know that it doesn't say much, but I do live myself a chance; I truly want to improve my knowledge and skill. Ben, I can't find enough words to express my gratitude for your help, your patience, and your truly perfect guidance - you don't solve things for me, but you help me think and find the way myself thus increasing chances of getting better at this thinking process. Of course, it would be much easier for you to just come up with a solution and a code, but you patiently wait to see how I fare based on your comments. Thank you!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-07 21:57 +0000 |
| Message-ID | <87mvf2o7n2.fsf@bsb.me.uk> |
| In reply to | #101227 |
Alla _ <modelling.data@gmail.com> writes: > On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> > <snip> >> . >> . >> You can avoid the hassle of returning (and therefore test for) NULL >> simply by making this a "skip_space" function that returns a pointer to >> the first character that follows a run of isspace characters. Try that >> out and see how that makes the main function look. > While waiting for your reply, I have finally decided to look at the hint. > I don't want to allow myself to jump around in a surge of happiness, but > that is exactly what I came up with - without looking at the hint ) Oh, please, > let it be a sign of improvement. I know that it doesn't say much, but I do > live myself a chance; I truly want to improve my knowledge and skill. Of course it is a sign of improvement! Like any skill, programming takes time to learn -- lots of time. While there is no substitute for writing code, don't underestimate the value of reading other people's programs. I've learned countless things from people whose names I know longer recall simply because I read their code. > Ben, I can't find enough words to express my gratitude for your help, > your patience, and your truly perfect guidance - you don't solve things > for me, but you help me think and find the way myself thus increasing > chances of getting better at this thinking process. Of course, it would be > much easier for you to just come up with a solution and a code, but you > patiently wait to see how I fare based on your comments. Thank you! That's very gratifying to hear. Thank you. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-08 01:51 -0800 |
| Message-ID | <b2c15898-c9b2-417c-8dfa-506892e99582@googlegroups.com> |
| In reply to | #101258 |
On Sunday, January 8, 2017 at 12:57:44 AM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> > > <snip> > >> . > >> . > >> You can avoid the hassle of returning (and therefore test for) NULL > >> simply by making this a "skip_space" function that returns a pointer to > >> the first character that follows a run of isspace characters. Try that > >> out and see how that makes the main function look. > > While waiting for your reply, I have finally decided to look at the hint. > > I don't want to allow myself to jump around in a surge of happiness, but > > that is exactly what I came up with - without looking at the hint ) Oh, please, > > let it be a sign of improvement. I know that it doesn't say much, but I do > > live myself a chance; I truly want to improve my knowledge and skill. > > Of course it is a sign of improvement! Like any skill, programming > takes time to learn -- lots of time. While there is no substitute for > writing code, don't underestimate the value of reading other people's > programs. I've learned countless things from people whose names I know > longer recall simply because I read their code. Thank you very much. Yes, I understand it. I do appreciate seeing other people's code suggestions - a lot of those has already helped me and taught me a lot, as well; still the approach you suggested is truly the best way to teach people something, not only programming, - making a person think and try to find various solutions to a problem on his own, accompanied by great code examples from other people. > > > Ben, I can't find enough words to express my gratitude for your help, > > your patience, and your truly perfect guidance - you don't solve things > > for me, but you help me think and find the way myself thus increasing > > chances of getting better at this thinking process. Of course, it would be > > much easier for you to just come up with a solution and a code, but you > > patiently wait to see how I fare based on your comments. Thank you! > > That's very gratifying to hear. Thank you. > > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-08 02:09 -0800 |
| Message-ID | <9d6134b7-5e54-4a62-a628-76f63d4d2989@googlegroups.com> |
| In reply to | #101258 |
On Sunday, January 8, 2017 at 12:57:44 AM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> > > <snip> > >> . > >> . > >> You can avoid the hassle of returning (and therefore test for) NULL > >> simply by making this a "skip_space" function that returns a pointer to > >> the first character that follows a run of isspace characters. Try that > >> out and see how that makes the main function look. > > While waiting for your reply, I have finally decided to look at the hint. > > I don't want to allow myself to jump around in a surge of happiness, but > > that is exactly what I came up with - without looking at the hint ) Oh, please, > > let it be a sign of improvement. I know that it doesn't say much, but I do > > live myself a chance; I truly want to improve my knowledge and skill. > > Of course it is a sign of improvement! Like any skill, programming > takes time to learn -- lots of time. While there is no substitute for > writing code, don't underestimate the value of reading other people's > programs. I've learned countless things from people whose names I know > longer recall simply because I read their code. > What truly worries me now is that if I am left by myself, correct thinking habits, which has just started to emerge, can be easily overwhelmed by bad old entrenched thinking proclivities. To make sure those old ones are gone, I need to practice good ones more and more; then it will be much easier to grow further. > > Ben, I can't find enough words to express my gratitude for your help, > > your patience, and your truly perfect guidance - you don't solve things > > for me, but you help me think and find the way myself thus increasing > > chances of getting better at this thinking process. Of course, it would be > > much easier for you to just come up with a solution and a code, but you > > patiently wait to see how I fare based on your comments. Thank you! > > That's very gratifying to hear. Thank you. > > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-07 04:09 -0800 |
| Message-ID | <6cbe3b83-1181-40fa-b007-b9913f92ef3f@googlegroups.com> |
| In reply to | #101219 |
On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote: <snip> Looking again at exercise 3, I see that, indeed, I take from each line only values I care about, ignoring anything else. Interesting. If, upon looking at my final version of exercise 3, you say that it is all right, then I would like, if I may, to proceed to writing the program based on these exercises, but the one that I need for parsing the data from csv file of the form I show below (sorry for repeating it, I know many of you have seen it many times already): Years,2011,2012,2013,2014,2015 Sales,1062,1252,1587,1934,2519 Cost of Goods Sold,654,814,1009,1190,1499 Gross Profit,408,438,578,744,1020 "Selling, General, and Admin Exp",254,271,364,454,576 Operating Income before Depr,154,167,214,290,444 Depreciation and Amortization,25,31,38,52,70 Operating Profit,129,136,176,238,374 Interest Expense,4,3,3,1,4 Other Gains and Losses,0,7,10,0,-1 Pretax Income,125,126,163,237,371 Income Tax Expense,55,52,65,92,141 Net Income,70,74,98,145,230 Here is how I see the task - please, correct it if it's wrong: I have to read data from a file line by line, and process those lines in a way that allows me to parse valid names, which are row names, and valid numbers, and store those in two corresponding arrays. Valid names have the following form: <non-numerical characters> or <double quotation marks><non-numerical characters> <comma><non-numerical characters><double quotation marks>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-07 22:05 +0000 |
| Message-ID | <87h95ao7a3.fsf@bsb.me.uk> |
| In reply to | #101230 |
Alla _ <modelling.data@gmail.com> writes: > On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> >> > On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote: > <snip> > Looking again at exercise 3, I see that, indeed, I take from each line > only values I care about, ignoring anything else. Interesting. > > If, upon looking at my final version of exercise 3, you say that > it is all right, then I would like, if I may, to proceed to writing the program > based on these exercises, but the one that I need for parsing the > data from csv file of the form I show below OK. I liked your idea of averaging all the numbers on a line first, but if you want to take the plunge, have a go... > (sorry for repeating it, > I know many of you have seen it many times already): > Years,2011,2012,2013,2014,2015 > Sales,1062,1252,1587,1934,2519 > Cost of Goods Sold,654,814,1009,1190,1499 > Gross Profit,408,438,578,744,1020 > "Selling, General, and Admin Exp",254,271,364,454,576 > Operating Income before Depr,154,167,214,290,444 > Depreciation and Amortization,25,31,38,52,70 > Operating Profit,129,136,176,238,374 > Interest Expense,4,3,3,1,4 > Other Gains and Losses,0,7,10,0,-1 > Pretax Income,125,126,163,237,371 > Income Tax Expense,55,52,65,92,141 > Net Income,70,74,98,145,230 > > Here is how I see the task - please, correct it if it's wrong: > I have to read data from a file line by line, and process those > lines in a way that allows me to parse valid names, which are > row names, and valid numbers, and store those in two corresponding > arrays. I don't know because I did not understand the overall task. It would help me if you explain why you store the data. > Valid names have the following form: > <non-numerical characters> > or <double quotation marks><non-numerical characters> > <comma><non-numerical characters><double quotation marks> That seems a bit fussy. For example, I would allow "Sales" to be a valid name despite it having no comma. And do you care about the leading spaces on some lines? I.e. do you need to store <space><space>Net<space>Income? Finally, are you OK that you can't have a name with a double quote mark in it? (Remember it's fine to simplify!) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-08 03:43 -0800 |
| Message-ID | <ffeed204-1a54-46cd-a221-9f41c68ad816@googlegroups.com> |
| In reply to | #101259 |
On Sunday, January 8, 2017 at 1:05:31 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Friday, January 6, 2017 at 7:33:50 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> >> > On Friday, January 6, 2017 at 3:50:08 AM UTC+3, Ben Bacarisse wrote:
> > <snip>
> > Looking again at exercise 3, I see that, indeed, I take from each line
> > only values I care about, ignoring anything else. Interesting.
> >
> > If, upon looking at my final version of exercise 3, you say that
> > it is all right, then I would like, if I may, to proceed to writing the program
> > based on these exercises, but the one that I need for parsing the
> > data from csv file of the form I show below
>
> OK. I liked your idea of averaging all the numbers on a line first, but
> if you want to take the plunge, have a go...
>
I like that too. I would love to do more such exercises, they truly help;
and I would like to scale them up, as I have mentioned, to process
lines with unlimited amount of numbers. Also, apart from very
interesting exercises in K&R, I have a set of exercises suggested
by the course, but the ones I have skipped because those are hack
versions for those more comfortable with programming.
But first I do have to finish my project. I truly have to, and have very
serious reasons for that (sorry for not explaining all details).
> > (sorry for repeating it,
> > I know many of you have seen it many times already):
> > Years,2011,2012,2013,2014,2015
> > Sales,1062,1252,1587,1934,2519
> > Cost of Goods Sold,654,814,1009,1190,1499
> > Gross Profit,408,438,578,744,1020
> > "Selling, General, and Admin Exp",254,271,364,454,576
> > Operating Income before Depr,154,167,214,290,444
> > Depreciation and Amortization,25,31,38,52,70
> > Operating Profit,129,136,176,238,374
> > Interest Expense,4,3,3,1,4
> > Other Gains and Losses,0,7,10,0,-1
> > Pretax Income,125,126,163,237,371
> > Income Tax Expense,55,52,65,92,141
> > Net Income,70,74,98,145,230
> >
> > Here is how I see the task - please, correct it if it's wrong:
> > I have to read data from a file line by line, and process those
> > lines in a way that allows me to parse valid names, which are
> > row names, and valid numbers, and store those in two corresponding
> > arrays.
>
> I don't know because I did not understand the overall task. It would
> help me if you explain why you store the data.
>
I have decided now to break it into smaller parts, and then it might be
more clear.
Below are first two parts of the program. Both parts are a set of inter-
mingled functions.
First part: make sure that the provided file has the correct
input format:
(1) check if row names completely correspond to the required ones,
no more or less of those - for this I assume I need an array
of required row names, and when reading each line from the
file, make sure that line 1 row name equals the first name in
the array, etc.
For example:
array: Years, Sales, COGS
line1: Years,2011,2012,2013,2014,2015
line2: Sales,1062,1252,1587,1934,2519
line3: Cost of Goods Sold,654,814,1009,1190,1499
=> make sure that the name on the line1 corresponds
to the first name in the array, etc.
(2) check if there are exactly 5 years of numeric data,
and, sort of a complication to the task, make sure that those years
are 5 previous years ending at the current year (the program has to
determine the current year, compute what year would be 5 years back
from the current one, and check if the file contains data for exactly
these years - years should be provided in the first line of the file).
Now, given the preconditioned set of row names, I don't need
an additional array to store names from the file. At the very end,
when the program has done all required computation, I can
grab those preconditioned row names, and transfer them into
the program's output, which will be recorded in csv format
as well (maybe also in mysql table - would love to do that
also, but have not yet decided; it depends on how things
will go with the basic code).
Second part: compute forecasted sales:
(1) compute forecasted sales growth rate; for this take
the second file line, which contains the name
Sales, and compute the average (bingo!) growth rate
based on each year's rate =>
each year rate = ( amount of sales this year - amount of
sales previous year ) / amount of sales previous year
Store final sales average growth rate in the array named
averages (this will contain all average rates computed
based on each line's data - not included in this second
part of the task);
(2) prompt the user to input the projected industry
growth rate beyond 5 year period (for now I leave
it like this, though I wanted to make it more
complicated by searching the web for a correct rate;
I guess I will not consider doing this now, even though
I love to create complicated tasks);
(3) compute sales numbers for the next 5 years
using historical average from (1) =>
previous sales amount x rate
(4) compute sales numbers for 5 years beyond
based on the industry average found in (2)
Totally 10 forecasted years of sales, and these
numbers should be stored in an array.
Please, let me know what you think? If this is clear,
I would like to ask, if I may and if you can, to
correct me. Then I can sketch a pseudo code
for all these steps.
I am not at all sure if this is interesting to you.
Thank you!
> > Valid names have the following form:
> > <non-numerical characters>
> > or <double quotation marks><non-numerical characters>
> > <comma><non-numerical characters><double quotation marks>
>
> That seems a bit fussy. For example, I would allow "Sales" to be a
> valid name despite it having no comma. And do you care about the
> leading spaces on some lines? I.e. do you need to store
> <space><space>Net<space>Income? Finally, are you OK that you can't have
> a name with a double quote mark in it? (Remember it's fine to
> simplify!)
>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-08 21:36 +0000 |
| Message-ID | <87wpe5mdxw.fsf@bsb.me.uk> |
| In reply to | #101286 |
Alla _ <modelling.data@gmail.com> writes: > On Sunday, January 8, 2017 at 1:05:31 AM UTC+3, Ben Bacarisse wrote: <snip> >> OK. I liked your idea of averaging all the numbers on a line first, but >> if you want to take the plunge, have a go... >> > I like that too. I would love to do more such exercises, they truly help; <snip> > But first I do have to finish my project. I truly have to, and have very > serious reasons for that (sorry for not explaining all details). OK, press on. <snip> >> I don't know because I did not understand the overall task. It would >> help me if you explain why you store the data. >> > I have decided now to break it into smaller parts, and then it might be > more clear. > Below are first two parts of the program. Both parts are a set of inter- > mingled functions. > > First part: make sure that the provided file has the correct > input format: > (1) check if row names completely correspond to the required ones, > no more or less of those - for this I assume I need an array > of required row names, and when reading each line from the > file, make sure that line 1 row name equals the first name in > the array, etc. > For example: > array: Years, Sales, COGS > line1: Years,2011,2012,2013,2014,2015 > line2: Sales,1062,1252,1587,1934,2519 > line3: Cost of Goods Sold,654,814,1009,1190,1499 > => make sure that the name on the line1 corresponds > to the first name in the array, etc. That's a very strict format, but it's your program. In general I would not separate checking from computing. You just make more work that way. If you can't check as you go, then you might as well just read the data into a 2D array as you check. Then it's there ready for the computation phase. > (2) check if there are exactly 5 years of numeric data, > and, sort of a complication to the task, make sure that those years > are 5 previous years ending at the current year (the program has to > determine the current year, compute what year would be 5 years back > from the current one, and check if the file contains data for exactly > these years - years should be provided in the first line of the file). (1) and (2) are not separate steps. You are going to do the number checking as you do the name checking. > Now, given the preconditioned set of row names, I don't need > an additional array to store names from the file. At the very end, > when the program has done all required computation, I can > grab those preconditioned row names, and transfer them into > the program's output, which will be recorded in csv format > as well (maybe also in mysql table - would love to do that > also, but have not yet decided; it depends on how things > will go with the basic code). > > Second part: compute forecasted sales: > (1) compute forecasted sales growth rate; for this take > the second file line, which contains the name > Sales, and compute the average (bingo!) growth rate > based on each year's rate => > each year rate = ( amount of sales this year - amount of > sales previous year ) / amount of sales previous year > Store final sales average growth rate in the array named > averages (this will contain all average rates computed > based on each line's data - not included in this second > part of the task); Why is this stored in an array? > (2) prompt the user to input the projected industry > growth rate beyond 5 year period (for now I leave > it like this, though I wanted to make it more > complicated by searching the web for a correct rate; > I guess I will not consider doing this now, even though > I love to create complicated tasks); > (3) compute sales numbers for the next 5 years > using historical average from (1) => > previous sales amount x rate I this really the right way to do it? If you have a financial background I will simply accept your answer, but it's not the way a scientist would make a forecast from this sort of data. > (4) compute sales numbers for 5 years beyond > based on the industry average found in (2) > Totally 10 forecasted years of sales, and these > numbers should be stored in an array. Why are they being stored. I must be missing something here -- what do you do with the results of all these calculations? It's here that I'd say this calculation is repeated for each line in the file. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-09 04:33 -0800 |
| Message-ID | <47f51247-cb89-4283-9411-df05b12d6782@googlegroups.com> |
| In reply to | #101312 |
On Monday, January 9, 2017 at 12:36:51 AM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > <snip> > <snip> > >> I don't know because I did not understand the overall task. It would > >> help me if you explain why you store the data. > >> > > I have decided now to break it into smaller parts, and then it might be > > more clear. > > Below are first two parts of the program. Both parts are a set of inter- > > mingled functions. > > > > First part: make sure that the provided file has the correct > > input format: > > (1) check if row names completely correspond to the required ones, > > no more or less of those - for this I assume I need an array > > of required row names, and when reading each line from the > > file, make sure that line 1 row name equals the first name in > > the array, etc. > > For example: > > array: Years, Sales, COGS > > line1: Years,2011,2012,2013,2014,2015 > > line2: Sales,1062,1252,1587,1934,2519 > > line3: Cost of Goods Sold,654,814,1009,1190,1499 > > => make sure that the name on the line1 corresponds > > to the first name in the array, etc. > > That's a very strict format, but it's your program. Yes, it is. I have decided to do so in order to simplify. It will be much easier to add more flexibility once I have a more rigid program, as the one we did in exercises. It is an exercises, anyway, and not some truly viable generally useful application. But, yes, I can extend it much later on. > > In general I would not separate checking from computing. Yes, me too - based on exercises we did, I would like to follow that pattern, and thus to practice and develop those skills further. > You just make > more work that way. If you can't check as you go, then you might as > well just read the data into a 2D array as you check. Then it's there > ready for the computation phase. That's what I have started from, but you showed me another much better way, which might be more efficient. As you can see, I have even changed at listed one thing - I am not planning to store row names anymore, I don't need them to make the computation; the only thing I have to do is to check if the input contains correct names in each row to make sure I get correct corresponding numbers. > > > (2) check if there are exactly 5 years of numeric data, > > and, sort of a complication to the task, make sure that those years > > are 5 previous years ending at the current year (the program has to > > determine the current year, compute what year would be 5 years back > > from the current one, and check if the file contains data for exactly > > these years - years should be provided in the first line of the file). > > (1) and (2) are not separate steps. You are going to do the number > checking as you do the name checking. Yes, I have separated them in the text, but these are part of the first step ) I hope to be able to find the way to do so, again based on what I have learned thanks to your great help. > > > Now, given the preconditioned set of row names, I don't need > > an additional array to store names from the file. At the very end, > > when the program has done all required computation, I can > > grab those preconditioned row names, and transfer them into > > the program's output, which will be recorded in csv format > > as well (maybe also in mysql table - would love to do that > > also, but have not yet decided; it depends on how things > > will go with the basic code). > > > > Second part: compute forecasted sales: > > (1) compute forecasted sales growth rate; for this take > > the second file line, which contains the name > > Sales, and compute the average (bingo!) growth rate > > based on each year's rate => > > each year rate = ( amount of sales this year - amount of > > sales previous year ) / amount of sales previous year > > Store final sales average growth rate in the array named > > averages (this will contain all average rates computed > > based on each line's data - not included in this second > > part of the task); > > Why is this stored in an array? Because I need the array of all averages: sales average rate will be the first element in this array, which will be filled with other subsequent rates; these rates will be used in future computations. > > > (2) prompt the user to input the projected industry > > growth rate beyond 5 year period (for now I leave > > it like this, though I wanted to make it more > > complicated by searching the web for a correct rate; > > I guess I will not consider doing this now, even though > > I love to create complicated tasks); > > (3) compute sales numbers for the next 5 years > > using historical average from (1) => > > previous sales amount x rate > > I this really the right way to do it? If you have a financial > background I will simply accept your answer, but it's not the way a > scientist would make a forecast from this sort of data. Yes, please, accept this approach (and, yes, I have a financial background, a bit more than just background :) ). As I have mentioned a few times, the goal of this program is not to make a viable rigorously correct financial program (we all have excel for that, and lots of other professional software), but to practice programming in C; therefore I simplify everything. It's my C project, not financial project ))) But, anyway, please, do me a favor and explain how you see, as you named it, a "scientific way" to do such forecasts. I will be grateful for this - I am always open to everything, because no matter how much one thinks he/she knows and how many years he/she has spent doing something, there is always, always. always a lot of room for improvement (no one is perfect, especially me), and you might know very interesting things I might not have considered in the past. So, please, share this with me, even though it is not a C topic. > > > (4) compute sales numbers for 5 years beyond > > based on the industry average found in (2) > > Totally 10 forecasted years of sales, and these > > numbers should be stored in an array. > > Why are they being stored. I must be missing something here -- what do > you do with the results of all these calculations? These forecasted sales numbers are used to project all other items on the income statement, as well as on the balance sheet. Therefore, I need that array to be able to compute all other data. > > It's here that I'd say this calculation is repeated for each line in the > file. > > <snip> > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-09 21:44 +0000 |
| Message-ID | <8760lnx60w.fsf@bsb.me.uk> |
| In reply to | #101335 |
Alla _ <modelling.data@gmail.com> writes: > On Monday, January 9, 2017 at 12:36:51 AM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> > <snip> >> <snip> >> >> I don't know because I did not understand the overall task. It would >> >> help me if you explain why you store the data. >> >> >> > I have decided now to break it into smaller parts, and then it might be >> > more clear. >> > Below are first two parts of the program. Both parts are a set of inter- >> > mingled functions. >> > >> > First part: make sure that the provided file has the correct >> > input format: >> > (1) check if row names completely correspond to the required ones, >> > no more or less of those - for this I assume I need an array >> > of required row names, and when reading each line from the >> > file, make sure that line 1 row name equals the first name in >> > the array, etc. >> > For example: >> > array: Years, Sales, COGS >> > line1: Years,2011,2012,2013,2014,2015 >> > line2: Sales,1062,1252,1587,1934,2519 >> > line3: Cost of Goods Sold,654,814,1009,1190,1499 >> > => make sure that the name on the line1 corresponds >> > to the first name in the array, etc. >> >> That's a very strict format, but it's your program. > Yes, it is. I have decided to do so in order to simplify. It probably makes it more complicated but since you have not yet fully specified what the program does, you may need this complication. > It will be much easier to add more flexibility once I have > a more rigid program, as the one we did in exercises. It is > an exercises, anyway, and not some truly viable generally useful > application. But, yes, I can extend it much later on. > >> In general I would not separate checking from computing. > Yes, me too - based on exercises we did, I would like to follow > that pattern, and thus to practice and develop those skills further. >> You just make >> more work that way. If you can't check as you go, then you might as >> well just read the data into a 2D array as you check. Then it's there >> ready for the computation phase. > That's what I have started from, but you showed me another much > better way, which might be more efficient. I don't understand. You seem to want to check the first and then compute some things. I am suggesting you don't do that -- that you check as you compute just as you have been in the exercises. <snip> >> > Now, given the preconditioned set of row names, I don't need >> > an additional array to store names from the file. At the very end, >> > when the program has done all required computation, I can >> > grab those preconditioned row names, and transfer them into >> > the program's output, which will be recorded in csv format >> > as well (maybe also in mysql table - would love to do that >> > also, but have not yet decided; it depends on how things >> > will go with the basic code). >> > >> > Second part: compute forecasted sales: >> > (1) compute forecasted sales growth rate; for this take >> > the second file line, which contains the name >> > Sales, and compute the average (bingo!) growth rate >> > based on each year's rate => >> > each year rate = ( amount of sales this year - amount of >> > sales previous year ) / amount of sales previous year >> > Store final sales average growth rate in the array named >> > averages (this will contain all average rates computed >> > based on each line's data - not included in this second >> > part of the task); >> >> Why is this stored in an array? > Because I need the array of all averages: sales average rate > will be the first element in this array, which will be filled > with other subsequent rates; these rates will be used in > future computations. If you don't tell me what your program is going to do I can't advise you! What are the future computations? >> > (2) prompt the user to input the projected industry >> > growth rate beyond 5 year period (for now I leave >> > it like this, though I wanted to make it more >> > complicated by searching the web for a correct rate; >> > I guess I will not consider doing this now, even though >> > I love to create complicated tasks); >> > (3) compute sales numbers for the next 5 years >> > using historical average from (1) => >> > previous sales amount x rate >> >> I this really the right way to do it? If you have a financial >> background I will simply accept your answer, but it's not the way a >> scientist would make a forecast from this sort of data. > Yes, please, accept this approach OK. <snip> > But, anyway, please, do me a favor and explain how you see, as you > named it, a "scientific way" to do such forecasts. It's a big topic but you try to find what the statistical packages call a model that fits the data. You might, for example, try a linear model for which you calculate the equation of a "best fit" line though the data. If that is not a good fit, you might try an exponential model from which you calculate a baseline and growth rate, again using some statistical measure of goodness of fit. <snip> >> > (4) compute sales numbers for 5 years beyond >> > based on the industry average found in (2) >> > Totally 10 forecasted years of sales, and these >> > numbers should be stored in an array. >> >> Why are they being stored. I must be missing something here -- what do >> you do with the results of all these calculations? > These forecasted sales numbers are used to project all other items on > the income statement, > as well as on the balance sheet. Therefore, I need that array to be able > to compute all other data. The only computations described so far involve only numbers on one line. I need to know what the program actually does if you'd like some advice on how to go about writing it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-09 23:54 -0800 |
| Message-ID | <af96103e-17ee-487f-8640-5499ccfc3c3e@googlegroups.com> |
| In reply to | #101351 |
On Tuesday, January 10, 2017 at 12:44:39 AM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Monday, January 9, 2017 at 12:36:51 AM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> > > <snip> > >> <snip> > >> >> I don't know because I did not understand the overall task. It would > >> >> help me if you explain why you store the data. > >> >> > >> > I have decided now to break it into smaller parts, and then it might be > >> > more clear. > >> > Below are first two parts of the program. Both parts are a set of inter- > >> > mingled functions. > >> > > >> > First part: make sure that the provided file has the correct > >> > input format: > >> > (1) check if row names completely correspond to the required ones, > >> > no more or less of those - for this I assume I need an array > >> > of required row names, and when reading each line from the > >> > file, make sure that line 1 row name equals the first name in > >> > the array, etc. > >> > For example: > >> > array: Years, Sales, COGS > >> > line1: Years,2011,2012,2013,2014,2015 > >> > line2: Sales,1062,1252,1587,1934,2519 > >> > line3: Cost of Goods Sold,654,814,1009,1190,1499 > >> > => make sure that the name on the line1 corresponds > >> > to the first name in the array, etc. > >> > >> That's a very strict format, but it's your program. > > Yes, it is. I have decided to do so in order to simplify. > > It probably makes it more complicated but since you have not yet fully > specified what the program does, you may need this complication. > > > It will be much easier to add more flexibility once I have > > a more rigid program, as the one we did in exercises. It is > > an exercises, anyway, and not some truly viable generally useful > > application. But, yes, I can extend it much later on. > > > >> In general I would not separate checking from computing. > > Yes, me too - based on exercises we did, I would like to follow > > that pattern, and thus to practice and develop those skills further. > >> You just make > >> more work that way. If you can't check as you go, then you might as > >> well just read the data into a 2D array as you check. Then it's there > >> ready for the computation phase. > > That's what I have started from, but you showed me another much > > better way, which might be more efficient. > > I don't understand. You seem to want to check the first and then > compute some things. I am suggesting you don't do that -- that you > check as you compute just as you have been in the exercises. > > <snip> > >> > Now, given the preconditioned set of row names, I don't need > >> > an additional array to store names from the file. At the very end, > >> > when the program has done all required computation, I can > >> > grab those preconditioned row names, and transfer them into > >> > the program's output, which will be recorded in csv format > >> > as well (maybe also in mysql table - would love to do that > >> > also, but have not yet decided; it depends on how things > >> > will go with the basic code). > >> > > >> > Second part: compute forecasted sales: > >> > (1) compute forecasted sales growth rate; for this take > >> > the second file line, which contains the name > >> > Sales, and compute the average (bingo!) growth rate > >> > based on each year's rate => > >> > each year rate = ( amount of sales this year - amount of > >> > sales previous year ) / amount of sales previous year > >> > Store final sales average growth rate in the array named > >> > averages (this will contain all average rates computed > >> > based on each line's data - not included in this second > >> > part of the task); > >> > >> Why is this stored in an array? > > Because I need the array of all averages: sales average rate > > will be the first element in this array, which will be filled > > with other subsequent rates; these rates will be used in > > future computations. > > If you don't tell me what your program is going to do I can't advise > you! What are the future computations? > > >> > (2) prompt the user to input the projected industry > >> > growth rate beyond 5 year period (for now I leave > >> > it like this, though I wanted to make it more > >> > complicated by searching the web for a correct rate; > >> > I guess I will not consider doing this now, even though > >> > I love to create complicated tasks); > >> > (3) compute sales numbers for the next 5 years > >> > using historical average from (1) => > >> > previous sales amount x rate > >> > >> I this really the right way to do it? If you have a financial > >> background I will simply accept your answer, but it's not the way a > >> scientist would make a forecast from this sort of data. > > Yes, please, accept this approach > > OK. > > <snip> > > But, anyway, please, do me a favor and explain how you see, as you > > named it, a "scientific way" to do such forecasts. > > It's a big topic but you try to find what the statistical packages call > a model that fits the data. You might, for example, try a linear model > for which you calculate the equation of a "best fit" line though the > data. If that is not a good fit, you might try an exponential model > from which you calculate a baseline and growth rate, again using some > statistical measure of goodness of fit. ah, I see. Yes, these are well known models. Thank you! > > <snip> > >> > (4) compute sales numbers for 5 years beyond > >> > based on the industry average found in (2) > >> > Totally 10 forecasted years of sales, and these > >> > numbers should be stored in an array. > >> > >> Why are they being stored. I must be missing something here -- what do > >> you do with the results of all these calculations? > > These forecasted sales numbers are used to project all other items on > > the income statement, > > as well as on the balance sheet. Therefore, I need that array to be able > > to compute all other data. > > The only computations described so far involve only numbers on one line. > I need to know what the program actually does if you'd like some advice > on how to go about writing it. Oh, I apologize - I thought you remember the whole idea; I have posted it some time ago with the pre-final table I am planning to compute. I will now describe it again - please, see as part of my previous message. And, of course, I would be very grateful to get your advice and guidance, if you truly have time for that - I assume this program doesn't sound interesting. > > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-10 02:04 -0800 |
| Message-ID | <4be411c3-15ab-42b6-ab6f-fade71baea65@googlegroups.com> |
| In reply to | #101351 |
On Tuesday, January 10, 2017 at 12:44:39 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
>
> The only computations described so far involve only numbers on one line.
> I need to know what the program actually does if you'd like some advice
> on how to go about writing it.
>
I am reposting my above message and
EDIT: extending it to show the whole picture. Also, one more time:
this is not a viable, comprehensive, commercially applicable financial
program to process financial data in a correct way using correct
mathematical models; I apply only some, trying to simplify as much
as possible, still maintaining the concept. The goal is not to make even
a slight attempt to trump excel and/or any other professional software,
which abound, but to *practice writing program in C*; the accent is on
C and programming using the basic concept of constructing the pro-forma
statements, and then using those to write a valuation model (small one, nothing
fancy like Black-Scholes ). Also for now I use arithmetic average where
possible, not even geometric one, although in reality I, as anyone else,
would never use arithmetic average for obvious reasons .
I can always extend this program further upon finishing, and add/change
features to make it more correct in terms of processing financial input.
But it is not the goal now.
First part: make sure that the provided file has the correct
input format:
(1) check if row names completely correspond to the required ones,
no more or less of those - for this I assume I need an array
of required row names, and when reading each line from the
file, make sure that line 1 row name equals the first name in
the array, etc.
For example:
array: Years, Sales, COGS
line1: Years,2011,2012,2013,2014,2015
line2: Sales,1062,1252,1587,1934,2519
line3: Cost of Goods Sold,654,814,1009,1190,1499
=> make sure that the name on the line1 corresponds
to the first name in the array, etc.
(2) check if there are exactly 5 years of numeric data,
and, sort of a complication to the task, make sure that those years
are 5 previous years ending at the current year (the program has to
determine the current year, compute what year would be 5 years back
from the current one, and check if the file contains data for exactly
these years - years should be provided in the first line of the file).
Now, given the preconditioned set of row names, I don't need
an additional array to store names from the file. At the very end,
when the program has done all required computation, I can
grab those preconditioned row names, and transfer them into
the program's output, which will be recorded in csv format
as well (maybe also in mysql table - would love to do that
also, but have not yet decided; it depends on how things
will go with the basic code).
Second part: compute forecasted sales:
(1) compute forecasted sales growth rate; for this take
the second file line, which contains the name
Sales, and compute the average (bingo!) growth rate
based on each year's rate =>
each year rate = ( amount of sales this year - amount of
sales previous year ) / amount of sales previous year
Store final sales average growth rate in the array named
Rates (this will contain all necessary rates computed
based on each line's data - not included in this second
part of the task);
(2) prompt the user to input the projected industry
growth rate beyond 5 year period (for now I leave
it like this, though I wanted to make it more
complicated by searching the web for a correct rate;
I guess I will not consider doing this now, even though
I love to create complicated tasks);
(3) compute sales numbers for the next 5 years
using historical average from (1) =>
previous sales amount x rate
(4) compute sales numbers for 5 years beyond
based on the industry average found in (2)
Totally 10 forecasted years of sales, and these
numbers should be stored in an array.
Third part: compute averages for each item of
the income statement (except depreciation and amortization,
tax, interest expense – these are computed a bit
differently):
I assume that all following steps have to be done as
I go; and for that I need to have an array of Sales
Numbers, which the program has read in the first-second
Parts.
(1) compute common-size income statement as
each year’s ratios to Sales;
For example:
line2: Sales,1062,1252,1587,1934,2519
line3: Cost of Goods Sold,654,814,1009,1190,1499
Common-size COGS will be:
654/1062=0.62, 814/1252=0.65, 1009/1587=0.64,
1190/1934=0.62, 1499/2519=0.60
Take average of all these, and put as a second
element in the array Rates, where the first one
is the average sales growth rate computed in the second
part above.
Do the same for each line (except those named above);
at the end the array Rates should contain all necessary
Rates. Note: three of those have to be computed
differently, and, as I understand it, whenever I hit
that certain line (example, Depreciation and Amortization)
I call a function that computes the rate I need, and then
put that rate into the cumulative array Rates.
At this point, summarizing, I should have two
Arrays:
1 – array with all historic Sales numbers for 5 years;
2 – array with forecasted Sales numbers for next 10 years
(separate array because this one will be part of the final
pro-forma statement written into new csv files at the end
of all computations)
3 – array with all necessary rates (array of assumptions).
Forth part: write pro-forma income statement:
- take each year’s sales number and multiply by
a corresponding rate;
For example, the average COGS rate computed
above is 0.62 => COGS for each next 10 years
will be Sales number for corresponding year x
by (1 + 0.62); same for each line.
Here is the partial example (3 years) of the final pro forma
in csv format:
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
Fifth part:
(1) compute Total assets for each year based
on Sales numbers;
(2) get (or compute based on the method above)
common-size balance sheet, using Total assets
for corresponding years;
(3) create a valuation model.
Let me describe details of the fifth part later -
it more or less repeats previous ones, with some
mathematical variations.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-10 11:28 +0000 |
| Message-ID | <87pojvupah.fsf@bsb.me.uk> |
| In reply to | #101373 |
Alla _ <modelling.data@gmail.com> writes: > On Tuesday, January 10, 2017 at 12:44:39 AM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> > <snip> >> >> The only computations described so far involve only numbers on one line. >> I need to know what the program actually does if you'd like some advice >> on how to go about writing it. >> > I am reposting my above message and > EDIT: extending it to show the whole picture. <snip> > Fifth part: > (1) compute Total assets for each year based > on Sales numbers; > (2) get (or compute based on the method above) > common-size balance sheet, using Total assets > for corresponding years; > (3) create a valuation model. > Let me describe details of the fifth part later - > it more or less repeats previous ones, with some > mathematical variations. This is not the whole picture, but never mind because I don't think I can advise you how to write this sort of program in C. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-10 04:25 -0800 |
| Message-ID | <0779ab2a-cb48-4593-9fa7-0edf7903d1a8@googlegroups.com> |
| In reply to | #101375 |
On Tuesday, January 10, 2017 at 2:29:01 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Tuesday, January 10, 2017 at 12:44:39 AM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> > > <snip> > >> > >> The only computations described so far involve only numbers on one line. > >> I need to know what the program actually does if you'd like some advice > >> on how to go about writing it. > >> > > I am reposting my above message and > > EDIT: extending it to show the whole picture. > <snip> > > Fifth part: > > (1) compute Total assets for each year based > > on Sales numbers; > > (2) get (or compute based on the method above) > > common-size balance sheet, using Total assets > > for corresponding years; > > (3) create a valuation model. > > Let me describe details of the fifth part later - > > it more or less repeats previous ones, with some > > mathematical variations. > > This is not the whole picture, but never mind because I don't think I > can advise you how to write this sort of program in C. I see. Thank you very much for your sincere answer. The only question, if I may, - will you be able to help with particular C issues when I post my code here, and help me to find a better way of writing the code?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-10 14:14 +0000 |
| Message-ID | <87eg0buhmf.fsf@bsb.me.uk> |
| In reply to | #101376 |
Alla _ <modelling.data@gmail.com> writes: > On Tuesday, January 10, 2017 at 2:29:01 PM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> >> > On Tuesday, January 10, 2017 at 12:44:39 AM UTC+3, Ben Bacarisse wrote: >> >> Alla _ <modelling.data@gmail.com> writes: >> >> >> > <snip> >> >> >> >> The only computations described so far involve only numbers on one line. >> >> I need to know what the program actually does if you'd like some advice >> >> on how to go about writing it. >> >> >> > I am reposting my above message and >> > EDIT: extending it to show the whole picture. >> <snip> >> > Fifth part: >> > (1) compute Total assets for each year based >> > on Sales numbers; >> > (2) get (or compute based on the method above) >> > common-size balance sheet, using Total assets >> > for corresponding years; >> > (3) create a valuation model. >> > Let me describe details of the fifth part later - >> > it more or less repeats previous ones, with some >> > mathematical variations. >> >> This is not the whole picture, but never mind because I don't think I >> can advise you how to write this sort of program in C. > I see. Thank you very much for your sincere answer. > The only question, if I may, - will you be able to help with particular > C issues when I post my code here, and help me to find a better > way of writing the code? Oh, sure. For one thing, once the program is written, I'll know what it's supposed to do. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web