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 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 10:14 -0800 |
| Message-ID | <04709823-a412-4700-9597-7e6282bf11de@googlegroups.com> |
| In reply to | #100571 |
On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> <snip>
>
> > Please, take a look at this version. I don't need any non-numeric characters
> > after digital ones, therefore I do not use isalnum here.
> > I now intend to use this version in my values converting function. Is
> > it all right?
>
> No, I'd say there is a bug, but the real problem is that you are still
> looking for problems rather than acting on success. You've spent a lot
> of time with programs that look for \r when (as far as I know) you don't
> want any \r characters. A stray \r is no different to a stray # or \a
> or any other odd thing you don't expect.
>
> The most robust programs work by looking for the data they need and then
> only continuing when they find it. They don't care about all the many
> ways in which the input might be malformed (except when they absolutely
> must provide detailed explanations of problems). This strategy will
> also, as if by magic, solve the problems with last lines being or not
> being terminated by a newline. Since you don't care about that, there
> is no reason for your program to take any special action either. You
> process the valid data that you find in a line buffer. When the data
> you need are not there, your program simply stops, with some message
> like "Malformed data on line 54 of file xyz.csv".
Thank you very much. I have to ponder over this; for now I don't yet see
how to check for success, i.e. to check that the file contains only the data
I need, without creating a cumbersome set of character names, including
double quotes (which signal that there are some inner commas
within the name, which do not reflect column separation). I deal with some of
these issues in other functions, i.e. row_names and row_values.
Most likely, here
I will need to use structures, as we have discussed with Richard.
Indeed, the input file should have only certain amount of row_names,
and those names are also predefined, according to my script.
Also there is a predefined number of columns, which contain
numerical data.
>
> In this fragment your plan seems to be to find a character you don't
> need (the last non-digit) and only then will you start to look for the
> data you need. That's backwards -- look for what you need and complain
> to the user when you don't find it.
>
Same - I have to think it over. I hope to find this solution.
> Now for that bug...
>
> > bool get_line (FILE *input_file)
> > {
> > char buffer[BUFFER_SIZE] = "";
> > size_t line = 0;
> > size_t index;
> >
> > //Read each line from the file, store in the buffer
> > while(fgets(buffer, sizeof(buffer), input_file) != NULL)
> > {
> <snip>
> > index = strlen(buffer) - 1;
> <snip>
> > while(!isdigit(buffer[index]))
> > index--;
> > buffer[index+1] = '\0';
>
> What happens when the line is empty, i.e. buffer contains only "\n"?
> What if it contains only "abc,def,ghi\n"?
I have added this:
index = strlen(buffer) - 1;
if(index < 1)
{
printf("The line[%zu] contains no input\n", line);
puts("Please, check the input data");
return false;
}
/* Finish the buffer at the last digit
in the line */
while(!isdigit(buffer[index]))
index--;
if(index == 0)
{
puts("Incorrect data: no numerical input; correct the input.");
return false;
}
buffer[index+1] = '\0';
>
> > /* Check for any unprintable characters
> > within the line */
> > if(unprintable(buffer))
>
> Why do you care?
opps ) Because if the line contains something I don't need, the user
has to correct the input. I need the user to provide the correct input
information.
>
> <snip>
> > /** Find unprintable characters in array
> > other than LF and CR
> > **/
>
> A detail: this function reports CR and LF as well. You may call it in
> such a way that it will never see them, but the function's definition
> (and comments) should not assume some limited context like that.
>
> Another: if you asked someone to find your car keys, would you be happy
> if, after a few minutes, they just called out "yes"? Functions
> described as finding something should probably say where. (To be clear,
> this is a remark about the comment -- the function is fine simply
> reporting the presence of some class of characters.)
>
> > bool unprintable(char *buffer)
> > {
> > while(*buffer != '\0')
> > {
> > if(!isprint(*buffer))
>
> Technically, you should write !isprint((unsigned char)*buffer) here if
> you want the code to be portable. This is one of the nasty bits of C's
> history that has stuck around. (The same applies to all the isxxx
> functions and macros.)
>
I see. Thank you.
/** Find unprintable characters in array
other than LF and CR
**/
bool unprintable(char *buffer)
{
int index = 0;
while(*buffer != '\0')
{
if(!isprint((unsigned char)*buffer))
{
printf("Unprintable character found at buffer[%i]\n", index);
return true;
}
buffer++;
index++;
}
return false;
}
> > return true;
> > buffer++;
> > }
> > return false;
> > }
>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-29 11:44 -0800 |
| Message-ID | <lna8be1pw7.fsf@kst-u.example.com> |
| In reply to | #100572 |
Alla _ <modelling.data@gmail.com> writes:
[...]
> Thank you very much. I have to ponder over this; for now I don't yet see
> how to check for success, i.e. to check that the file contains only the data
> I need, without creating a cumbersome set of character names, including
> double quotes (which signal that there are some inner commas
> within the name, which do not reflect column separation). I deal with some of
> these issues in other functions, i.e. row_names and row_values.
[...]
In a CSV file, a field surrounded with double quotes doesn't
*necessarily* contain commas, but it's *permitted* to contain commas.
For example, these are equivalent:
one,two,"three,four"
"one","two","three,four"
There are also rules for how to represent fields that contain quotation
marks; you might not need to worry about that, at least initially.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-30 02:02 +0000 |
| Message-ID | <87a8bejhsp.fsf@bsb.me.uk> |
| In reply to | #100572 |
Alla _ <modelling.data@gmail.com> writes:
> On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> <snip>
>>
>> > Please, take a look at this version. I don't need any non-numeric characters
>> > after digital ones, therefore I do not use isalnum here.
>> > I now intend to use this version in my values converting function. Is
>> > it all right?
>>
>> No, I'd say there is a bug, but the real problem is that you are still
>> looking for problems rather than acting on success. You've spent a lot
>> of time with programs that look for \r when (as far as I know) you don't
>> want any \r characters. A stray \r is no different to a stray # or \a
>> or any other odd thing you don't expect.
>>
>> The most robust programs work by looking for the data they need and then
>> only continuing when they find it. They don't care about all the many
>> ways in which the input might be malformed (except when they absolutely
>> must provide detailed explanations of problems). This strategy will
>> also, as if by magic, solve the problems with last lines being or not
>> being terminated by a newline. Since you don't care about that, there
>> is no reason for your program to take any special action either. You
>> process the valid data that you find in a line buffer. When the data
>> you need are not there, your program simply stops, with some message
>> like "Malformed data on line 54 of file xyz.csv".
>
> Thank you very much. I have to ponder over this; for now I don't yet see
> how to check for success, i.e. to check that the file contains only the data
> I need, without creating a cumbersome set of character names, including
> double quotes (which signal that there are some inner commas
> within the name, which do not reflect column separation). I deal with some of
> these issues in other functions, i.e. row_names and row_values.
It's hard for me to know how to help since I don't see the problem you
seem to be seeing. I don't see any need for character names at all, let
alone a cumbersome set of them.
If I were teaching this on a course, I would design a series of
exercises that built up to what you are doing. I'm not sure you have
time to do it that way.
<snip>
>> Now for that bug...
>>
>> > bool get_line (FILE *input_file)
>> > {
>> > char buffer[BUFFER_SIZE] = "";
>> > size_t line = 0;
>> > size_t index;
>> >
>> > //Read each line from the file, store in the buffer
>> > while(fgets(buffer, sizeof(buffer), input_file) != NULL)
>> > {
>> <snip>
>> > index = strlen(buffer) - 1;
>> <snip>
>> > while(!isdigit(buffer[index]))
>> > index--;
>> > buffer[index+1] = '\0';
>>
>> What happens when the line is empty, i.e. buffer contains only "\n"?
>
>> What if it contains only "abc,def,ghi\n"?
> I have added this:
> index = strlen(buffer) - 1;
> if(index < 1)
What if buffer contains just one character "9"? Do you not want to see
that number?
> {
> printf("The line[%zu] contains no input\n", line);
> puts("Please, check the input data");
> return false;
> }
> /* Finish the buffer at the last digit
> in the line */
> while(!isdigit(buffer[index]))
> index--;
> if(index == 0)
> {
> puts("Incorrect data: no numerical input; correct the input.");
> return false;
> }
What about the line "abc,def,ghi\n"?
> buffer[index+1] = '\0';
>>
>> > /* Check for any unprintable characters
>> > within the line */
>> > if(unprintable(buffer))
>>
>> Why do you care?
> opps ) Because if the line contains something I don't need, the user
> has to correct the input. I need the user to provide the correct input
> information.
The point was why specifically non-printing characters? In any program
there will lots of ways in which the input can be wrong. In this case,
it's hard to tell because the program has no function yet, but if the
purpose were to read numbers, then there would be all sorts of ways in
which the input could be wrong. Will you try to test for them all?
The right approach (for, say, numerical input) is to parse a number
using strtod and to report and error if that fails. Simple. It could
fail because there are some non-printing characters in place of digits,
but maybe because the line is empty or... well any of an infinite number
of other erroneous inputs.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-30 03:13 -0800 |
| Message-ID | <58e42cf5-fb0b-4813-9473-a4186723a297@googlegroups.com> |
| In reply to | #100602 |
On Friday, December 30, 2016 at 5:02:22 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> >> <snip>
> >>
> >> What happens when the line is empty, i.e. buffer contains only "\n"?
> >
> >> What if it contains only "abc,def,ghi\n"?
> > I have added this:
> > index = strlen(buffer) - 1;
> > if(index < 1)
>
> What if buffer contains just one character "9"? Do you not want to see
> that number?
No, I don't. There have to be 5 columns of numerical data, not more, not less.
>
> > {
> > printf("The line[%zu] contains no input\n", line);
> > puts("Please, check the input data");
> > return false;
> > }
> > /* Finish the buffer at the last digit
> > in the line */
> > while(!isdigit(buffer[index]))
> > index--;
> > if(index == 0)
> > {
> > puts("Incorrect data: no numerical input; correct the input.");
> > return false;
> > }
>
> What about the line "abc,def,ghi\n"?
Isn't the above addresses this issue? I scan the buffer from the very end
till I find the fist numerical character; but if index = 0, it means there are no
numerical characters at all, and the line can contain whatever it pleases, but
it is not valid if there are no exactly 5 columns of numerical input.
>
> > buffer[index+1] = '\0';
> >>
> >> > /* Check for any unprintable characters
> >> > within the line */
> >> > if(unprintable(buffer))
> >>
> >> Why do you care?
> > opps ) Because if the line contains something I don't need, the user
> > has to correct the input. I need the user to provide the correct input
> > information.
>
> The point was why specifically non-printing characters? In any program
> there will lots of ways in which the input can be wrong. In this case,
> it's hard to tell because the program has no function yet, but if the
> purpose were to read numbers, then there would be all sorts of ways in
> which the input could be wrong. Will you try to test for them all?
>
> The right approach (for, say, numerical input) is to parse a number
> using strtod and to report and error if that fails. Simple. It could
> fail because there are some non-printing characters in place of digits,
> but maybe because the line is empty or... well any of an infinite number
> of other erroneous inputs.
I have another post on this matter - there we discuss the strtol function
I use in row_values function to parse all numerical values. This program
here is supposed to precede that one.
>
> <snip>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-30 14:49 +0000 |
| Message-ID | <87y3yxh3pl.fsf@bsb.me.uk> |
| In reply to | #100645 |
Alla _ <modelling.data@gmail.com> writes:
> On Friday, December 30, 2016 at 5:02:22 AM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote:
>> >> Alla _ <modelling.data@gmail.com> writes:
>> >>
>> >> <snip>
>> >>
>
>> >> What happens when the line is empty, i.e. buffer contains only "\n"?
>> >
>> >> What if it contains only "abc,def,ghi\n"?
>> > I have added this:
>> > index = strlen(buffer) - 1;
>> > if(index < 1)
>>
>> What if buffer contains just one character "9"? Do you not want to see
>> that number?
> No, I don't. There have to be 5 columns of numerical data, not more,
> not less.
Then your test is wrong. The shortest valid line is
n,1,2,3,4,5\n
But that's not the way to go anyway.
The current program does nothing useful so I have to speculate on how
you will eventually do some real processing. The simplest way to know
if you have exactly five numbers is to parse all the numbers and report
when you don't get five.
>> > {
>> > printf("The line[%zu] contains no input\n", line);
>> > puts("Please, check the input data");
>> > return false;
>> > }
>> > /* Finish the buffer at the last digit
>> > in the line */
>> > while(!isdigit(buffer[index]))
>> > index--;
>> > if(index == 0)
>> > {
>> > puts("Incorrect data: no numerical input; correct the input.");
>> > return false;
>> > }
>>
>> What about the line "abc,def,ghi\n"?
> Isn't the above addresses this issue? I scan the buffer from the very
> end till I find the fist numerical character; but if index = 0, it
> means there are no numerical characters at all, and the line can
> contain whatever it pleases, but it is not valid if there are no
> exactly 5 columns of numerical input.
No, you can the buffer until index == 0 and test !isdigit(buffer[0]).
You find that 'a' is not a digit and do index--. index is an unsigned
int type so the subtraction wraps round and index will have a value of
something like 18446744073709551615 (that's what it is on my system).
Your program that tests !isdigit(buffer[18446744073709551615]). What do
you think it will find?
On my system, gcc has an -fsanitize=undefined option that does a lot of
run-time checking. Running you program with the input in question gives
me this helpful exchange:
$ ./a1 /dev/stdin ✘
abc,def,ghi
*****************************
Buffer beg:: abc,def,ghi
a1.c:66:16: runtime error: index 18446744073709551615 out of bounds for type 'char [100]'
>> > buffer[index+1] = '\0';
>> >>
>> >> > /* Check for any unprintable characters
>> >> > within the line */
>> >> > if(unprintable(buffer))
>> >>
>> >> Why do you care?
>> > opps ) Because if the line contains something I don't need, the user
>> > has to correct the input. I need the user to provide the correct input
>> > information.
>>
>> The point was why specifically non-printing characters? In any program
>> there will lots of ways in which the input can be wrong. In this case,
>> it's hard to tell because the program has no function yet, but if the
>> purpose were to read numbers, then there would be all sorts of ways in
>> which the input could be wrong. Will you try to test for them all?
>>
>> The right approach (for, say, numerical input) is to parse a number
>> using strtod and to report and error if that fails. Simple. It could
>> fail because there are some non-printing characters in place of digits,
>> but maybe because the line is empty or... well any of an infinite number
>> of other erroneous inputs.
> I have another post on this matter - there we discuss the strtol function
> I use in row_values function to parse all numerical values. This program
> here is supposed to precede that one.
But that does not answer my question. I know you will eventually parse
the numbers -- that's why I asked about the test above. If you write
that program correctly you won't care about the non-printing characters.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-30 03:28 -0800 |
| Message-ID | <d7a18165-7c8d-4be7-a101-6264856e0223@googlegroups.com> |
| In reply to | #100602 |
On Friday, December 30, 2016 at 5:02:22 AM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
<snip>
> It's hard for me to know how to help since I don't see the problem you
> seem to be seeing. I don't see any need for character names at all, let
> alone a cumbersome set of them.
>
> If I were teaching this on a course, I would design a series of
> exercises that built up to what you are doing. I'm not sure you have
> time to do it that way.
I want to learn this correct approach to structuring my programs - you
have been referring to it a few times already, and I did my best to follow
your advice, but as we see I always fail due to lack of understanding and
experience. I even have this phrase of yours "Always check input operations
for success not failure" highlighted in one of my files.
It this case, given the task I am solving, I don't see how to check the line
only for success in succinct and logically correct way because:
- each line has row names at the beginning, followed by 5 columns of
numerical data (as you have, probably, seen in the inputs I have provided
here);
- each row name has a fairly simply format, except for two lines, which might
have two versions - one short (just like all other rows), another long one;
i.e. COGS can also be Cost of goods sold;
SG&A can also be Selling, General, and Administrative (in this latter case
I will also get surrounding double quotes)
- all these have to occupy a contiguous space, not separated by any other
additional characters.
Is it possible to test this type of line only for success leaving out all other unwanted
characters?
If yes, can I learn this in two days if I don't go any further with my task and
concentrate only on this issue?
And the main most important question: do *you* have time and will to guide
me in this process? I will be grateful for sincere answer: tell me yes, or tell
me no - I will definitely understand if you say no, because I know how
tedious it is to try to teach me something at such a distance and my inability
to dedicate enough time to all this (but if you have time, I promise not to
go on with anything else, until I solve this matter with testing the line only
for success).
>
<snip>
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-30 03:45 -0800 |
| Message-ID | <4fa3bed7-0a99-4808-9103-3ebc46f6965a@googlegroups.com> |
| In reply to | #100646 |
On Friday, December 30, 2016 at 2:28:50 PM UTC+3, Alla _ wrote: > On Friday, December 30, 2016 at 5:02:22 AM UTC+3, Ben Bacarisse wrote: > > Alla _ <modelling.data@gmail.com> writes: > > > > > On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote: > > >> Alla _ <modelling.data@gmail.com> writes: > > >> > <snip> > > It's hard for me to know how to help since I don't see the problem you > > seem to be seeing. I don't see any need for character names at all, let > > alone a cumbersome set of them. > > > > If I were teaching this on a course, I would design a series of > > exercises that built up to what you are doing. I'm not sure you have > > time to do it that way. > I want to learn this correct approach to structuring my programs - you > have been referring to it a few times already, and I did my best to follow > your advice, but as we see I always fail due to lack of understanding and > experience. I even have this phrase of yours "Always check input operations > for success not failure" highlighted in one of my files. > > It this case, given the task I am solving, I don't see how to check the line > only for success in succinct and logically correct way because: > - each line has row names at the beginning, followed by 5 columns of > numerical data (as you have, probably, seen in the inputs I have provided > here); > - each row name has a fairly simply format, except for two lines, which might > have two versions - one short (just like all other rows), another long one; > i.e. COGS can also be Cost of goods sold; > SG&A can also be Selling, General, and Administrative (in this latter case > I will also get surrounding double quotes) > - all these have to occupy a contiguous space, not separated by any other > additional characters. > > Is it possible to test this type of line only for success leaving out all other unwanted > characters? > > If yes, can I learn this in two days if I don't go any further with my task and > concentrate only on this issue? > And the main most important question: do *you* have time and will to guide > me in this process? I will be grateful for sincere answer: tell me yes, or tell > me no - I will definitely understand if you say no, because I know how > tedious it is to try to teach me something at such a distance and my inability > to dedicate enough time to all this (but if you have time, I promise not to > go on with anything else, until I solve this matter with testing the line only > for success). > > Oh, I have completely forgotten that it is a New Year's Eve and a festive period. Well. I will still be working, so I will continue to post my questions and will wait until everyone is back )))
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-30 13:53 +0000 |
| Message-ID | <87k2ahikvr.fsf@bsb.me.uk> |
| In reply to | #100646 |
Alla _ <modelling.data@gmail.com> writes: > On Friday, December 30, 2016 at 5:02:22 AM UTC+3, Ben Bacarisse wrote: >> Alla _ <modelling.data@gmail.com> writes: >> >> > On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote: >> >> Alla _ <modelling.data@gmail.com> writes: >> >> > <snip> >> It's hard for me to know how to help since I don't see the problem you >> seem to be seeing. I don't see any need for character names at all, let >> alone a cumbersome set of them. >> >> If I were teaching this on a course, I would design a series of >> exercises that built up to what you are doing. I'm not sure you have >> time to do it that way. > I want to learn this correct approach to structuring my programs - you > have been referring to it a few times already, and I did my best to follow > your advice, but as we see I always fail due to lack of understanding and > experience. I even have this phrase of yours "Always check input operations > for success not failure" highlighted in one of my files. > > It this case, given the task I am solving, I don't see how to check the line > only for success in succinct and logically correct way because: > - each line has row names at the beginning, followed by 5 columns of > numerical data (as you have, probably, seen in the inputs I have provided > here); > - each row name has a fairly simply format, except for two lines, which might > have two versions - one short (just like all other rows), another long one; > i.e. COGS can also be Cost of goods sold; > SG&A can also be Selling, General, and Administrative (in this latter case > I will also get surrounding double quotes) > - all these have to occupy a contiguous space, not separated by any other > additional characters. That last one seems rather strict, but if that's what you need, fine. > Is it possible to test this type of line only for success leaving out all other unwanted > characters? Yes. That's what programming is about. A compiler like gcc is testing something far more complex -- does the input match the rules of C's syntax -- and it can manage it. It uses techniques that have taken decades to develop, but the idea is the same. It does not look for problems but simply decides there is a problem if it can't find a valid C program. You will need a complex function that tests the line for having the right format. That test will extract the data at the same time because there is no point is determining that you have the right data without extracting it. For example, you probably won't write the test for "a number" yourself. Instead, you call strtod but since strtod can tell you the number it found, you might as well store it. Of course, that complex function is written by calling other simpler ones that test for the part you expect: a name, a separator, a number and so on. > If yes, can I learn this in two days if I don't go any further with my > task and concentrate only on this issue? I don't know. I posted some exercises in another answer. Do they look easy or hard to you? > And the main most important question: do *you* have time and will to > guide me in this process? I will be grateful for sincere answer: tell > me yes, or tell me no I have the time, but I would suggest you start with simple exercises and build up. > - I will definitely understand if you say no, because I know how > tedious it is to try to teach me something at such a distance and my inability > to dedicate enough time to all this (but if you have time, I promise not to > go on with anything else, until I solve this matter with testing the line only > for success). I can also guide you through that process if you prefer. Your best plan would be to work on several programs at once, because you will probably get conflicting advice. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-30 08:23 -0800 |
| Message-ID | <c3318805-6e09-4896-a45c-d780200a0045@googlegroups.com> |
| In reply to | #100658 |
On Friday, December 30, 2016 at 4:53:21 PM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Friday, December 30, 2016 at 5:02:22 AM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> > >> > On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote: > >> >> Alla _ <modelling.data@gmail.com> writes: > >> >> > > <snip> > >> It's hard for me to know how to help since I don't see the problem you > >> seem to be seeing. I don't see any need for character names at all, let > >> alone a cumbersome set of them. > >> > >> If I were teaching this on a course, I would design a series of > >> exercises that built up to what you are doing. I'm not sure you have > >> time to do it that way. > > I want to learn this correct approach to structuring my programs - you > > have been referring to it a few times already, and I did my best to follow > > your advice, but as we see I always fail due to lack of understanding and > > experience. I even have this phrase of yours "Always check input operations > > for success not failure" highlighted in one of my files. > > > > It this case, given the task I am solving, I don't see how to check the line > > only for success in succinct and logically correct way because: > > - each line has row names at the beginning, followed by 5 columns of > > numerical data (as you have, probably, seen in the inputs I have provided > > here); > > - each row name has a fairly simply format, except for two lines, which might > > have two versions - one short (just like all other rows), another long one; > > i.e. COGS can also be Cost of goods sold; > > SG&A can also be Selling, General, and Administrative (in this latter case > > I will also get surrounding double quotes) > > - all these have to occupy a contiguous space, not separated by any other > > additional characters. > > That last one seems rather strict, but if that's what you need, fine. > > > Is it possible to test this type of line only for success leaving out all other unwanted > > characters? > > Yes. That's what programming is about. A compiler like gcc is testing > something far more complex -- does the input match the rules of C's > syntax -- and it can manage it. It uses techniques that have taken > decades to develop, but the idea is the same. It does not look for > problems but simply decides there is a problem if it can't find a valid > C program. > > You will need a complex function that tests the line for having the > right format. That test will extract the data at the same time because > there is no point is determining that you have the right data without > extracting it. For example, you probably won't write the test for "a > number" yourself. Instead, you call strtod but since strtod can tell > you the number it found, you might as well store it. > > Of course, that complex function is written by calling other simpler > ones that test for the part you expect: a name, a separator, a number > and so on. > > > If yes, can I learn this in two days if I don't go any further with my > > task and concentrate only on this issue? > > I don't know. I posted some exercises in another answer. Do they look > easy or hard to you? > > > And the main most important question: do *you* have time and will to > > guide me in this process? I will be grateful for sincere answer: tell > > me yes, or tell me no > > I have the time, but I would suggest you start with simple exercises and > build up. > > > - I will definitely understand if you say no, because I know how > > tedious it is to try to teach me something at such a distance and my inability > > to dedicate enough time to all this (but if you have time, I promise not to > > go on with anything else, until I solve this matter with testing the line only > > for success). > > I can also guide you through that process if you prefer. Your best plan > would be to work on several programs at once, because you will probably > get conflicting advice. > Thank you very very much! Yes, I see those exercises above. I will start doing them, and we'll see how I fare. Now I already have: - this parsing the line program, which I hope to rewrite based on a correct approach to programming, but obviously even not dreaming to reach even a modicum close to the functionality of gcc! we are not aiming at that now, are we? ) - function to parse and store row names from the line read by the above function; - function to parse and store numbers. Technically I am set at this stage, provided I clearly understand that all of these three are corrupt, need to be reworked, and then I have to work with putting all values into a correct form (structures) to be able to process the data further; and, yes, dynamic memory allocation - I am not giving up ))) > -- > Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-30 03:50 -0800 |
| Message-ID | <48561015-9c83-48da-ba00-28fa3ebca81d@googlegroups.com> |
| In reply to | #100602 |
On Friday, December 30, 2016 at 5:02:22 AM UTC+3, Ben Bacarisse wrote: > Alla _ <modelling.data@gmail.com> writes: > > > On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote: > >> Alla _ <modelling.data@gmail.com> writes: > >> <snip> > It's hard for me to know how to help since I don't see the problem you > seem to be seeing. I don't see any need for character names at all, let > alone a cumbersome set of them. <snip> Actually the approach, which Richard has suggested to eliminate all possible \r, could be used here as well to get only the necessary input, but in that case: - the if condition will be huge to record only valid characters (isalpha, and if the row name contains commas between words, then also take into account the possibility of double quotes, etc) is accoutered; - report an error if any unwanted character is encountered while contiguously reading a file. while contiguously reading a line
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-30 13:35 +0000 |
| Message-ID | <87pok9ilpd.fsf@bsb.me.uk> |
| In reply to | #100648 |
Alla _ <modelling.data@gmail.com> writes:
> On Friday, December 30, 2016 at 5:02:22 AM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>> > On Thursday, December 29, 2016 at 2:25:21 PM UTC+3, Ben Bacarisse wrote:
>> >> Alla _ <modelling.data@gmail.com> writes:
>> >>
> <snip>
>> It's hard for me to know how to help since I don't see the problem you
>> seem to be seeing. I don't see any need for character names at all, let
>> alone a cumbersome set of them.
> <snip>
> Actually the approach, which Richard has suggested to eliminate all
> possible \r, could be used here as well to get only the necessary
> input, but in that case: - the if condition will be huge to record
> only valid characters (isalpha, and if the row name contains commas
> between words, then also take into account the possibility of double
> quotes, etc) is accoutered; - report an error if any unwanted
> character is encountered while contiguously reading a file. while
> contiguously reading a line
I'm sorry but this is very much the wrong way to look at the problem.
In my view, Richard has led you astray by providing a solution to
something that is not a problem. Now you want to extent that solution
to something that is even less of a problem.
Write the program to read the data you need. In doing so you will
automatically detect bad input because you won't find the data you
expect.
I would set a student these exercises:
1. Write a program that reads lines into a fix-size buffer (100
characters will do) and prints the average of any numbers found at the
start of a line (except for white-space). It should ignore lines that
don't start with a number. So, given
1
-2.0
xyz
7bz
it should print 2.0 ((1 - 2 + 7)/3).
2. Write another program that ignores lines that don't have just a
number on them. For the input above the 7bz line will now be ignored.
3. Write a third program that expects lines like this
3.0,2
2 ,4
1, -6.0
and prints the average of the difference between the two numbers. Any
lines that do not have the format
<spaces><number><spaces><comma><spaces><number><spaces>
(where <spaces> means zero or more white-space characters) should be
ignored.
4. Write a fourth the report the lines that don't have the correct
format.
Given that you want to use strtod, I'd also state that sscanf should not
be used (it's rather too easy with sscanf).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-30 15:22 +0000 |
| Message-ID | <o45u0v$f58$1@dont-email.me> |
| In reply to | #100656 |
On 30/12/16 13:35, Ben Bacarisse wrote: <snip> > In my view, Richard has led you astray by providing a solution to > something that is not a problem. I don't think so. The \r was causing a trailing 0 in her output. Solution: get rid of the damn thing in a data pre-processing step - that is, sanitise the data in a separate program. Easy fix. If she'd done that when I'd told her to, she could have saved herself many days of futile discussions, and she wouldn't now be involved in six or seven different conversations on the subject. > Now you want to extent that solution > to something that is even less of a problem. Yes, she had a tiny problem which was easily dealt with, but everybody wants her to turn this program into the most generic treatment of CSV files ever, instead of concentrating on meeting her spec. > Write the program to read the data you need. In doing so you will > automatically detect bad input because you won't find the data you > expect. That's fine advice as far as it goes, but it won't help her with spurious trailing 0s. > I would set a student these exercises: On this, at least, I think we can agree --- that Alla will never make any progress in C until she stops enrolling on C courses. They push her too fast in all the wrong directions. -- 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 | 2016-12-30 08:29 -0800 |
| Message-ID | <e95b7c38-4280-40a5-b117-43bce279b535@googlegroups.com> |
| In reply to | #100665 |
On Friday, December 30, 2016 at 6:22:40 PM UTC+3, Richard Heathfield wrote: > On 30/12/16 13:35, Ben Bacarisse wrote: > <snip> > > In my view, Richard has led you astray by providing a solution to > > something that is not a problem. > > I don't think so. The \r was causing a trailing 0 in her output. > Solution: get rid of the damn thing in a data pre-processing step - that > is, sanitise the data in a separate program. Easy fix. If she'd done > that when I'd told her to, she could have saved herself many days of > futile discussions, and she wouldn't now be involved in six or seven > different conversations on the subject. > > > > Now you want to extent that solution > > to something that is even less of a problem. > > Yes, she had a tiny problem which was easily dealt with, but everybody > wants her to turn this program into the most generic treatment of CSV > files ever, instead of concentrating on meeting her spec. > > > Write the program to read the data you need. In doing so you will > > automatically detect bad input because you won't find the data you > > expect. > > That's fine advice as far as it goes, but it won't help her with > spurious trailing 0s. > > > I would set a student these exercises: > > On this, at least, I think we can agree --- that Alla will never make > any progress in C until she stops enrolling on C courses. They push her > too fast in all the wrong directions. This was not a C course, but CS, a generic one, covering lots of very basic aspects, as I have tried to explain to you many times, so you will not think bad about this truly great course; it's my choice to finish the course doing the C program, because I want to to proceed with C - it's one of the best languages, it never does anything for you, and that's great; it's like the difference between driving the car with automatic transmission or with manual; I would always opt for a manual one, if I have a choice.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-30 16:51 +0000 |
| Message-ID | <87shp5gy1f.fsf@bsb.me.uk> |
| In reply to | #100665 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 30/12/16 13:35, Ben Bacarisse wrote: > <snip> >> In my view, Richard has led you astray by providing a solution to >> something that is not a problem. > > I don't think so. The \r was causing a trailing 0 in her > output. That's an odd way to put it. I'd say the input was being done incorrectly making it seem like there were more numbers than there were. If the line was processed correctly, I can't see how any number of \rs could cause any problems at all. > Solution: get rid of the damn thing in a data pre-processing > step - that is, sanitise the data in a separate program. Easy fix. If > she'd done that when I'd told her to, she could have saved herself > many days of futile discussions, and she wouldn't now be involved in > six or seven different conversations on the subject. I grant that multiple conversations are a problem. Do you have a solution to that? As for your fix, she can still do that since nothing anyone else has said will interfere with processing a \r-free file. And while the extra talk may have been distracting, she can go back to that program now if she likes. It's certainly going to be nearer to a solution than taking my approach which will be a more radical departure. >> Now you want to extent that solution >> to something that is even less of a problem. > > Yes, she had a tiny problem which was easily dealt with, but everybody > wants her to turn this program into the most generic treatment of CSV > files ever, instead of concentrating on meeting her spec. Not I. You must have forgotten the advice I gave to simplify and simplify and simplify until you can get something working. And when I posted about all the horrors of the CSV format, it was to make it plain than she should *not* try to cope with every possible variety. >> Write the program to read the data you need. In doing so you will >> automatically detect bad input because you won't find the data you >> expect. > > That's fine advice as far as it goes, but it won't help her with > spurious trailing 0s. I don't understand. If the program reads the data it needs, how can there be trailing 0s? >> I would set a student these exercises: > > On this, at least, I think we can agree Maybe she will try them. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-31 10:50 -0800 |
| Message-ID | <2ebcad56-f9e9-4494-aad2-8451d82cf52e@googlegroups.com> |
| In reply to | #100656 |
On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
<snip>
> I would set a student these exercises:
>
> 1. Write a program that reads lines into a fix-size buffer (100
> characters will do) and prints the average of any numbers found at the
> start of a line (except for white-space). It should ignore lines that
> don't start with a number. So, given
>
> 1
> -2.0
> xyz
> 7bz
>
> it should print 2.0 ((1 - 2 + 7)/3).
<snip>
Please, take a look at this version. I have tested it on several
inputs, including the one suggested by you, and each time it delivered
the result I expected. One of the comments are used is rather big, but
I did that on purpose to explain what I try to achieve.
Issues not solved yet:
1) I have not yet found the way to print ((1 - 2 + 7)/3)
2) I have not found the way to test my average function for success;
one of the options I used was if(the values of average != 0), but this
is incorrect because average can be 0.
#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_line (FILE *input_file, int *numbers, size_t *index_n);
void average(int *numbers, float *average_num, 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 )
{
int numbers[BUFFER_SIZE] = {0};
size_t index_n = 0;
float average_num;
if( !get_line(fp, numbers, &index_n) )
{
puts("Reading file failed");
fclose(fp);
return EXIT_FAILURE;
}
//DEBUG
for(size_t i = 0; i < index_n; i++)
printf("%i ", numbers[i]);
putchar('\n');
average(numbers, &average_num, index_n);
printf("The average is %.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
/***** bad test for the success of average function
if(average_num != 0)
{
printf("The average is %.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
*****/
}
//Couldn't open the file
printf("%s - %s\n", data_file, errno ? strerror(errno) : "Openfailure!");
return EXIT_FAILURE;
}
/** Function to read and process the data
from the file line by line
**/
bool get_line (FILE *input_file, int *numbers, size_t *index_n)
{
char buffer[BUFFER_SIZE] = "";
char *ptr = NULL;
char *not_converted = NULL;
int number;
size_t index_ch;
//Read each character from the file, store in a buffer
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
index_ch = 0;
//DEBUG
puts("*****************************");
printf("Buffer beg:: %s\n", buffer);
//Skip spaces at the begining of the line
while(isspace(buffer[index_ch]))
index_ch++;
/** If the first character in the buffer is a number,
or if the first character after all beginning
spaces is a number;
do not do anything in all other cases
**/
if( isdigit(buffer[index_ch])
|| (buffer[index_ch] == '-'
&& isdigit(buffer[index_ch+1])))
{
ptr = &buffer[index_ch];
number = (int)strtol(ptr, ¬_converted, 10);
if (not_converted > ptr)
{
numbers[(*index_n)++] = number;
puts("Number is parsed.");
}
}
}
if (ferror(input_file))
{
puts("The function detected an error reading a file.");
if(*index_n != 0)
printf("Last input processed was: %s\n", buffer);
return false;
}
return true;
}
/** Find the average **/
void average(int *numbers, float *average_num, size_t index)
{
float sum = 0;
for(size_t i = 0; i < index; i++)
sum += numbers[i];
*average_num = sum/index;
}
Very Happy New Year! )
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-31 19:02 +0000 |
| Message-ID | <o48v8m$bmh$1@dont-email.me> |
| In reply to | #100733 |
On 31/12/2016 18:50, Alla _ wrote: > /** Function to read and process the data > from the file line by line > **/ > > bool get_line (FILE *input_file, int *numbers, size_t *index_n) The description and the function name don't match. Does it deal with the whole file, or just a line? Does it /get/ and return the line or file, or does it do something with it here? If so, what does it do exactly? What's the format of the file? > //Read each character from the file, store in a buffer > while( fgets(buffer, sizeof(buffer), input_file) != NULL) Same here. fgets gets the next line, not the next character, and the loop presumably deals with the whole file. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-31 20:10 +0000 |
| Message-ID | <87tw9jrhac.fsf@bsb.me.uk> |
| In reply to | #100733 |
Alla _ <modelling.data@gmail.com> writes:
> On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
> <snip>
>> I would set a student these exercises:
>>
>> 1. Write a program that reads lines into a fix-size buffer (100
>> characters will do) and prints the average of any numbers found at the
>> start of a line (except for white-space). It should ignore lines that
>> don't start with a number. So, given
>>
>> 1
>> -2.0
>> xyz
>> 7bz
>>
>> it should print 2.0 ((1 - 2 + 7)/3).
> <snip>
> Please, take a look at this version. I have tested it on several
> inputs, including the one suggested by you, and each time it delivered
> the result I expected. One of the comments are used is rather big, but
> I did that on purpose to explain what I try to achieve.
> Issues not solved yet:
> 1) I have not yet found the way to print ((1 - 2 + 7)/3)
Sorry, that was by way of explanation. It should just print 2.0.
> 2) I have not found the way to test my average function for success;
> one of the options I used was if(the values of average != 0), but this
> is incorrect because average can be 0.
The average function must indicate success or failure in some way if you
are to do this. I wouldn't bother because this is intended to be an
exercise in reading numbers -- I'd just make sure I don't call the
average function unless at least one number was seen.
> #include <stdio.h>
> #include <stdlib.h>
> #include <ctype.h>
> #include <string.h>
> #include <stdbool.h>
> #include <errno.h>
You don't use errno (except for setting it) so you don't need this
file. Include it if and when you do decide you need to use errno.
> #define BUFFER_SIZE 100
> #define TEXT "../files/ex_1.csv"
>
> bool get_line (FILE *input_file, int *numbers, size_t *index_n);
> void average(int *numbers, float *average_num, 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 )
> {
> int numbers[BUFFER_SIZE] = {0};
That size is wrong. There is no connection between the maximum length
of the line and the number of lines you will process.
In fact, I had not intended that you store the numbers at all, but if
you do you should use a size with its own helpful name, even if its
value happens to be the same as BUFFER_SIZE and you must check that you
don't try to save more then will fit.
You've assumed the the input will be integers. That was my error. I
wrote 2.0 to suggest that a fraction was possible, and I mentioned using
strtod, but I should have been more explicit.
> size_t index_n = 0; float average_num;
>
> if( !get_line(fp, numbers, &index_n) )
That's a odd name since it processes a while bunch of lines rather than
just getting one.
> {
> puts("Reading file failed");
> fclose(fp);
> return EXIT_FAILURE;
> }
> //DEBUG
> for(size_t i = 0; i < index_n; i++)
> printf("%i ", numbers[i]);
> putchar('\n');
>
> average(numbers, &average_num, index_n);
Personally, I rarely waste the opportunity to return a value from a
function. The obvious return value here would be the average with the
effect that you would not need the second argument.
> printf("The average is %.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
>
> /***** bad test for the success of average function
> if(average_num != 0)
> {
> printf("The average is %.2f\n", average_num);
> fclose(fp);
> return EXIT_SUCCESS;
> }
> *****/
> }
> //Couldn't open the file
> printf("%s - %s\n", data_file, errno ? strerror(errno) : "Openfailure!");
>
> return EXIT_FAILURE;
> }
>
> /** Function to read and process the data
> from the file line by line
> **/
>
> bool get_line (FILE *input_file, int *numbers, size_t *index_n)
> {
> char buffer[BUFFER_SIZE] = "";
> char *ptr = NULL;
> char *not_converted = NULL;
> int number;
> size_t index_ch;
Earlier, you declared some objects close to where they are needed but
here you declare everything here in one go. I don't mind which you do,
but it helps the reader if you stick to one or the other.
>
> //Read each character from the file, store in a buffer
I would say that comment is wrong. It may be how you see what's
happening, but comments should be for other people. You can safely
assume that everyone reading your program knows what a while loop with
fgets in the condition is doing.
> while( fgets(buffer, sizeof(buffer), input_file) != NULL)
> {
> index_ch = 0;
>
> //DEBUG
> puts("*****************************");
> printf("Buffer beg:: %s\n", buffer);
>
> //Skip spaces at the begining of the line
> while(isspace(buffer[index_ch]))
> index_ch++;
>
> /** If the first character in the buffer is a number,
> or if the first character after all beginning
> spaces is a number;
> do not do anything in all other cases
> **/
> if( isdigit(buffer[index_ch])
> || (buffer[index_ch] == '-'
> && isdigit(buffer[index_ch+1])))
> {
> ptr = &buffer[index_ch];
> number = (int)strtol(ptr, ¬_converted, 10);
>
> if (not_converted > ptr)
> {
> numbers[(*index_n)++] = number;
> puts("Number is parsed.");
> }
> }
Skip the all that testing. strtod (and strtol) do it for you. They
will also permit more things that are numbers. Unless you have have a
very good reason to forbid them, I would permit as a number anything
that strotd will parse. That includes a leading + sign and an initial
. (as in .125) which you code above prohibits.
> }
>
> if (ferror(input_file))
It's noble that you consider file errors at all as so many people don't.
But they don't for a reason -- they are rare and testing the code is
very hard. I won't suggest you remove the code, but it's going above
and beyond what I'd expect from a student.
> {
> puts("The function detected an error reading a file.");
> if(*index_n != 0)
> printf("Last input processed was: %s\n", buffer);
A line number is usually more helpful than the line itself.
> return false;
> }
> return true;
> }
>
> /** Find the average **/
> void average(int *numbers, float *average_num, size_t index)
const int *numbers -- help the reader out.
> {
> float sum = 0;
> for(size_t i = 0; i < index; i++)
> sum += numbers[i];
>
> *average_num = sum/index;
You should test that index is not zero or (and this is perfectly valid)
document the fact that the index must be > 0 in a comment and make sure
you never call this function with index == 0.
> }
Anyway, don't worry about the volume of comments as you have basically
done this exercise. But you need to fix a few things before moving on:
(1) Use strtod to read the numbers.
(2) Use double rather than float. There is very little reason to use
float in this sort of program.
(3) Don't print anything but the average on stdout. All errors and
debugging messages should go to stderr. I like to test program
automatically and I can't do that if there is a blizzard to output
unrelated to the main objective.
(4) If you store the numbers, make sure you can't overrun the array.
(5) Simplify the scanning by letting strtod do it all.
> Very Happy New Year! )
Thanks. Same to you.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2017-01-01 04:08 -0800 |
| Message-ID | <99ecbd6a-f338-4693-bad5-ef89cbe52735@googlegroups.com> |
| In reply to | #100736 |
On Saturday, December 31, 2016 at 11:10:43 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
> > On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >>
> > <snip>
> >> I would set a student these exercises:
> >>
> >> 1. Write a program that reads lines into a fix-size buffer (100
> >> characters will do) and prints the average of any numbers found at the
> >> start of a line (except for white-space). It should ignore lines that
> >> don't start with a number. So, given
> >>
> >> 1
> >> -2.0
> >> xyz
> >> 7bz
> >>
> >> it should print 2.0 ((1 - 2 + 7)/3).
> > <snip>
<snip>
> > Issues not solved yet:
> > 1) I have not yet found the way to print ((1 - 2 + 7)/3)
>
> Sorry, that was by way of explanation. It should just print 2.0.
Still it would be interesting to found out how to print out this type
of output given the unknown number of digits and the possible
variability of their signs. Is it possible?
>
> > 2) I have not found the way to test my average function for success;
> > one of the options I used was if(the values of average != 0), but this
> > is incorrect because average can be 0.
>
> The average function must indicate success or failure in some way if you
> are to do this. I wouldn't bother because this is intended to be an
> exercise in reading numbers -- I'd just make sure I don't call the
> average function unless at least one number was seen.
I need the average function in my program anyway, if you recall the spec
I have showed. Also I believe that I might have to deal a few times
with these types of functions, which might not have a straightforward
solution for success/failure test.
Therefore, please, advice me on what approaches can be used here.
>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <ctype.h>
> > #include <string.h>
> > #include <stdbool.h>
> > #include <errno.h>
>
> You don't use errno (except for setting it) so you don't need this
> file. Include it if and when you do decide you need to use errno.
Don't I need this header if I set errno to 0?
>
A few posts ago I have written that the errno, stderr, etc are still
topics, which I don't understand, and have not yet learned about.
I have made some corrections to the code based on helpful advice
Barry has suggested, and therefore have read some material on
these topics, but those are not yet sufficient.
> > #define BUFFER_SIZE 100
<snip>
> > if ( fp )
> > {
> > int numbers[BUFFER_SIZE] = {0};
>
> That size is wrong. There is no connection between the maximum length
> of the line and the number of lines you will process.
>
> In fact, I had not intended that you store the numbers at all, but if
> you do you should use a size with its own helpful name, even if its
> value happens to be the same as BUFFER_SIZE and you must check that you
> don't try to save more then will fit.
I have corrected the size. But: yes, I can't figure out how to work with the
input without first reading it into the buffer, and then taking only valid
characters out of that buffer. I have tried it not only for this exercise,
but I don't see the solution yet. Still waiting to get to my "aha" moment.
I assume it will make the code more clear.
>
> You've assumed the the input will be integers. That was my error. I
> wrote 2.0 to suggest that a fraction was possible, and I mentioned using
> strtod, but I should have been more explicit.
No, this was my error in the code. I have clearly understood that I need
to write a program that will process floats; I have unintentionally
used the type int for numbers array. I'd say it's a typo.
>
> > size_t index_n = 0; float average_num;
> >
> > if( !get_line(fp, numbers, &index_n) )
>
> That's a odd name since it processes a while bunch of lines rather than
> just getting one.
it's get_lines now )
>
<snip>
> >
> > average(numbers, &average_num, index_n);
>
> Personally, I rarely waste the opportunity to return a value from a
> function. The obvious return value here would be the average with the
> effect that you would not need the second argument.
My first version returned the average, but then I changed it into a
pointer recalling that pointers are revered in C. Also not to waste
any opportunity to train the usage of pointers.
Corrected now back to returning the average.
<snip>
> > bool get_line (FILE *input_file, int *numbers, size_t *index_n)
> > {
> > char buffer[BUFFER_SIZE] = "";
> > char *ptr = NULL;
> > char *not_converted = NULL;
> > int number;
> > size_t index_ch;
>
> Earlier, you declared some objects close to where they are needed but
> here you declare everything here in one go. I don't mind which you do,
> but it helps the reader if you stick to one or the other.
>
I see. I have moved some declarations close to place of usage. Is this what
you mean? (I will post the whole code below, here just corrected parts).
Edit after reading the whole post: I have deleted all testing, see at the end
of the post; but here I still have them to make sure I have correctly
understood you.
/** Process the data only if the buffer has valid
input
**/
if( isdigit(buffer[index_ch])
|| (buffer[index_ch] == '-'
&& isdigit(buffer[index_ch+1])))
{
char *ptr = &buffer[index_ch];
char *not_converted = NULL;
double number = (double)strtod(ptr, ¬_converted);
if (not_converted > ptr)
{
numbers[(*index_n)++] = number;
puts("Number is parsed.");
}
}
> >
> > //Read each character from the file, store in a buffer
>
> I would say that comment is wrong. It may be how you see what's
> happening, but comments should be for other people. You can safely
> assume that everyone reading your program knows what a while loop with
> fgets in the condition is doing.
I see. Does this one sound better:
//Parse file data, store only numbers
>
> > while( fgets(buffer, sizeof(buffer), input_file) != NULL)
<snip>
> > if( isdigit(buffer[index_ch])
> > || (buffer[index_ch] == '-'
> > && isdigit(buffer[index_ch+1])))
> > {
> > ptr = &buffer[index_ch];
> > number = (int)strtol(ptr, ¬_converted, 10);
> >
> > if (not_converted > ptr)
> > {
> > numbers[(*index_n)++] = number;
> > puts("Number is parsed.");
> > }
> > }
>
> Skip the all that testing. strtod (and strtol) do it for you. They
> will also permit more things that are numbers. Unless you have have a
> very good reason to forbid them, I would permit as a number anything
> that strotd will parse. That includes a leading + sign and an initial
> . (as in .125) which you code above prohibits.
>
> > }
> >
> > if (ferror(input_file))
>
> It's noble that you consider file errors at all as so many people don't.
> But they don't for a reason -- they are rare and testing the code is
> very hard. I won't suggest you remove the code, but it's going above
> and beyond what I'd expect from a student.
Then in this case let's not treat me as a student ))) I am happy
to learn and develop good habits, even if they might be more sophisticated at
this point. It is important for me. Please, consider not "protecting" me
from these type of essential features.
>
> > {
> > puts("The function detected an error reading a file.");
> > if(*index_n != 0)
> > printf("Last input processed was: %s\n", buffer);
>
> A line number is usually more helpful than the line itself.
>
> > return false;
> > }
> > return true;
> > }
> >
> > /** Find the average **/
> > void average(int *numbers, float *average_num, size_t index)
>
> const int *numbers -- help the reader out.
>
> > {
> > float sum = 0;
> > for(size_t i = 0; i < index; i++)
> > sum += numbers[i];
> >
> > *average_num = sum/index;
>
> You should test that index is not zero or (and this is perfectly valid)
> document the fact that the index must be > 0 in a comment and make sure
> you never call this function with index == 0.
The reason I have not tested the index is because I call the average function
only if the get_lines (new name with -s at the end :) ) is successful, and
therefore index cannot be zero. Why is this assumption incorrect?
I have added the test now, see below in the whole program.
>
> > }
>
> Anyway, don't worry about the volume of comments as you have basically
> done this exercise. But you need to fix a few things before moving on:
>
> (1) Use strtod to read the numbers.
done
>
> (2) Use double rather than float. There is very little reason to use
> float in this sort of program.
done
>
> (3) Don't print anything but the average on stdout. All errors and
> debugging messages should go to stderr.
As I have noted above it is still a conundrum for me, I have to learn
what stderr exactly is, what is happening underneath the hood,
and how to see its messages, even though I know when and how
to use some pieces of code that include stderr.
> I like to test program
> automatically and I can't do that if there is a blizzard to output
> unrelated to the main objective.
>
> (4) If you store the numbers, make sure you can't overrun the array.
done, but still would like to learn how not to store the input in additional
array
>
> (5) Simplify the scanning by letting strtod do it all.
done
>
> > Very Happy New Year! )
>
> Thanks. Same to you.
Thank you )
Here is the corrected version:
#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) )
{
puts("Reading file failed");
fclose(fp);
return EXIT_FAILURE;
}
if(index_n > 0)
{
average_num = average(numbers, index_n);
printf("The average is %.2f\n", average_num);
fclose(fp);
return EXIT_SUCCESS;
}
}
//Couldn't open the file
printf("%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 index_ch;
size_t line = 0;
//Parse file data, store only numbers
while( fgets(buffer, sizeof(buffer), input_file) != NULL)
{
line++;
index_ch = 0;
//Skip spaces at the begining of the line
while(isspace(buffer[index_ch]))
index_ch++;
char *ptr = &buffer[index_ch];
char *not_converted = NULL;
double number = (double)strtod(ptr, ¬_converted);
if (not_converted > ptr && *index_n < NUMBERS)
numbers[(*index_n)++] = number;
}
if (ferror(input_file))
{
puts("The function detected an error reading a file.");
if(*index_n != 0)
printf("Last input processed was at line '%zu': %s\n", line, buffer);
return false;
}
return true;
}
/** Find the average **/
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;
}
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-01-01 12:38 +0000 |
| Message-ID | <o4at68$342$1@dont-email.me> |
| In reply to | #100765 |
On 01/01/17 12:08, Alla _ wrote:
> On Saturday, December 31, 2016 at 11:10:43 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>>> On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
>>>> Alla _ <modelling.data@gmail.com> writes:
>>>>
>>> <snip>
>>>> I would set a student these exercises:
>>>>
>>>> 1. Write a program that reads lines into a fix-size buffer (100
>>>> characters will do) and prints the average of any numbers found at the
>>>> start of a line (except for white-space). It should ignore lines that
>>>> don't start with a number. So, given
>>>>
>>>> 1
>>>> -2.0
>>>> xyz
>>>> 7bz
>>>>
>>>> it should print 2.0 ((1 - 2 + 7)/3).
>>> <snip>
> <snip>
>>> Issues not solved yet:
>>> 1) I have not yet found the way to print ((1 - 2 + 7)/3)
>>
>> Sorry, that was by way of explanation. It should just print 2.0.
>
> Still it would be interesting to found out how to print out this type
> of output given the unknown number of digits and the possible
> variability of their signs. Is it possible?
Yes, of course it's possible, but it's completely outside the remit of
the spec. It's because you keep flying off at tangents that you never
learn anything.
> I need the average function in my program anyway,
Not in Ben's challenge, you don't.
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
double d = 0.0;
double endptr = 0.0;
double average = 0.0;
unsigned long int n = 0;
char line[100] = "";
while(fgets(line, sizeof line, stdin) != NULL)
{
d = strtod(line, &endptr);
if(endptr > d)
{
average = (d + n * average) / (n + 1);
}
}
printf("%f\n", average);
return 0;
}
Your solution had hundreds of lines. The above has 21 lines, and a tiny
handful of statements. |This is the kind of simplicity for which you
should be striving.
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-01-01 13:45 +0000 |
| Message-ID | <o4b139$fps$1@dont-email.me> |
| In reply to | #100770 |
On 01/01/2017 12:38, Richard Heathfield wrote:
> On 01/01/17 12:08, Alla _ wrote:
>> On Saturday, December 31, 2016 at 11:10:43 PM UTC+3, Ben Bacarisse wrote:
>>> Alla _ <modelling.data@gmail.com> writes:
>>>
>>>> On Friday, December 30, 2016 at 4:35:33 PM UTC+3, Ben Bacarisse wrote:
>>>>> Alla _ <modelling.data@gmail.com> writes:
>>>>>
>>>> <snip>
>>>>> I would set a student these exercises:
>>>>>
>>>>> 1. Write a program that reads lines into a fix-size buffer (100
>>>>> characters will do) and prints the average of any numbers found at the
>>>>> start of a line (except for white-space). It should ignore lines that
>>>>> don't start with a number. So, given
>>>>>
>>>>> 1
>>>>> -2.0
>>>>> xyz
>>>>> 7bz
>>>>>
>>>>> it should print 2.0 ((1 - 2 + 7)/3).
>>>> <snip>
>> <snip>
>>>> Issues not solved yet:
>>>> 1) I have not yet found the way to print ((1 - 2 + 7)/3)
>>>
>>> Sorry, that was by way of explanation. It should just print 2.0.
>>
>> Still it would be interesting to found out how to print out this type
>> of output given the unknown number of digits and the possible
>> variability of their signs. Is it possible?
>
> Yes, of course it's possible, but it's completely outside the remit of
> the spec. It's because you keep flying off at tangents that you never
> learn anything.
>
>> I need the average function in my program anyway,
>
> Not in Ben's challenge, you don't.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> double d = 0.0;
> double endptr = 0.0;
> double average = 0.0;
> unsigned long int n = 0;
> char line[100] = "";
> while(fgets(line, sizeof line, stdin) != NULL)
> {
> d = strtod(line, &endptr);
> if(endptr > d)
> {
> average = (d + n * average) / (n + 1);
> }
> }
> printf("%f\n", average);
> return 0;
> }
>
> Your solution had hundreds of lines. The above has 21 lines, and a tiny
> handful of statements. |This is the kind of simplicity for which you
> should be striving.
Does your code work? I'm getting results of 0.0.
The &endptr is supposed to be char** in the specs.
The value of n doesn't appear to change from 0.
I tweaked it a bit to fix that, and only summed the values, then worked
out the average at the end.
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web