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 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-10 14:52 +0000 |
| Message-ID | <o52sc3$gji$2@dont-email.me> |
| In reply to | #101383 |
On 10/01/17 14:14, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > <snip> >> 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. Not necessarily. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-10 07:02 -0800 |
| Message-ID | <25884318-a1a1-4f03-8cef-fb62182ad822@googlegroups.com> |
| In reply to | #101383 |
On Tuesday, January 10, 2017 at 5:14:38 PM UTC+3, Ben Bacarisse wrote: > 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. Thank you very much ) > > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-12 00:11 -0800 |
| Message-ID | <be4123d7-f8e8-422c-a732-d750686d7891@googlegroups.com> |
| In reply to | #101383 |
On Tuesday, January 10, 2017 at 5:14:38 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
I would like to ask for one clarification. My question is regarding using
pointers to characters in the exercise. I declare char *not_converted and
assign NULL to it, so it doesn't actually point anywhere at the beginning,
but not_converted has the size of 4 or 8 bytes (8 in my case). Then,
when I call strtod, the function assigns to not_converted the address of
the first character that was not converted.
But if to read a line from a file I use char *buffer (not a static array) and
do the following declaration:
char *buffer = NULL;
then call fgets (using the static size BUFFER_SIZE), then I will get a
segmentation fault because when I declared the pointer I didn't allocate
any memory, to which that pointer should point, where the program
could store all characters from the line. Therefore, to use a buffer pointer
I need first to allocate memory, and then call fgets.
Are all above assumptions correct?
Here is a program once again, but with a slight change introducing
buffer pointer.
#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 = malloc(BUFFER_SIZE);
size_t line = 0;
//Parse file data, store only numbers
while( fgets(buffer, BUFFER_SIZE, 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);
free(buffer);
return false;
}
free(buffer);
return true;
}
/** Function to skip spaces in the input **/
char *skip_spaces(char *buffer)
{
while(isspace(*buffer))
buffer++;
return buffer;
}
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2017-01-12 01:13 -0800 |
| Message-ID | <bf63f1e9-bccb-477f-bae5-75d5fa6b8b32@googlegroups.com> |
| In reply to | #101499 |
On Thursday, 12 January 2017 08:11:15 UTC, Alla _ wrote: > On Tuesday, January 10, 2017 at 5:14:38 PM UTC+3, Ben Bacarisse wrote: > > Alla _ <modelling.data@gmail.com> writes: > > I would like to ask for one clarification. My question is regarding using > pointers to characters in the exercise. I declare char *not_converted and > assign NULL to it, so it doesn't actually point anywhere at the beginning, > but not_converted has the size of 4 or 8 bytes (8 in my case). Then, > when I call strtod, the function assigns to not_converted the address of > the first character that was not converted. I wouldn't say "the function assigns ..." - what happens is that you declare not_converted as a pointer to char, initially pointing nowhere. You pass strtod() the /address/ of not_converted and strtod can then dereference the address and store a suitable pointer value (the address of the first unconverted character) at that address. > But if to read a line from a file I use char *buffer (not a static array) and > do the following declaration: > char *buffer = NULL; > then call fgets (using the static size BUFFER_SIZE), then I will get a > segmentation fault because when I declared the pointer I didn't allocate > any memory, to which that pointer should point, where the program > could store all characters from the line. Therefore, to use a buffer pointer > I need first to allocate memory, and then call fgets. You pass fgets() the /value/ of "buffer" and fgets assumes it can take that as a valid address at which to start storing returned data. You still seem to be confused about pointers and addresses. Perhaps you need to take a little more time over the basics of these without all the other stuff you are trying to handle.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-12 01:41 -0800 |
| Message-ID | <0222d52d-adf9-4cea-9aa4-b4a06b7fe484@googlegroups.com> |
| In reply to | #101500 |
On Thursday, January 12, 2017 at 12:13:58 PM UTC+3, mark.b...@gmail.com wrote: > On Thursday, 12 January 2017 08:11:15 UTC, Alla _ wrote: > > On Tuesday, January 10, 2017 at 5:14:38 PM UTC+3, Ben Bacarisse wrote: > > > Alla _ <modelling.data@gmail.com> writes: > > > > I would like to ask for one clarification. My question is regarding using > > pointers to characters in the exercise. I declare char *not_converted and > > assign NULL to it, so it doesn't actually point anywhere at the beginning, > > but not_converted has the size of 4 or 8 bytes (8 in my case). Then, > > when I call strtod, the function assigns to not_converted the address of > > the first character that was not converted. > > I wouldn't say "the function assigns ..." - what happens is that you declare > not_converted as a pointer to char, initially pointing nowhere. You pass > strtod() the /address/ of not_converted and strtod can then dereference the > address and store a suitable pointer value (the address of the first > unconverted character) at that address. > > > But if to read a line from a file I use char *buffer (not a static array) and > > do the following declaration: > > char *buffer = NULL; > > then call fgets (using the static size BUFFER_SIZE), then I will get a > > segmentation fault because when I declared the pointer I didn't allocate > > any memory, to which that pointer should point, where the program > > could store all characters from the line. Therefore, to use a buffer pointer > > I need first to allocate memory, and then call fgets. > > You pass fgets() the /value/ of "buffer" and fgets assumes it can take that > as a valid address at which to start storing returned data. > > You still seem to be confused about pointers and addresses. Perhaps you need > to take a little more time over the basics of these without all the other > stuff you are trying to handle. Oh, I thought that I am fine with that already. Thank you very much for your answer. I see that you have confirmed what I have written, with a slight variation in English words.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-12 09:55 +0000 |
| Message-ID | <o57jn9$hj1$1@dont-email.me> |
| In reply to | #101499 |
On 12/01/17 08:11, Alla _ wrote: > On Tuesday, January 10, 2017 at 5:14:38 PM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: > > I would like to ask for one clarification. My question is regarding using > pointers to characters in the exercise. I declare char *not_converted and > assign NULL to it, so it doesn't actually point anywhere at the beginning, > but not_converted has the size of 4 or 8 bytes (8 in my case). To be more precise, it has the size of sizeof not_converted bytes. This might be 1, 2, 3, 4, 5, 6, 7, 8, 9, or 7,896,423,413 bytes. > Then, > when I call strtod, the function assigns to not_converted the address of > the first character that was not converted. Yes. That is, strtod points not_converted to the first unconverted character. > But if to read a line from a file I use char *buffer (not a static array) and > do the following declaration: > char *buffer = NULL; > then call fgets (using the static size BUFFER_SIZE), then I will get a > segmentation fault because when I declared the pointer I didn't allocate > any memory, to which that pointer should point, where the program > could store all characters from the line. You're wondering why you don't have to allocate memory for not_converted, but you /do/ have to allocate it for buffer? Answer: the memory that not_converted points into (after the strtod call) is /already/ allocated, because you allocated that memory yourself in some way. When you make a legal call to strtod, you pass it a string, which is a sequential series of characters in *already-allocated memory*. Consider: char foo[32] = " 1234.5zulu"; When you do this: char *bar = NULL; char *baz = foo + 8; You expect bar to point nowhere, because you've set it to NULL, but you expect baz to point 8 characters into foo. There's no malloc call here, because you're not asking for /more/ memory --- you're pointing into memory that you already own. strtod(foo, &bar); Similarly, bar will be pointing into memory that you already own, memory that is currently labelled 'foo'. In fact, bar and baz now point to precisely the same place, the ninth character of foo, the 'z'. > Here is a program once again, but with a slight change introducing > buffer pointer. <snip> > char *buffer = malloc(BUFFER_SIZE); > size_t line = 0; > > //Parse file data, store only numbers > while( fgets(buffer, BUFFER_SIZE, input_file) != NULL) If malloc fails, the behaviour of this line is undefined. I've mentioned this to you before. Several times, if I'm not mistaken. Failing to check malloc returns is a terrible habit, and one that you need to break as soon as possible. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-12 10:25 -0800 |
| Message-ID | <f4a49ec3-390b-4cd9-8fdf-7e08b443f1c2@googlegroups.com> |
| In reply to | #101504 |
On Thursday, January 12, 2017 at 12:55:28 PM UTC+3, Richard Heathfield wrote: > On 12/01/17 08:11, Alla _ wrote: > > On Tuesday, January 10, 2017 at 5:14:38 PM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > > > > I would like to ask for one clarification. My question is regarding using > > pointers to characters in the exercise. I declare char *not_converted and > > assign NULL to it, so it doesn't actually point anywhere at the beginning, > > but not_converted has the size of 4 or 8 bytes (8 in my case). > > To be more precise, it has the size of sizeof not_converted bytes. This > might be 1, 2, 3, 4, 5, 6, 7, 8, 9, or 7,896,423,413 bytes. > > > Then, > > when I call strtod, the function assigns to not_converted the address of > > the first character that was not converted. > > Yes. That is, strtod points not_converted to the first unconverted > character. > > > But if to read a line from a file I use char *buffer (not a static array) and > > do the following declaration: > > char *buffer = NULL; > > then call fgets (using the static size BUFFER_SIZE), then I will get a > > segmentation fault because when I declared the pointer I didn't allocate > > any memory, to which that pointer should point, where the program > > could store all characters from the line. > > You're wondering why you don't have to allocate memory for > not_converted, but you /do/ have to allocate it for buffer? Not that I was wondering, rather checking; and upon doing so have decided to confirm my assumptions here. But I am glad to see that you have understood my motive, even though I didn't express it. Thank you! >Answer: the > memory that not_converted points into (after the strtod call) is > /already/ allocated, because you allocated that memory yourself in some way. > > When you make a legal call to strtod, you pass it a string, which is a > sequential series of characters in *already-allocated memory*. Consider: > > char foo[32] = " 1234.5zulu"; > > When you do this: > > char *bar = NULL; > char *baz = foo + 8; > > You expect bar to point nowhere, because you've set it to NULL, but you > expect baz to point 8 characters into foo. There's no malloc call here, > because you're not asking for /more/ memory --- you're pointing into > memory that you already own. Yes, I see. > > strtod(foo, &bar); > > Similarly, bar will be pointing into memory that you already own, memory > that is currently labelled 'foo'. In fact, bar and baz now point to > precisely the same place, the ninth character of foo, the 'z'. > > > Here is a program once again, but with a slight change introducing > > buffer pointer. > > <snip> > > > char *buffer = malloc(BUFFER_SIZE); > > size_t line = 0; > > > > //Parse file data, store only numbers > > while( fgets(buffer, BUFFER_SIZE, input_file) != NULL) > > If malloc fails, the behaviour of this line is undefined. I've mentioned > this to you before. Several times, if I'm not mistaken. Yes! I have not failed to do this before, and it's the first time in quite a while that I have not done that. Apologies. > > Failing to check malloc returns is a terrible habit, and one that you > need to break as soon as possible. Yes, I understand it. Thank you very much for your comments.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-08 19:02 -0800 |
| Message-ID | <2oj57cdre121j0nhodi3k4cph22cj03agj@4ax.com> |
| In reply to | #101286 |
On Sun, 8 Jan 2017 03:43:12 -0800 (PST), Alla _ <modelling.data@gmail.com> wrote: >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 => Not a C issue, and perhaps just a question of semantics, but that is not the way things work in accounting. Consider a five year period. If year 1 has 11% growth, year 2 has 18% growth, year 3 has 14% growth, year 4 has 1%, and year 5 as 1%, then the average rate computed this way would be 9.0%. But a base value of 100, year one would end at 111, year two would end at 131, year 3 would end at 149.3, year 4 would end at 150.8, and year 5 would end at 152.3. The average interest rate over five years that would grow a base value of 100 to 152.3 is slightly less than 8.8% If it matters, the formula for average interest rate over y years is rate = exp(log(final_value-initial_value)/y) - 1; -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-09 05:27 -0800 |
| Message-ID | <fc7b4651-8e55-48fa-888a-0d529ded8a47@googlegroups.com> |
| In reply to | #101331 |
On Monday, January 9, 2017 at 6:02:33 AM UTC+3, Barry Schwarz wrote: > On Sun, 8 Jan 2017 03:43:12 -0800 (PST), Alla _ > <modelling.data@gmail.com> wrote: > > >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 => > > Not a C issue, and perhaps just a question of semantics, but that is > not the way things work in accounting. Consider a five year period. > If year 1 has 11% growth, year 2 has 18% growth, year 3 has 14% > growth, year 4 has 1%, and year 5 as 1%, then the average rate > computed this way would be 9.0%. > > But a base value of 100, year one would end at 111, year two would end > at 131, year 3 would end at 149.3, year 4 would end at 150.8, and year > 5 would end at 152.3. The average interest rate over five years that > would grow a base value of 100 to 152.3 is slightly less than 8.8% > > If it matters, the formula for average interest rate over y years is > rate = exp(log(final_value-initial_value)/y) - 1; > rate = (final_value / initial_value)^(1/years) Then take each year's ending value x rate => eliminate saw tooth problem. > -- > Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-01-07 17:06 +0100 |
| Message-ID | <o4r3mv$fkq$1@gioia.aioe.org> |
| In reply to | #101215 |
On 1/6/2017 3:11 PM, Alla _ wrote: <snip> > double sum = 0; I don't know if anyone else commented about this, but as of my personal knowledge it is a good habit, when specifying floating point constants, to make their float type explicit: double sum = 0.0; Occasionally, it can prevent surprises.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-07 08:11 -0800 |
| Message-ID | <e69b5661-bba0-4a86-aea7-7ddca401bbaf@googlegroups.com> |
| In reply to | #101231 |
On Saturday, January 7, 2017 at 7:07:04 PM UTC+3, Manfred wrote: > On 1/6/2017 3:11 PM, Alla _ wrote: > <snip> > > double sum = 0; > I don't know if anyone else commented about this, but as of my personal > knowledge it is a good habit, when specifying floating point constants, > to make their float type explicit: > double sum = 0.0; > > Occasionally, it can prevent surprises. Thank you! No, no one has yet commented on this, but now I recall I have seen this approach, and it does sound as a better choice here.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-05 16:04 -0800 |
| Message-ID | <a3nt6cp73q96r955vct2gaulo8d23ongia@4ax.com> |
| In reply to | #101162 |
On Thu, 5 Jan 2017 02:52:30 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>On Wednesday, January 4, 2017 at 3:21:46 PM UTC+3, Ben Bacarisse wrote:
>> Mark Bluemel has also made the key point here but I'm going to reply
>> as well because I want to add a couple of other remarks...
>>
>> Alla _ <modelling.data@gmail.com> writes:
>> <snip>
>> >> In order to try to speed things up, here's an attempt at a more rigorous
>> >> specification:
>> >>
>> >> The notation <number> means any non-empty sequence of bytes that would
>> >> be accepted by strtod as a number. <ws> means any (possibly empty)
>> >> sequence of space characters as defined by isspace. <any> refers to a
>> >> (possibly empty) sequence of entirely arbitrary bytes (digits, spaces,
>> >> newlines, anything).
>> >>
>> >> Exercise 1 wanted you to average all the numbers found on lines with the
>> >> format
>> >>
>> >> <number><any>
>> >>
>> >> and to ignore any that don't fit that pattern. In exercise 2 you must
>> >> average the numbers found only on lines with the format
>> >>
>> >> <number><ws>
>> >>
>> > I see. It's was indeed a matter of moving one line of code.
>>
>> Almost. Very close now.
>>
>> I think you need a develop a more diabolical testing regime. You should
>> be trying very hard to break your program and, by now, I'd expect you to
>> have many files (or many one large file with many lines) that are in
>> some way odd or special that you throw at each version to see if it
>> breaks.
>>
>> The two cases you need to think about are a line with nothing in it, and
>> a line with a number but some trailing spaces. This last one should
>> really have been in your tests. It was even in the list I sent you!
>>
>> When you have that sorted out, I'm going to say "now re-organise the
>> code to remove the continue" so you can do that before waiting, but make
>> the changes needed for correctness first. Don't do it yet.
>
>Please, take a look at the version below. Yesterday in my reply to Mark I have
>posted a version with a few bugs, which I have managed to find. The version
>I am posting now uses the no-additional-array approach, suggested by Mark,
>because it was easier to spot mistakes using that approach (Thank you, Mark!).
>If this version is all right, I will correct my array version as well based on corrections
>I have implemented here. Also, I have eliminated the 'continue' thing, because it
>bothered me a lot, even without you commenting on it, but I am glad you have
>brought that up as well - it did tell me I was right feeling bad about using it.
>
>#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);
>bool empty_input(char *buffer);
<snip main>
>/** 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 1 number
> if ( (not_converted > buffer) && (!empty_input(buffer) &&
You really need to think about your tests. If not_converted is
greater than buffer, then strtod found a number to process. That
means there was some non-<ws> in the line. Therefore,
empty_input(buffer) must return false and the second expression will
always evaluate to true. If not_converted equals buffer, then the
second expression will not be evaluated at all. Therefore, it never
contributes anything to the evaluation of the if expression as a
whole.
> empty_input(not_converted)) )
> {
> *sum += number;
> (*index_n)++;
> line++;
> }
> else
> {
> fprintf(stderr, "Incorrect input line '%zu'\n", line);
> 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 check for empty lines **/
>bool empty_input(char *buffer)
>{
> if (*buffer == '\r' || *buffer == '\n')
Another meaningless test. isspace treats both \r and \n as <ws>. This
may save one or two iterations of the following while loop but hardly
worth the effort or added complexity.
> return true;
> else
> {
> while(isspace(*buffer++));
> if(*buffer == '\0')
> return true;
> }
> return false;
>}
>
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-04 12:36 -0800 |
| Message-ID | <cjmq6c14da9n4u2j9ie83918j28tunn5r9@4ax.com> |
| In reply to | #101082 |
On Wed, 4 Jan 2017 02:23:04 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>On Wednesday, January 4, 2017 at 6:31:00 AM UTC+3, Ben Bacarisse wrote:
<snip>
>> and to ignore any that don't fit that pattern. In exercise 2 you must
>> average the numbers found only on lines with the format
>>
>> <number><ws>
>>
>I see. It's was indeed a matter of moving one line of code.
>#include <stdio.h>
>#include <stdlib.h>
>#include <ctype.h>
>#include <string.h>
>#include <stdbool.h>
>#include <errno.h>
>
>#define BUFFER_SIZE 100
>#define NUMBERS 100
>#define TEXT "../files/ex_1.csv"
>
>bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
>double average(const double *numbers, size_t index);
>
>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");
> if ( fp )
> {
> double numbers[NUMBERS] = {0};
> size_t index_n = 0;
> double average_num;
>
> if( !get_lines(fp, numbers, &index_n) )
> {
> fclose(fp);
An error message would be nice.
> return EXIT_FAILURE;
> }
> //Call function average only when index_n > 0
> if(index_n > 0)
> {
> average_num = average(numbers, index_n);
> printf("%.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
> }
> }
> //Couldn't open the file
> fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
> return EXIT_FAILURE;
>}
>/** Function to read and process the data
> from the file line by line
> **/
>bool get_lines (FILE *input_file, double *numbers, 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);
>
> //Ignore lines that contain characters other than 1 number
> if (not_converted >= buffer && *not_converted != '\n')
Will this accept or reject a line containing "1 "? What about a
line containing only "\n"? What about a line containing "1 2"? What
about a line longer than BUFFER_SIZE containing "1 "? Why are you
possibly accepting a line where not_converted equals buffer even
though that guarantees there was not an acceptable number on the line?
> {
> fprintf(stderr, "Incorrect input, line '%zu'\n", line);
Did you really mean to allow this to specify line 0 if the error
occurs on the first line?
> line++;
> continue;
> }
> //Store a number in the array
> if (*index_n < NUMBERS)
> numbers[(*index_n)++] = number;
> else
> {
> fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
> return false;
> }
> line++;
> }
>
> if (ferror(input_file))
> {
> if(*index_n != 0)
> fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
This error message is not dependent on *index_n
> fprintf(stderr, "The function detected an error in reading a file; no data has been processed");
This error message should specify how many numbers were successfully
processed, even if 0.
> return false;
> }
> return true;
>}
>
>/** Function to find the average;
> must only be called with index > 0
> **/
>double average(const double *numbers, size_t index)
>{
> double sum = 0;
> for(size_t i = 0; i < index; i++)
> sum += numbers[i];
>
> return sum/index;
>}
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-04 12:49 -0800 |
| Message-ID | <lny3yqsg7y.fsf@kst-u.example.com> |
| In reply to | #101128 |
Barry Schwarz <schwarzb@dqel.com> writes:
> On Wed, 4 Jan 2017 02:23:04 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
[...]
>> fprintf(stderr, "The function detected an error in reading a file; no data has been processed");
>
> This error message should specify how many numbers were successfully
> processed, even if 0.
And it should end in a newline.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-04 05:19 -0800 |
| Message-ID | <424b6473-9d52-473f-abce-4de84994b566@googlegroups.com> |
| In reply to | #101075 |
On Wednesday, January 4, 2017 at 6:31:00 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
> In exercise 3 you must calculate the average of the differences between
> pairs of numbers. Only lines of the form
>
> <number><ws>,<ws><number><ws>
>
> should be used. All other lines should be ignored.
<snip>
The only thing that was not clear in the 3d exercise is the precedence of numbers
to compute the difference: should I have subtracted the first one from the
second, or vv? For now the program subtracts the second from the first one.
Or should the program compute the abs of the difference? For now, it doesn't.
Please, take a look at this third exercise below.
one of the inputs
3.0,2
2_,4
1,_-6.0
I have one "comment" within the program that is not a comment, but a
note, in which I explain to you why I use additional variable. I found that
it is better to explain right before declaring that variable.
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <stdbool.h>
#include <errno.h>
#define BUFFER_SIZE 100
#define NUMBERS 100
#define TEXT "../files/ex_1.csv"
bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
double average(const double *numbers, size_t index);
bool valid_input(char *buffer, char *not_converted);
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");
if ( fp )
{
double numbers[NUMBERS] = {0};
size_t index_n = 0;
double average_num;
if( !get_lines(fp, numbers, &index_n) )
{
fclose(fp);
return EXIT_FAILURE;
}
//Call function average only when index_n > 0
if(index_n > 0)
{
average_num = average(numbers, index_n);
printf("%.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
}
//Couldn't open the file
fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
return EXIT_FAILURE;
}
/** Function to read and process the data
from the file line by line
**/
bool get_lines (FILE *input_file, double *numbers, 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 difference = 0;
double number = strtod(buffer, ¬_converted);
//Proceed only if input is valid
if ( valid_input(buffer, not_converted))
{
/*** Not a comment, a note: I use additional
pointer here because my buffer has type char[100],
and I can't assign to it the address of a pointer;
if it were pointer to a char, I would not need ptr
***/
if(*(not_converted+1) != '\0')
{
char *ptr = not_converted + 1;
if(isspace(*ptr) || *ptr == ',')
ptr++;
difference = number - strtod(ptr, ¬_converted);
if(valid_input(ptr, not_converted))
{
if (*index_n < NUMBERS)
numbers[(*index_n)++] = difference;
else
{
fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
return false;
}
}
}
}
line++;
continue;
}
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 characters
in the not-converted part of the line
**/
bool valid_input(char *buffer, char *not_converted)
{
if ( not_converted > buffer)
if(isspace(*not_converted) || *not_converted == ',')
return true;
return false;
}
/** Function to find the average;
must only be called with index > 0
**/
double average(const double *numbers, size_t index)
{
double sum = 0;
for(size_t i = 0; i < index; i++)
sum += numbers[i];
return sum/index;
}
It also would be interesting to scale up the third exercise to write a program that
computes the average of the differences of all numbers in the line, which
can contain any number of numerical values; and ignore lines like the one
I have thought of initially when doing exercise 2, i.e. lines that can contain
non-numerical characters anywhere within the line.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-01-04 15:14 +0000 |
| Message-ID | <87a8b6n9h8.fsf@bsb.me.uk> |
| In reply to | #101090 |
Alla _ <modelling.data@gmail.com> writes: > On Wednesday, January 4, 2017 at 6:31:00 AM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> > <snip> >> In exercise 3 you must calculate the average of the differences between >> pairs of numbers. Only lines of the form >> >> <number><ws>,<ws><number><ws> >> >> should be used. All other lines should be ignored. > <snip> > The only thing that was not clear in the 3d exercise is the precedence of numbers > to compute the difference: should I have subtracted the first one from the > second, or vv? For now the program subtracts the second from the first > one. Fine. Since this is about input I don't think it matters. > Or should the program compute the abs of the difference? For now, it > doesn't. That would need to be stated explicitly. Unless there is some very specific context involved, difference doesn't mean absolute difference. But this is not something to worry about. Do you think I'd mind if you write any one of sum += v1 - v2; sum += v2 - v1; sum += fabs(v1 - v2); in an exercise about input processing? Even if I did care, I'd say "ah I was not clear, I meant ..." and that would be that. > Please, take a look at this third exercise below. Not yet. What's happened to exercise two? <snip> > It also would be interesting to scale up the third exercise to write a > program that computes the average of the differences of all numbers in > the line, which can contain any number of numerical values; and ignore > lines like the one I have thought of initially when doing exercise 2, > i.e. lines that can contain non-numerical characters anywhere within > the line. That would make a fine exercise 5, though I would not use average of differences simply because (if I understand the term) it requires an extra condition of the there being an even number of data items. But that could be the exercise 6. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 02:57 -0800 |
| Message-ID | <cf6a2e17-be86-4fac-a58c-0220568a0913@googlegroups.com> |
| In reply to | #101095 |
On Wednesday, January 4, 2017 at 6:14:22 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > <snip> > Please, take a look at this third exercise below. > > Not yet. What's happened to exercise two? Nothing, I am working on improving it. > > <snip> > > It also would be interesting to scale up the third exercise to write a > > program that computes the average of the differences of all numbers in > > the line, which can contain any number of numerical values; and ignore > > lines like the one I have thought of initially when doing exercise 2, > > i.e. lines that can contain non-numerical characters anywhere within > > the line. > > That would make a fine exercise 5, though I would not use average of > differences simply because (if I understand the term) it requires an > extra condition of the there being an even number of data items. But that > could be the exercise 6. > Why have you suggested that taking an average of a set of numbers requires that set to contain an even number of elements, if I have understood you correctly? And the exercise 3 requires the program to compute the average of differences. I sense some misunderstanding here ) > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-05 08:24 -0800 |
| Message-ID | <ln1swhscek.fsf@kst-u.example.com> |
| In reply to | #101163 |
Alla _ <modelling.data@gmail.com> writes:
> On Wednesday, January 4, 2017 at 6:14:22 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
[...]
>> > It also would be interesting to scale up the third exercise to write a
>> > program that computes the average of the differences of all numbers in
>> > the line, which can contain any number of numerical values; and ignore
>> > lines like the one I have thought of initially when doing exercise 2,
>> > i.e. lines that can contain non-numerical characters anywhere within
>> > the line.
>>
>> That would make a fine exercise 5, though I would not use average of
>> differences simply because (if I understand the term) it requires an
>> extra condition of the there being an even number of data items. But that
>> could be the exercise 6.
>>
> Why have you suggested that taking an average of a set of numbers requires
> that set to contain an even number of elements, if I have understood you
> correctly? And the exercise 3 requires the program to compute the average
> of differences. I sense some misunderstanding here )
It depends on what "average of differences" means.
Given the sequence 10, 20, 40, 70, does the "average of differences"
mean the average of 10, 20, and 30, or 10 and 30? If the latter, you
need an even number of elements.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-05 02:58 -0800 |
| Message-ID | <c7b53397-f16e-4a5b-867c-6d3904221302@googlegroups.com> |
| In reply to | #101095 |
On Wednesday, January 4, 2017 at 6:14:22 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > <snip> > That would make a fine exercise 5, though I would not use average of > differences simply because (if I understand the term) it requires an > extra condition of the there being an even number of data items. But that > could be the exercise 6. Oh, sad that you will see that only upon reading my previous comment; I see what you mean - you were referring not the word 'average' but to the word 'difference'. > > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2017-01-04 13:02 -0800 |
| Message-ID | <86nq6clop820mb0tnqeoj525d5gae09aim@4ax.com> |
| In reply to | #101090 |
On Wed, 4 Jan 2017 05:19:01 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:
>On Wednesday, January 4, 2017 at 6:31:00 AM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
><snip>
>> In exercise 3 you must calculate the average of the differences between
>> pairs of numbers. Only lines of the form
>>
>> <number><ws>,<ws><number><ws>
>>
>> should be used. All other lines should be ignored.
><snip>
And now in this single thread, we have exercise #3 commingled with two
versions of exercise #2. May I suggest you start three new threads
with different titles that make it clear what is being discussed.
>The only thing that was not clear in the 3d exercise is the precedence of numbers
>to compute the difference: should I have subtracted the first one from the
>second, or vv? For now the program subtracts the second from the first one.
>Or should the program compute the abs of the difference? For now, it doesn't.
>
>Please, take a look at this third exercise below.
>one of the inputs
>3.0,2
>2_,4
>1,_-6.0
>I have one "comment" within the program that is not a comment, but a
>note, in which I explain to you why I use additional variable. I found that
>it is better to explain right before declaring that variable.
>#include <stdio.h>
>#include <stdlib.h>
>#include <ctype.h>
>#include <string.h>
>#include <stdbool.h>
>#include <errno.h>
>
>#define BUFFER_SIZE 100
>#define NUMBERS 100
>#define TEXT "../files/ex_1.csv"
>
>bool get_lines (FILE *input_file, double *numbers, size_t *index_n);
>double average(const double *numbers, size_t index);
>bool valid_input(char *buffer, char *not_converted);
>
>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");
> if ( fp )
> {
> double numbers[NUMBERS] = {0};
> size_t index_n = 0;
> double average_num;
>
> if( !get_lines(fp, numbers, &index_n) )
> {
> fclose(fp);
Error message?
> return EXIT_FAILURE;
> }
> //Call function average only when index_n > 0
> if(index_n > 0)
> {
> average_num = average(numbers, index_n);
> printf("%.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
> }
> }
> //Couldn't open the file
> fprintf(stderr, "%s - %s\n", data_file, errno ? strerror(errno) : "Open failure!");
> return EXIT_FAILURE;
>}
>/** Function to read and process the data
> from the file line by line
> **/
>bool get_lines (FILE *input_file, double *numbers, 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 difference = 0;
> double number = strtod(buffer, ¬_converted);
>
> //Proceed only if input is valid
> if ( valid_input(buffer, not_converted))
> {
> /*** Not a comment, a note: I use additional
> pointer here because my buffer has type char[100],
> and I can't assign to it the address of a pointer;
> if it were pointer to a char, I would not need ptr
> ***/
> if(*(not_converted+1) != '\0')
> {
> char *ptr = not_converted + 1;
> if(isspace(*ptr) || *ptr == ',')
> ptr++;
What will this do to a line containing "1 2,3"? Or one with no comma
between the two numbers, only <ws>?
> difference = number - strtod(ptr, ¬_converted);
>
> if(valid_input(ptr, not_converted))
> {
> if (*index_n < NUMBERS)
> numbers[(*index_n)++] = difference;
> else
> {
> fprintf(stderr, "Number of data exceeds capacity; stop at line '%zu'\n", line);
> return false;
> }
> }
> }
> }
> line++;
> continue;
> }
>
> if (ferror(input_file))
> {
> if(*index_n != 0)
> fprintf(stderr, "Error: last input processed was at line '%zu': %s\n", line, buffer);
This message not dependent on index_n.
> fprintf(stderr, "The function detected an error in reading a file; no data has been processed");
This message should specify number of values processed, even if 0.
> return false;
> }
> return true;
>}
>
>/** Function to determine valid characters
> in the not-converted part of the line
> **/
>bool valid_input(char *buffer, char *not_converted)
>{
> if ( not_converted > buffer)
> if(isspace(*not_converted) || *not_converted == ',')
Will this accept or reject a line containing "1,2,"? What should it
do? Will this accept or eject a line of exactly BUFFER_SIZE-4 spaces
followed by "1,2"? Will it accept or reject a line containing "1,2_3"
(the underscore represent one space)?
Go back and look at how you verified the validity of the first number
and its trailing comma. Think about how similar that is to how you
need to verify the validity of the second number and whatever follows
it.
> return true;
>
> return false;
>}
>
>/** Function to find the average;
> must only be called with index > 0
> **/
>double average(const double *numbers, size_t index)
>{
> double sum = 0;
> for(size_t i = 0; i < index; i++)
> sum += numbers[i];
>
> return sum/index;
>}
>
>It also would be interesting to scale up the third exercise to write a program that
>computes the average of the differences of all numbers in the line, which
>can contain any number of numerical values; and ignore lines like the one
>I have thought of initially when doing exercise 2, i.e. lines that can contain
>non-numerical characters anywhere within the line.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web