Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126692 > unrolled thread
| Started by | G B <gb@gb.com> |
|---|---|
| First post | 2018-02-14 11:47 -0400 |
| Last post | 2018-02-25 20:12 +0000 |
| Articles | 20 on this page of 168 — 30 participants |
Back to article view | Back to comp.lang.c
Text Files G B <gb@gb.com> - 2018-02-14 11:47 -0400
Re: Text Files Ed Prochak <edprochak@gmail.com> - 2018-02-14 08:45 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-14 08:47 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-15 01:17 -0800
Re: Text Files gordonb.ea2mq@burditt.org (Gordon Burditt) - 2018-02-14 11:10 -0600
Re: Text Files "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-14 12:28 -0500
Re: Text Files jt@toerring.de (Jens Thoms Toerring) - 2018-02-14 21:07 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-14 15:31 -0700
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-15 06:59 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 10:20 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-14 22:51 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 11:04 +0100
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-15 06:16 -0800
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:22 +0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 15:58 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 16:31 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:31 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:21 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:17 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:36 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:48 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:09 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:57 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 15:50 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 15:50 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:07 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:44 +0000
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:22 +1300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 17:48 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-16 17:06 +0100
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 11:10 +1300
Re: Text Files supercat@casperkitty.com - 2018-02-16 14:48 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-16 15:14 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 23:25 +0000
Re: Text Files supercat@casperkitty.com - 2018-02-16 15:50 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-16 07:19 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 17:13 +0100
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-19 17:55 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-19 19:14 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-19 11:48 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 08:14 -0800
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-17 18:32 -0600
Re: Text Files jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-15 22:57 +0100
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 22:58 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 00:19 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 02:26 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 02:57 +0000
Re: Text Files asetofsymbols@gmail.com - 2018-02-16 00:21 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:30 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:36 +0100
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 11:36 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 13:10 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 12:25 +0000
Re: Text Files Ike Naar <ike@iceland.freeshell.org> - 2018-03-06 19:33 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-03-06 20:55 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:42 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 16:58 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 20:02 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 21:43 +0100
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:01 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 13:10 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 05:27 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 14:20 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-16 09:04 -0700
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 14:31 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 06:42 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-16 14:58 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 07:23 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-16 15:24 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-16 04:13 -0800
Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-16 04:29 -0800
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 16:41 +0000
Re: Text Files Siri Cruise <chine.bleu@yahoo.com> - 2018-02-20 09:39 -0800
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-20 19:16 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 12:46 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 14:52 +0100
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 17:07 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 14:23 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-15 18:52 +0300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 14:39 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 15:43 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 20:32 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 22:06 +0000
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-15 23:12 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 15:12 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 23:43 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:54 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 23:35 +0000
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-16 17:07 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 02:38 +0000
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-17 17:26 +1300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-17 11:22 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-17 12:07 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 04:17 -0800
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-17 16:25 +0300
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-17 07:35 -0800
Re: Text Files GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-17 15:24 +0100
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-18 11:10 +1300
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-19 12:05 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-19 15:32 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 10:34 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-21 15:35 -0800
Re: Text Files bartc <bc@freeuk.com> - 2018-02-22 00:11 +0000
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-21 18:26 -0600
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-21 21:39 -0800
Re: Text Files Robert Wessel <robertwessel2@yahoo.com> - 2018-02-23 03:08 -0600
Re: Text Files supercat@casperkitty.com - 2018-02-23 16:16 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-23 16:46 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-24 02:49 -0800
Re: Text Files asetofsymbols@gmail.com - 2018-02-24 05:16 -0800
Re: Text Files "F. Russell" <fr@random.info> - 2018-02-24 14:35 +0000
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-24 08:48 -0700
Re: Text Files supercat@casperkitty.com - 2018-02-25 15:09 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:54 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-26 11:04 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 11:52 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-26 14:12 -0800
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 14:40 -0800
Re: Text Files already5chosen@yahoo.com - 2018-02-22 04:58 -0800
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 05:33 -0800
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-22 13:59 +0000
Re: Text Files Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-22 07:24 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-20 12:14 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-15 21:37 +0100
Re: Text Files bartc <bc@freeuk.com> - 2018-02-15 21:34 +0000
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-15 14:15 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-16 10:47 +0100
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-15 22:20 +0800
Re: Text Files "F. Russell" <fr@random.info> - 2018-02-15 15:24 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-15 16:05 +0000
Re: Text Files "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-16 00:22 +0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-15 13:35 -0700
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 00:13 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-24 21:24 +0000
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 14:55 +0300
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 13:00 +0000
Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:35 -0400
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 21:36 +0000
Re: Text Files Real Troll <Real.Troll@Trolls.com> - 2018-02-24 17:45 -0400
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-24 22:51 +0000
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-24 23:56 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:14 +0000
Re: Text Files bartc <bc@freeuk.com> - 2018-02-25 00:22 +0000
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:16 +0300
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-25 15:20 -0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-25 20:27 -0700
Re: Text Files gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 06:19 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 15:35 +0300
Re: Text Files Reinhardt Behm <rbehm@hushmail.com> - 2018-02-26 20:53 +0800
Grammar Patrol (Was: Text Files) gazelle@shell.xmission.com (Kenny McCormack) - 2018-02-26 17:54 +0000
Re: Text Files Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-26 15:27 +0000
Re: Text Files Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-02-26 18:50 +0300
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:26 -0800
Re: Text Files scott@slp53.sl.home (Scott Lurndal) - 2018-02-26 19:46 +0000
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 09:04 +0100
Re: Text Files already5chosen@yahoo.com - 2018-02-27 00:56 -0800
Re: Text Files Ian Collins <ian-news@hotmail.com> - 2018-02-27 22:07 +1300
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 14:37 +0100
Re: Text Files already5chosen@yahoo.com - 2018-02-27 07:38 -0800
Re: Text Files supercat@casperkitty.com - 2018-02-27 09:18 -0800
Re: Text Files David Brown <david.brown@hesbynett.no> - 2018-02-27 10:15 +0100
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-27 08:53 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 23:14 -0800
Re: Text Files Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-26 08:32 -0700
Re: Text Files Keith Thompson <kst-u@mib.org> - 2018-02-26 09:17 -0800
Re: Text Files Tim Rentsch <txr@alumni.caltech.edu> - 2018-02-26 22:55 -0800
Re: Text Files Anton Shepelev <anton.txt@gmail.com> - 2018-02-25 15:02 +0300
Re: Text Files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-25 20:12 +0000
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-17 13:10 +0000 |
| Message-ID | <kRVhC.116098$BM3.41285@fx14.am4> |
| In reply to | #126827 |
On 17/02/2018 12:01, Malcolm McLean wrote: > On Friday, February 16, 2018 at 3:59:04 PM UTC, David Brown wrote: > If you write Python like C, however, you get a reasonably fast and > comprehensible function. A few years I posted a tokeniser program in Python to comp.lang.python. It was clunkily written, and was really just a port of a program I might equally have written it C. It was picked on for being crude and non-Pythonic. The way to do it was apparently with Python's built-in regular expression library, which is implemented in C so ought to be very fast compared with pure Python byte-code. But when it was tested against such a tokeniser, my version was double the speed! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-02-17 05:27 -0800 |
| Message-ID | <7a09385c-4611-4c77-9ce7-dfa43e1ce3f7@googlegroups.com> |
| In reply to | #126832 |
On Saturday, February 17, 2018 at 1:10:51 PM UTC, Bart wrote: > On 17/02/2018 12:01, Malcolm McLean wrote: > > On Friday, February 16, 2018 at 3:59:04 PM UTC, David Brown wrote: > > > If you write Python like C, however, you get a reasonably fast and > > comprehensible function. > > A few years I posted a tokeniser program in Python to comp.lang.python. > > It was clunkily written, and was really just a port of a program I might > equally have written it C. > > It was picked on for being crude and non-Pythonic. The way to do it was > apparently with Python's built-in regular expression library, which is > implemented in C so ought to be very fast compared with pure Python > byte-code. > > But when it was tested against such a tokeniser, my version was double > the speed! > If you restrict yourself to the C-like subset of Python then it's not surprising that you can get comparable performance. But it's fair enough to say that that's not what Python is really for - a C clone with an interpreter as standard and slightly different syntax. Regular expressions are more flexible than a hard-coded tokeniser, in fact too flexible - expressions rapidly reach the level of complexity whereby they have to be tested and debugged as programs in their own right.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-17 14:20 +0000 |
| Message-ID | <GSWhC.107812$VP3.48806@fx06.am4> |
| In reply to | #126834 |
On 17/02/2018 13:27, Malcolm McLean wrote: > On Saturday, February 17, 2018 at 1:10:51 PM UTC, Bart wrote: >> On 17/02/2018 12:01, Malcolm McLean wrote: >>> On Friday, February 16, 2018 at 3:59:04 PM UTC, David Brown wrote: >> >>> If you write Python like C, however, you get a reasonably fast and >>> comprehensible function. >> >> A few years I posted a tokeniser program in Python to comp.lang.python. >> >> It was clunkily written, and was really just a port of a program I might >> equally have written it C. >> >> It was picked on for being crude and non-Pythonic. The way to do it was >> apparently with Python's built-in regular expression library, which is >> implemented in C so ought to be very fast compared with pure Python >> byte-code. >> >> But when it was tested against such a tokeniser, my version was double >> the speed! >> > If you restrict yourself to the C-like subset of Python then it's > not surprising that you can get comparable performance. This was not C vs Python. With the same basic steps in both languages, the Python might be a couple of magnitudes slower. (It's making use of fast library functions and using built-in functionality both written in C that keeps Python usable.) This was Python vs Python. One with simple steps that mean executing lots of byte-code, compared the other executing C library functions. The byte-code version was faster. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2018-02-16 09:04 -0700 |
| Message-ID | <1btvug6hv8.fsf@pfeifferfamily.net> |
| In reply to | #126787 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > Note also that the C is more self-documenting. The Python is > essentially meaningless to a non-Python programmer, just a series > of square brackets with a contained for loop which could mean > anything. The C should be more or less readable to anyone who > knows any programming language - the exception being the fread > call. Don't be ridiculous. The C is 'more or less' readable to anyone who knows any programming language with a syntax similar to C. Someone who knows nothing but Python will find the C version just as unreadable as a C-only programmer will find the Python code.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-16 14:31 +0000 |
| Message-ID | <8737213t0w.fsf@bsb.me.uk> |
| In reply to | #126783 |
David Brown <david.brown@hesbynett.no> writes:
> On 16/02/18 12:36, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 16/02/18 01:19, bartc wrote:
>>>> On 15/02/2018 22:58, Ben Bacarisse wrote:
>>>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>>>
>>>>>> That last one is difficult to beat.
>>>>>
>>>>> Yes, I know what C's good at, but I was asking the OP. It's possible
>>>>> that none of that matters to them. It could be a quick throwaway
>>>>> program to find the line with the widest range:
>>>>>
>>>>> awk 'NF==6 { if ($6-$1 > r) { r = $6-$1; ln = NR }} END { print ln }'
>>>>>
>>>>> I'm shameless enough to say that I'm a pretty fast C programmer but,
>>>>> none the less, I'd write that sort of thing in AWK every time.
>>>>>
>>>>>> C is fast. Fast because it is just an abstraction of the machine.
>>>>>
>>>>> I changed my C version to do this calculation and found that the AWK
>>>>> version was faster.
>>>>
>>>> So, the task is to find the line where column 6 is bigger than column 1
>>>> by the maximum amount?
>>>>
>>>> I tried your code in gawk, on a 1-million line input file containing 6
>>>> columns of random numbers from 1 to 100,000.
>>>>
>>>> Gawk took 1.64 seconds.
>>>>
>>>> Then I threw something together with my scripting language, and it took
>>>> 1.50 seconds at the first attempt [code shown in my sig].
>>>
>>> Since we are having fun, I tested a simple python implementation.
>>>
>>> awk took 0.44s.
>>> Python2 and Python3 both took 0.9 seconds.
>>> pypy (JIT compiled python) took 0.37 seconds.
>>>
>>> All this shows that for a task like this, many languages are within
>>> spitting distance of the speed of C,
>>
>> I don't see how you can say that without a C data point on the same
>> machine. And, being very flexible, C code comes in with very different
>> timings depending on the exact job being done (for the "max range"
>> problem I got a fact of 10 between two simple C programs).
>
> "Within spitting distance" does not mean the same speed.
Yes, but I got about a factor 10. That's a long way to spit!
> It means fast
> enough to be usable for the same sort of task.
I don't think you can call that "within spitting distance". I'd take
anything from 0.01s to 10s for a once-off data analysis task, but I
would not call that within spitting distance in terms of speed.
If you want to try a C version to get a reference point for the other
times, this is the crudest, but fastest one I tried:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(void)
{
char line[1000];
size_t lnum = 0, lmax;
long int max = 0;
while (fgets(line, sizeof line, stdin)) {
lnum += 1;
long int d = strtol(strrchr(line, ' '), 0, 10) - strtol(line, 0, 10);
if (d > max) {
max = d;
lmax = lnum;
}
}
printf("%lu (%ld)\n", (unsigned long)lmax, max);
}
<snip>
> What we have shown in these few posts is that when you want to analyse
> lines of a text file with integer data, a language like Python (or awk,
> if the problem is simple enough, or even Bart's scripting language if he
> is the one solving the problem) is likely to give you a solid fraction
> of the speed of C with vastly less development effort.
Yes. What's more A quickly written C solution will be inflexible. More
and more work is needed to be able to alter the question you ask about
the data or to change the amount of checking applied to the input. Such
changes are usually quite small in languages aimed at this sort of task.
If I already had a collection of C functions to split lines on various
criteria and to convert text to numbers with proper error checking along
with some sort of fast associative array, I would consider using that
for large data sets, but there will always be a new question to be asked
of the data that will be more quickly answered with a slow AWK script.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-02-16 06:42 -0800 |
| Message-ID | <cca729a8-1d60-4eb8-ab55-2bb4bad2ba66@googlegroups.com> |
| In reply to | #126789 |
On Friday, February 16, 2018 at 2:31:59 PM UTC, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
> > On 16/02/18 12:36, Ben Bacarisse wrote:
> >> David Brown <david.brown@hesbynett.no> writes:
> >>
> >>> On 16/02/18 01:19, bartc wrote:
> >>>> On 15/02/2018 22:58, Ben Bacarisse wrote:
> >>>>> jacobnavia <jacob@jacob.remcomp.fr> writes:
> >>>>
> >>>>>> That last one is difficult to beat.
> >>>>>
> >>>>> Yes, I know what C's good at, but I was asking the OP. It's possible
> >>>>> that none of that matters to them. It could be a quick throwaway
> >>>>> program to find the line with the widest range:
> >>>>>
> >>>>> awk 'NF==6 { if ($6-$1 > r) { r = $6-$1; ln = NR }} END { print ln }'
> >>>>>
> >>>>> I'm shameless enough to say that I'm a pretty fast C programmer but,
> >>>>> none the less, I'd write that sort of thing in AWK every time.
> >>>>>
> >>>>>> C is fast. Fast because it is just an abstraction of the machine.
> >>>>>
> >>>>> I changed my C version to do this calculation and found that the AWK
> >>>>> version was faster.
> >>>>
> >>>> So, the task is to find the line where column 6 is bigger than column 1
> >>>> by the maximum amount?
> >>>>
> >>>> I tried your code in gawk, on a 1-million line input file containing 6
> >>>> columns of random numbers from 1 to 100,000.
> >>>>
> >>>> Gawk took 1.64 seconds.
> >>>>
> >>>> Then I threw something together with my scripting language, and it took
> >>>> 1.50 seconds at the first attempt [code shown in my sig].
> >>>
> >>> Since we are having fun, I tested a simple python implementation.
> >>>
> >>> awk took 0.44s.
> >>> Python2 and Python3 both took 0.9 seconds.
> >>> pypy (JIT compiled python) took 0.37 seconds.
> >>>
> >>> All this shows that for a task like this, many languages are within
> >>> spitting distance of the speed of C,
> >>
> >> I don't see how you can say that without a C data point on the same
> >> machine. And, being very flexible, C code comes in with very different
> >> timings depending on the exact job being done (for the "max range"
> >> problem I got a fact of 10 between two simple C programs).
> >
> > "Within spitting distance" does not mean the same speed.
>
> Yes, but I got about a factor 10. That's a long way to spit!
>
> > It means fast
> > enough to be usable for the same sort of task.
>
> I don't think you can call that "within spitting distance". I'd take
> anything from 0.01s to 10s for a once-off data analysis task, but I
> would not call that within spitting distance in terms of speed.
>
> If you want to try a C version to get a reference point for the other
> times, this is the crudest, but fastest one I tried:
>
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
>
> int main(void)
> {
> char line[1000];
> size_t lnum = 0, lmax;
> long int max = 0;
> while (fgets(line, sizeof line, stdin)) {
> lnum += 1;
> long int d = strtol(strrchr(line, ' '), 0, 10) - strtol(line, 0, 10);
> if (d > max) {
> max = d;
> lmax = lnum;
> }
> }
> printf("%lu (%ld)\n", (unsigned long)lmax, max);
> }
>
0.160 seconds on my machine.
gcc =O3
time cat numbers.txt | ./a.out to evoke (maybe not optimal?)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-16 14:58 +0000 |
| Message-ID | <0kChC.496666$w26.25695@fx47.am4> |
| In reply to | #126790 |
On 16/02/2018 14:42, Malcolm McLean wrote:
> On Friday, February 16, 2018 at 2:31:59 PM UTC, Ben Bacarisse wrote:
>> If you want to try a C version to get a reference point for the other
>> times, this is the crudest, but fastest one I tried:
>>
>> #include <stdio.h>
>> #include <string.h>
>> #include <stdlib.h>
>>
>> int main(void)
>> {
>> char line[1000];
>> size_t lnum = 0, lmax;
>> long int max = 0;
>> while (fgets(line, sizeof line, stdin)) {
>> lnum += 1;
>> long int d = strtol(strrchr(line, ' '), 0, 10) - strtol(line, 0, 10);
>> if (d > max) {
>> max = d;
>> lmax = lnum;
>> }
>> }
>> printf("%lu (%ld)\n", (unsigned long)lmax, max);
>> }
>>
> 0.160 seconds on my machine.
> gcc =O3
> time cat numbers.txt | ./a.out to evoke (maybe not optimal?)
>
How many lines in the input?
I test with a one-million-line, 37MB input, and I got these timings for
various 64-bit compilers, with whatever optimisation is available:
Pelles C 0.58 seconds
Lccwin 0.58
DMC 0.48 (32 bits)
gcc/tdm 0.37 5.1.0
Tiny C 0.36
MSVC 0.42
Mcc 0.39 (my compiler)
Interestingly, Tiny C was the fastest, beating gcc. (But only just as
there is some variability; timings shown are the most consistent.)
Using my parser-based version (or tokeniser really), gcc took 0.22
seconds. Tcc took 1.44 seconds on that one; presumably there was some
real code to deal with rather than just calls to library functions. [But
also, this program uses switch heavily and tcc is poor with that.]
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-02-16 07:23 -0800 |
| Message-ID | <bab5cbba-d91d-4aca-8d48-d4858857d6df@googlegroups.com> |
| In reply to | #126792 |
On Friday, February 16, 2018 at 2:58:14 PM UTC, Bart wrote:
> On 16/02/2018 14:42, Malcolm McLean wrote:
> > On Friday, February 16, 2018 at 2:31:59 PM UTC, Ben Bacarisse wrote:
>
> >> If you want to try a C version to get a reference point for the other
> >> times, this is the crudest, but fastest one I tried:
> >>
> >> #include <stdio.h>
> >> #include <string.h>
> >> #include <stdlib.h>
> >>
> >> int main(void)
> >> {
> >> char line[1000];
> >> size_t lnum = 0, lmax;
> >> long int max = 0;
> >> while (fgets(line, sizeof line, stdin)) {
> >> lnum += 1;
> >> long int d = strtol(strrchr(line, ' '), 0, 10) - strtol(line, 0, 10);
> >> if (d > max) {
> >> max = d;
> >> lmax = lnum;
> >> }
> >> }
> >> printf("%lu (%ld)\n", (unsigned long)lmax, max);
> >> }
> >>
> > 0.160 seconds on my machine.
> > gcc =O3
> > time cat numbers.txt | ./a.out to evoke (maybe not optimal?)
> >
>
> How many lines in the input?
>
A million, as for you. But I'm using a Mac mini.
(Incidentally there's no performance penalty in catting
to stdin rather than going through a file, mine is still
running at 0.050 seconds when I rewrite it to use stdin).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-16 15:24 +0000 |
| Message-ID | <87r2pl2c0k.fsf@bsb.me.uk> |
| In reply to | #126790 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: <snip> > 0.160 seconds on my machine. > gcc =O3 > time cat numbers.txt | ./a.out to evoke (maybe not optimal?) time ./a.out <number.txt would be more accurate though cat will be very fast on most modern systems. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-02-16 04:13 -0800 |
| Message-ID | <00b32aa2-ad11-4c87-90f3-43910bbde219@googlegroups.com> |
| In reply to | #126782 |
On Friday, February 16, 2018 at 11:37:07 AM UTC, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
> > On 16/02/18 01:19, bartc wrote:
> >> On 15/02/2018 22:58, Ben Bacarisse wrote:
> >>> jacobnavia <jacob@jacob.remcomp.fr> writes:
> >>
> >>>> That last one is difficult to beat.
> >>>
> >>> Yes, I know what C's good at, but I was asking the OP. It's possible
> >>> that none of that matters to them. It could be a quick throwaway
> >>> program to find the line with the widest range:
> >>>
> >>> awk 'NF==6 { if ($6-$1 > r) { r = $6-$1; ln = NR }} END { print ln }'
> >>>
> >>> I'm shameless enough to say that I'm a pretty fast C programmer but,
> >>> none the less, I'd write that sort of thing in AWK every time.
> >>>
> >>>> C is fast. Fast because it is just an abstraction of the machine.
> >>>
> >>> I changed my C version to do this calculation and found that the AWK
> >>> version was faster.
> >>
> >> So, the task is to find the line where column 6 is bigger than column 1
> >> by the maximum amount?
> >>
> >> I tried your code in gawk, on a 1-million line input file containing 6
> >> columns of random numbers from 1 to 100,000.
> >>
> >> Gawk took 1.64 seconds.
> >>
> >> Then I threw something together with my scripting language, and it took
> >> 1.50 seconds at the first attempt [code shown in my sig].
> >
> > Since we are having fun, I tested a simple python implementation.
> >
> > awk took 0.44s.
> > Python2 and Python3 both took 0.9 seconds.
> > pypy (JIT compiled python) took 0.37 seconds.
> >
> > All this shows that for a task like this, many languages are within
> > spitting distance of the speed of C,
>
> I don't see how you can say that without a C data point on the same
> machine. And, being very flexible, C code comes in with very different
> timings depending on the exact job being done (for the "max range"
> problem I got a fact of 10 between two simple C programs).
>
I just wrote a C program to generate a million lines of 6 2 digit integers.
Compiling with gcc scratch.c - no optimisation - it took 0.5 seconds.
So the speed of analysis exceeds the speed of data generation, unless
the values come from something like a seisometer.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2018-02-16 04:29 -0800 |
| Message-ID | <chine.bleu-486BF0.04285416022018@reader.eternal-september.org> |
| In reply to | #126784 |
In article <00b32aa2-ad11-4c87-90f3-43910bbde219@googlegroups.com>, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > > I don't see how you can say that without a C data point on the same > > machine. And, being very flexible, C code comes in with very different > > timings depending on the exact job being done (for the "max range" > > problem I got a fact of 10 between two simple C programs). > > > I just wrote a C program to generate a million lines of 6 2 digit integers. > Compiling with gcc scratch.c - no optimisation - it took 0.5 seconds. I just spent a couple of weeks debugging 10,000 line bash scripts in that abnomation known as 'configure'. For one the trick was to unset LD before the configure. I don't think C would be signficantly faster but I do think C code would be a hell of easier to debug. Or Python or Ruby or Tcl or ...? But not awk. Awk liek bash is good for something short, but when half your code is devoted to escaping nested quote hell, yes, you're doing it wrong. Most code is only used a few times then trashed where development cost far outweighs execution cost. For code that lasts maintenance cost usually outweighs execution cost. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ I'm saving up to buy the Donald a blue stone This post / \ from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-02-20 16:41 +0000 |
| Message-ID | <slrnp8oju8.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #126786 |
On Fri, 2018-02-16, Siri Cruise wrote: > In article <00b32aa2-ad11-4c87-90f3-43910bbde219@googlegroups.com>, > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > >> > I don't see how you can say that without a C data point on the same >> > machine. And, being very flexible, C code comes in with very different >> > timings depending on the exact job being done (for the "max range" >> > problem I got a fact of 10 between two simple C programs). >> > >> I just wrote a C program to generate a million lines of 6 2 digit integers. >> Compiling with gcc scratch.c - no optimisation - it took 0.5 seconds. > > I just spent a couple of weeks debugging 10,000 line bash scripts in that > abnomation known as 'configure'. For one the trick was to unset LD before the > configure. > > I don't think C would be signficantly faster but I do think C code would be a > hell of easier to debug. Or Python or Ruby or Tcl or ...? Shell scripts are good at running other programs; the others you listed are not, except Tcl maybe. > But not awk. Awk liek bash is good for something short, but when > half your code is devoted to escaping nested quote hell, yes, you're > doing it wrong. Aren't configure scripts written in /bin/sh rather than Bash? Bash is much better for large programs than what Bourne shell was. But probably the configure script would have been awful in Bash, too. > Most code is only used a few times then trashed where development > cost far outweighs execution cost. For code that lasts maintenance > cost usually outweighs execution cost. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2018-02-20 09:39 -0800 |
| Message-ID | <chine.bleu-5AEC03.09390020022018@reader.eternal-september.org> |
| In reply to | #126890 |
In article <slrnp8oju8.eu5.grahn+nntp@frailea.sa.invalid>, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > Aren't configure scripts written in /bin/sh rather than Bash? Bash is > much better for large programs than what Bourne shell was. I don't know. On the machinss I use, they tend to have been equated. > But probably the configure script would have been awful in Bash, too. I prefer to compare to configure and libtool to what flows into a sewage control plant. Which goes back to what I have learned that development and maintenance costs almost always outweigh execution costs. Maintainable C is good not because it might be faster, but because it is written to be maintainable. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ I'm saving up to buy the Donald a blue stone This post / \ from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-02-20 19:16 +0000 |
| Message-ID | <slrnp8osvj.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #126901 |
On Tue, 2018-02-20, Siri Cruise wrote: > In article <slrnp8oju8.eu5.grahn+nntp@frailea.sa.invalid>, > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > >> Aren't configure scripts written in /bin/sh rather than Bash? Bash is >> much better for large programs than what Bourne shell was. > > I don't know. On the machinss I use, they tend to have been equated. /bin/sh is often[0] an alias for Bash, but IIRC configure scripts are supposed to be written for a lowest common denominator. /Jorgen [0] Although it's dash or ksh on all machines I have here. -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-15 12:46 +0000 |
| Message-ID | <lifhC.9897$lJ4.4815@fx27.am4> |
| In reply to | #126692 |
On 14/02/2018 15:47, G B wrote:
> If you have a text file of numbers, what is the best way to read numbers
> line by line and do some tests on numbers for that line before moving to
> the next line? for example the text file might be:
>
> 07 23 36 52 53 57
> 02 04 09 15 25 51
> 02 03 11 14 18 21
> 22 22 23 28 33 54
> 16 19 26 48 58 58
> 04 28 42 48 56 57
> 05 13 18 21 45 46
> 05 22 23 29 31 58
> 01 03 07 14 16 55
> 06 09 40 43 46 48
>
> I want to read numbers: a, b, c, d, e, f and do some tests on it and
> then go to the next line and do the same.
>
> In some languages, it was possible to do something like this:
>
> While Not EOF (Infile) Do
> Begin
> ReadLn (InFile, a, b, c, d, e, f);
> // Write test code here
> End;
>
> I want something similar in C or C++.
Here's my C coding exercise for the morning. It uses a library-based
approach: put all the fiddly details into functions, in the aim of
keeping the main function as simple and as close to the above as possible.
Any extra specification, error checking etc can also be added to the
functions as needed, without affecting the use of the line- and
number-reading code too much. (For example checking for overlong lines,
or having an expanding buffer, or dealing with input errors. Note that
as written, it can only read from one file at a time, as the linebuffer
etc is local to readline().)
The readline_s() function was used for initial testing to get a known
line (eg. readline_s("10 20 30 40")), but has been left in.
The readint() function will read skip immediate "," or ";" separators,
so that "123,456" or "123;456" or "123 456" can be read, but does little
else beyond that. readint() will return zero at end-of-line; it can't
proceed to reading the next line; that is impossible with this interface.
Eof-checking can be done using ateof() (like your example), but will
also set a flag in the Buffpos* return value of readline().
----------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
typedef struct {char* buffptr; int eof;} Buffpos;
Buffpos* readline_s(char* s) {
static Buffpos rlpos;
rlpos.buffptr=s;
rlpos.eof=0;
return &rlpos;
}
Buffpos* readline(FILE* f) {
#define readline_buffsize 16384
static char linebuffer[readline_buffsize];
static Buffpos rlpos;
char* s;
if (fgets(linebuffer,readline_buffsize,f)) {
rlpos.buffptr = linebuffer;
rlpos.eof = 0;
}
else {
rlpos.buffptr = linebuffer;
rlpos.eof = 1;
}
return &rlpos;
}
int ateof(FILE* f) {
int c;
c = fgetc(f);
if (c == EOF) {
return 1;
}
ungetc(c,f);
return 0;
}
int64_t readint(Buffpos* p){
char* endptr;
int64_t a;
a = strtoll(p->buffptr,&endptr,10);
switch (*endptr) {
case ',':
case ';':
++endptr;
}
p->buffptr = endptr;
return a;
}
int main(void) {
Buffpos* linepos;
FILE* fh;
int a,b,c,d,e,f;
fh = fopen("input","r");
if (fh) {
while (!ateof(fh)) {
linepos = readline(fh);
a = readint(linepos);
b = readint(linepos);
c = readint(linepos);
d = readint(linepos);
e = readint(linepos);
f = readint(linepos);
printf("%5d %5d %5d %5d %5d %5d\n",a,b,c,d,e,f);
}
fclose(fh);
}
}
---------------------------------------
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-02-15 14:52 +0100 |
| Message-ID | <20180215145208.161c5e86369193896d45a3fb@gmail.com> |
| In reply to | #126718 |
On Thu, 15 Feb 2018 12:46:21 +0000
bartc <bc@freeuk.com> wrote:
> Here's my C coding exercise for the morning. It uses a library-based
> approach: put all the fiddly details into functions, in the aim of
> keeping the main function as simple and as close to the above as
> possible.
Any (public) C library should provide at least one header for type
checking such as:
#include <libxyz.h>
int main(int argc, char *argv[])
{
/* some code */
return 0;
}
It is better to include private code with prototypes such as:
#include "funcx.c"
#include "funcy.c"
#include "funcz.c"
int main(int argc, char *argv[])
{
/* some code */
return 0;
}
In my view, the code structure is clearer like this.
--
GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-02-15 17:07 +0300 |
| Message-ID | <20180215170742.2fa7eec0393468a47a96842a@g{oogle}mail.com> |
| In reply to | #126718 |
bartc:
>if (fgets(linebuffer,readline_buffsize,f)) {
> rlpos.buffptr = linebuffer;
> rlpos.eof = 0;
>}
>else {
> rlpos.buffptr = linebuffer;
> rlpos.eof = 1;
>}
>return &rlpos;
The assignment rlpos.buffptr = linebuffer is present
in both parts of the condition and therefore can be
moved outside. Why do you save linebuffer after
fgets() has returned null? I think it is useless:
fgets() returns s on success, and NULL on error
or when end of file occurs while no characters
have been read.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-15 14:23 +0000 |
| Message-ID | <1JghC.50902$U92.19193@fx11.am4> |
| In reply to | #126723 |
On 15/02/2018 14:07, Anton Shepelev wrote:
> bartc:
>
>> if (fgets(linebuffer,readline_buffsize,f)) {
>> rlpos.buffptr = linebuffer;
>> rlpos.eof = 0;
>> }
>> else {
>> rlpos.buffptr = linebuffer;
>> rlpos.eof = 1;
>> }
>> return &rlpos;
>
> The assignment rlpos.buffptr = linebuffer is present
> in both parts of the condition and therefore can be
> moved outside. Why do you save linebuffer after
> fgets() has returned null? I think it is useless:
I think that second assignment should have set rlpos.buffer to "", in
case the caller attempts reading stuff after readline() as been called
at end-of-file.
(I don't know if fgets will set the buffer to an empty string at EOF.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-02-15 18:52 +0300 |
| Message-ID | <20180215185244.44d5204d5fac378faeaffcdf@g{oogle}mail.com> |
| In reply to | #126727 |
bartc to Anton Shepelev:
>>bartc:
>>
>>>if (fgets(linebuffer,readline_buffsize,f)) {
>>> rlpos.buffptr = linebuffer;
>>> rlpos.eof = 0;
>>>}
>>>else {
>>> rlpos.buffptr = linebuffer;
>>> rlpos.eof = 1;
>>>}
>>>return &rlpos;
>>
>>The assignment rlpos.buffptr = linebuffer is pre-
>>sent in both parts of the condition and therefore
>>can be moved outside. Why do you save linebuffer
>>after fgets() has returned null? I think it is
>>useless:
>>
>> fgets() returns s on success, and NULL on error
>> or when end of file occurs while no characters
>> have been read.
>
>I think that second assignment should have set rl-
>pos.buffer to "", in case the caller attempts read-
>ing stuff after readline() as been called at end-
>of-file.
Then I suggest:
if (fgets(linebuffer,readline_buffsize,f)) rlpos.eof = 0;
else rlpos.eof = 1;
rlpos.buffptr = linebuffer;
>(I don't know if fgets will set the buffer to an
>empty string at EOF.)
It is not required to, and does not in my environ-
ment.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-15 14:39 +0000 |
| Message-ID | <87o9kq8gh3.fsf@bsb.me.uk> |
| In reply to | #126718 |
bartc <bc@freeuk.com> writes:
> On 14/02/2018 15:47, G B wrote:
>> If you have a text file of numbers, what is the best way to read
>> numbers line by line and do some tests on numbers for that line
>> before moving to the next line? for example the text file might be:
>>
>> 07 23 36 52 53 57
>> 02 04 09 15 25 51
>> 02 03 11 14 18 21
>> 22 22 23 28 33 54
>> 16 19 26 48 58 58
>> 04 28 42 48 56 57
>> 05 13 18 21 45 46
>> 05 22 23 29 31 58
>> 01 03 07 14 16 55
>> 06 09 40 43 46 48
>> In some languages, it was possible to do something like this:
>>
>> While Not EOF (Infile) Do
>> Begin
>> ReadLn (InFile, a, b, c, d, e, f);
>> // Write test code here
>> End;
> Here's my C coding exercise for the morning. It uses a library-based
> approach: put all the fiddly details into functions, in the aim of
> keeping the main function as simple and as close to the above as
> possible.
That's not always a good idea. Sometimes it helps to show better
alternatives. With six numbers there's no good read not to use an
array. If the numbers had interesting names, sure, stick with that, but
the OP has written a, b, ..., f suggesting that a number's position has
no intrinsic meaning.
But more importantly the OP probably wants to see the C way of doing it
rather trying to shoe-horn C into what is probably just an illustrative
example.
> Any extra specification, error checking etc can also be added to the
> functions as needed, without affecting the use of the line- and
> number-reading code too much. (For example checking for overlong
> lines, or having an expanding buffer, or dealing with input
> errors. Note that as written, it can only read from one file at a
> time, as the linebuffer etc is local to readline().)
Yes, you do no error checking and yet the program is way more
complicated than it needs to be. I can't shake the feeling you are
doing this to further your agenda of making C look more complicated than
it is.
Why use int64_t? There is not reason to specify that much, especially
as you, in fact, appear to want integers. You simply introduce the
possibility of overflow for no good reason. If you wanted a more
general readint function then long long is the type to use since it is
guaranteed to be available, is at least 64 bits wide, and matches the
type of strtoll.
What is the eof member of Buffpos for? And without , is there any
reason to have a struct at all?
Why do your signature EOF dance when you should know by now that C
favours a "try it and see if worked" model of IO? At the very least you
should say that you are doing this in a rather non-idiomatic way simply
to mirror the OP's example script.
Why limit the program to reading one named file? This seems to be thing
with Windows C programmers. Does the development environment make it
hard to run a program with stdin coming from a file? If so, then surely
having the name of the input file in argv is the way to go.
I hesitate to post my take on this because I am sure it will not be
most people's taste, but it is certainly shorter and it /does/ do some
error checking. Of course, we have no idea if that's what the OP
wants...
#include <stdio.h>
#include <stdbool.h>
bool parse_line(const char *lp, size_t n_wanted, int *d)
{
int n, len;
size_t n_read = 0;
while (sscanf(lp, "%d %n", &n, &len) == 1) {
if (n_read < n_wanted)
d[n_read] = n;
n_read += 1;
lp += len + (lp[len] == ',' || lp[len] == ';');
}
return *lp == 0 && n_read == n_wanted;
}
int main(void)
{
char line[1000];
size_t lnum = 0, numbers_per_line = 6;
int data[numbers_per_line];
while (fgets(line, sizeof line, stdin)) {
lnum += 1;
if (parse_line(line, numbers_per_line, data)) {
for (size_t i = 0; i < numbers_per_line; i++)
printf(" %5d", data[i]);
putchar('\n');
}
else fprintf(stderr, "Bad input on line %zu\n", lnum);
}
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web