Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60096 > unrolled thread
| Started by | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| First post | 2015-04-15 11:46 -0700 |
| Last post | 2015-04-30 01:40 -0700 |
| Articles | 20 on this page of 318 — 32 participants |
Back to article view | Back to comp.lang.c
Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 11:46 -0700
Re: Readability part I - code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-15 19:55 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:00 -0700
Re: Readability part I - code Xcott Craver <xcottcraver@gmail.com> - 2015-04-15 13:19 -0700
Re: Readability part I - code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-16 13:08 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:25 -0700
Re: Readability part I - code pa@see.signature.invalid (Pierre Asselin) - 2015-04-16 01:01 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:37 -0700
Re: Readability part I - code pa@see.signature.invalid (Pierre Asselin) - 2015-05-01 02:07 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 04:29 -0700
Readability part I - code asetofsymbols@gmail.com - 2015-04-16 00:13 -0700
Readability part I - code asetofsymbols@gmail.com - 2015-04-16 00:34 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:46 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-04-30 05:54 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 04:37 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-01 11:48 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-02 23:59 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-08 20:52 +0000
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-08 16:15 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-09 16:14 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 09:11 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 00:19 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:51 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-30 20:14 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 05:10 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-01 06:10 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 09:17 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-16 11:01 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 04:26 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-04-16 13:19 -0500
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-17 09:20 +0200
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-04-17 08:21 -0400
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-17 15:04 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 06:18 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-04-17 12:24 -0500
Re: Readability part I - code Greg Martin <greg.at.softsprocket@dot.com> - 2015-04-17 15:58 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 04:10 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 13:47 +0200
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-04-30 13:48 +0100
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 16:35 +0200
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-04-30 10:00 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 06:25 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-02 15:53 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:42 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-04 09:41 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 07:01 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-06 09:34 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 04:33 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:51 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 11:51 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-07 21:49 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 13:22 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-06 15:27 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:11 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-06 21:00 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 00:20 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 10:43 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-06 13:11 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:48 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 11:51 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 12:26 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 16:52 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-07 20:22 -0500
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-08 02:56 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-08 10:53 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 18:30 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-08 09:27 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-08 11:06 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-09 09:31 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-10 08:01 +1200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-09 13:13 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-10 08:51 +1200
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-09 16:45 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 13:28 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:36 -0700
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-05-06 22:13 -0500
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 11:56 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 14:16 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 11:43 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 12:02 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 13:36 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 15:09 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 17:13 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 18:07 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-08 11:35 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:41 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 13:59 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 10:27 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-10 10:50 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-10 19:09 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 04:54 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 13:19 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-12 05:26 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:31 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 16:40 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 10:28 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-10 11:39 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 05:33 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-07 17:59 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 09:20 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:37 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:40 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:46 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:53 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 13:47 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 20:04 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-11 12:39 -0700
Re: Readability part I - code Nathan Wagner <nw@hydaspes.if.org> - 2015-05-12 07:34 +0000
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-12 10:58 +0000
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-11 21:00 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 21:18 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-11 23:37 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 00:07 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-11 16:52 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 01:19 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 01:43 +0100
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-12 11:00 +0000
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 12:33 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 13:25 +0100
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:01 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:26 -0700
Re: Readability part I - code Ike Naar <ike@iceland.freeshell.org> - 2015-05-14 19:58 +0000
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 20:15 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 07:25 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 08:50 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-25 02:06 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:25 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:35 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 15:53 +0100
Re: Readability part I - code Martin Shobe <martin.shobe@yahoo.com> - 2015-07-10 10:20 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 16:30 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 10:49 -0700
Re: Readability part I - code Philip Lantz <prl@canterey.us> - 2015-07-10 11:19 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:47 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-13 20:20 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 02:57 -0700
Re: Readability part I - code "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-13 12:27 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 03:21 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 17:35 +0000
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-15 18:46 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-15 11:35 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:47 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 21:24 +0000
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-21 08:43 -0400
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-21 13:26 -0400
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-21 22:11 -0400
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-22 04:03 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 02:30 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-22 07:14 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 08:24 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-21 23:39 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-22 11:51 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-23 07:35 +1200
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 06:36 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:25 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 08:44 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-10 16:53 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:57 -0700
Re: Readability part I - code Öö Tiib <ootiib@hot.ee> - 2015-05-23 06:27 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-23 16:07 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-23 19:10 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 06:25 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-24 12:24 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 22:49 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 12:49 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 22:56 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:07 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 17:29 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:52 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 19:45 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 04:27 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 17:50 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:48 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:21 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-23 21:30 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-26 11:30 -0700
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 16:16 -0500
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-26 23:04 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:15 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:12 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-12 17:28 +1200
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 11:09 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 11:43 +0100
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-12 05:16 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-12 05:34 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 22:52 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 03:45 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-21 12:53 +0100
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-21 11:01 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 20:18 +0100
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 21:47 +0100
Re: Readability part I - code Kusalananda <kusalananda@example.com> - 2015-05-24 07:12 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:59 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:18 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-22 07:15 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:53 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-07-11 14:09 +1200
Re: Readability part I - code Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 10:37 +0800
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 12:51 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-07-12 10:20 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 07:23 -0700
Re: Readability part I - code jadill33@gmail.com - 2015-05-11 13:30 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 21:56 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:14 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:15 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 16:38 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 11:38 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 17:58 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 13:44 -0500
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 11:32 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 11:14 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 03:27 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-21 08:41 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 18:12 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-24 19:20 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:51 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 11:35 -0700
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-10 14:54 -0400
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-10 15:10 -0400
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 20:51 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 13:22 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 20:47 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 17:05 -0700
Re: Readability part I - code Rosario19 <Ros@invalid.invalid> - 2015-07-11 11:04 +0200
Re: Readability part I - code Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 18:06 +0800
Re: Readability part I - code Rosario19 <Ros@invalid.invalid> - 2015-07-11 14:57 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 09:20 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 20:06 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 04:55 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 13:26 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 06:29 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 13:49 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 07:12 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-21 15:26 +0000
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-22 11:36 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 13:50 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 23:01 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:42 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 17:37 +0000
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 10:59 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 16:47 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-16 17:03 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 06:52 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:23 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:52 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 09:29 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-24 14:56 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:30 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 11:04 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-07-10 18:39 -0500
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 17:02 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-11 01:23 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 17:48 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 10:50 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 06:55 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 15:23 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 08:14 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 07:53 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 22:04 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 14:51 -0700
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-11 20:05 -0400
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:31 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 18:24 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 19:00 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-13 13:24 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-13 06:11 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:09 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-11 23:21 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 17:35 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:43 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 10:31 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 16:12 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 18:02 +0100
Re: Readability part I - code Philip Lantz <prl@canterey.us> - 2015-07-12 11:16 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 21:06 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:44 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:15 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 13:50 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 20:13 +0000
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:01 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 17:28 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:53 +0100
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:45 +0000
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:55 +0100
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 02:44 +0000
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-07-12 16:51 -0500
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 10:25 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:52 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-07-11 09:25 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:15 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-08 16:15 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:35 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:56 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 11:53 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 20:01 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:09 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:12 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:43 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-25 14:51 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-26 09:17 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:44 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 03:19 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 14:04 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 08:07 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-02 09:18 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:10 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-03 10:43 -0700
Re: Readability part I - code Melzzzzz <mel@zzzzz.com> - 2015-05-03 19:47 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 13:40 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-04 12:10 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 06:45 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-05 09:06 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 20:27 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 10:33 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:33 -0700
Re: Readability part I - code Les Cargill <lcargill99@comcast.com> - 2015-04-16 12:28 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 03:42 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 01:40 -0700
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-15 11:35 -0700 |
| Message-ID | <lnh9p5jmkd.fsf@kst-u.example.com> |
| In reply to | #65637 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
> (snip, someone wrote)
>>> unsigned int
>>> is_prime(
>>> unsigned int n
>>> ){
>>> if (n < 2) return 0;
>>>
>>> if (! (n % 2)) return (n == 2);
>>> if (! (n % 3)) return (n == 3);
>>> unsigned int m = (unsigned int)(std::sqrt(n));
>
> (snip)
>
>> Obviously it's an improvement in terms of runtime efficiency.
>> Leaving aside low-level style factors (and ignoring the 'std::'
>> C++-ism), my main reservation is the use of sqrt() to find the
>> loop bound.
>
> Reminds me of my first IBM Fortran program, the sample in
> the Fortran manual, which uses sqrt() to limit the loop
> for prime testing. That was the first time I thought about
> doing it that way.
>
> Not so long before, I wrote a prime number program for an
> HP 9810A calculator, which stored generated primes in memory,
> and used those for testing. It seemed obvious enough to me
> at the time.
Once upon a time, I wrote a prime number generator for a Compucorp
programmable calculator. It only had a handful of storable registers,
so storing generated primes wasn't an option. The program printed 2, 3,
5, and 7, then went into a loop with hard-coded offsets so it skipped
multiples of 2, 3, 5, and 7 (and therefore didn't have to check those
factors). The loop repeated with a cycle of 210 (2*3*5*7). I probably
would have used a cycle of 2310 (2*3*5*7*11) if it had been possible to
write a program that long.
Basically I had a 210-element lookup table, but encoded in the
instructions rather than stored in memory.
[...]
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 08:47 -0700 |
| Message-ID | <kfnvbdeomp0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65637 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > [regarding calculating square root using floating point] > >> Basically I don't trust my own ability to reason about what >> happens when floating-point is involved (plus, rightly or >> wrongly, converting to and from floating point feels >> "expensive" to me - maybe that's just my prejudice, but there >> it is). [snip] > > I would put a +1 in just to be sure that it rounds up and I > don't miss any trial divisors. [snip] I had habits like that when I started programming. After ten years or so I decided I should unlearn them. Sloppy thinking leads to sloppy programs - better to be in the habit of thinking things through carefully and being exact.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-20 21:24 +0000 |
| Message-ID | <mojov3$ajb$2@speranza.aioe.org> |
| In reply to | #66005 |
Tim Rentsch <txr@alumni.caltech.edu> wrote: (snip regarding square roots and prime numbers) >> I would put a +1 in just to be sure that it rounds up and I >> don't miss any trial divisors. [snip] > I had habits like that when I started programming. After > ten years or so I decided I should unlearn them. Sloppy > thinking leads to sloppy programs - better to be in the > habit of thinking things through carefully and being exact. I agree in general, but depending on the proper implementation of sqrt() is farther than I might go. If I am writing the lower level, and can verify its operation, then yes. I am not so sure it is easy to verify that Newton-Raphson always rounds right. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-21 08:43 -0400 |
| Message-ID | <T7rrx.382294$ij7.209848@fx02.iad> |
| In reply to | #66065 |
On 7/20/15 5:24 PM, glen herrmannsfeldt wrote: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > (snip regarding square roots and prime numbers) > >>> I would put a +1 in just to be sure that it rounds up and I >>> don't miss any trial divisors. [snip] > >> I had habits like that when I started programming. After >> ten years or so I decided I should unlearn them. Sloppy >> thinking leads to sloppy programs - better to be in the >> habit of thinking things through carefully and being exact. > > I agree in general, but depending on the proper implementation > of sqrt() is farther than I might go. If I am writing the lower > level, and can verify its operation, then yes. I am not so sure > it is easy to verify that Newton-Raphson always rounds right. > > -- glen > But the floor of the sqrt is good enough. Any composite number must have at least one divisor less than or equal to the sqrt of the number. If the ceil of the sqrt divides into the number , the other factor will be, by necessity, less then or equal to the sqrt of the number. So as long as you always get something with an error less than 1, it is suitable. If the error might be as big or bigger than 1, then yes, you need to add the floor of the max error to get the number that is at least the floor of the sqrt.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-21 13:26 -0400 |
| Message-ID | <molv9a$5i8$1@dont-email.me> |
| In reply to | #66106 |
On 07/21/2015 08:43 AM, Richard Damon wrote: > On 7/20/15 5:24 PM, glen herrmannsfeldt wrote: >> Tim Rentsch <txr@alumni.caltech.edu> wrote: >> >> (snip regarding square roots and prime numbers) >> >>>> I would put a +1 in just to be sure that it rounds up and I >>>> don't miss any trial divisors. [snip] >> >>> I had habits like that when I started programming. After >>> ten years or so I decided I should unlearn them. Sloppy >>> thinking leads to sloppy programs - better to be in the >>> habit of thinking things through carefully and being exact. >> >> I agree in general, but depending on the proper implementation >> of sqrt() is farther than I might go. If I am writing the lower >> level, and can verify its operation, then yes. I am not so sure >> it is easy to verify that Newton-Raphson always rounds right. >> >> -- glen >> > > But the floor of the sqrt is good enough. Any composite number must have > at least one divisor less than or equal to the sqrt of the number. If > the ceil of the sqrt divides into the number , the other factor will be, > by necessity, less then or equal to the sqrt of the number. So as long > as you always get something with an error less than 1, it is suitable. > If the error might be as big or bigger than 1, then yes, you need to add > the floor of the max error to get the number that is at least the floor > of the sqrt. Consider a prime number prn such that prn*DBL_EPSILON > 1.0. Then (assuming that prn*prn doesn't overflow the relevant integer type) sqrt(prn*prn) might easily be infinitesimally less than prn, so floor(sqrt(prn*prn)) < prn. In that case, your loop will terminate one step early, failing to detect that prn*prn is a perfect square. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-21 22:11 -0400 |
| Message-ID | <%YCrx.279341$eJ6.74116@fx10.iad> |
| In reply to | #66116 |
On 7/21/15 1:26 PM, James Kuyper wrote: > On 07/21/2015 08:43 AM, Richard Damon wrote: >> But the floor of the sqrt is good enough. Any composite number must have >> at least one divisor less than or equal to the sqrt of the number. If >> the ceil of the sqrt divides into the number , the other factor will be, >> by necessity, less then or equal to the sqrt of the number. So as long >> as you always get something with an error less than 1, it is suitable. >> If the error might be as big or bigger than 1, then yes, you need to add >> the floor of the max error to get the number that is at least the floor >> of the sqrt. > > Consider a prime number prn such that prn*DBL_EPSILON > 1.0. Then > (assuming that prn*prn doesn't overflow the relevant integer type) > sqrt(prn*prn) might easily be infinitesimally less than prn, so > floor(sqrt(prn*prn)) < prn. In that case, your loop will terminate one > step early, failing to detect that prn*prn is a perfect square. > Yes, if the unsigned int to double conversion is inexact, then you need to take extra precautions. (Note, I did say if the error in the sqrt was > 1 you needed to do something). This would require (typically) 64 bit ints with 64 bit doubles (there are a number of historical issues that often make int be only 32 bits even on a machine which might say 64 bits would make more sense, so we have 8, 16, 32, and 64 bit standard types). I would need to do a careful analysis to make sure that adding +1 to the sqrt would be good enough, my first impression is that I would make sure the int to double conversion 'rounded up' by adding prn*DBL_EPSILON before doing the sqrt. Of course, we also run into the issue that by the standard, sqrt doesn't have a required precision, we are assuming that it has the typical accurate results (it might make sense to use a isqrt function which is defined to be accurate.)
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-22 04:03 +0000 |
| Message-ID | <mon4mp$201$1@speranza.aioe.org> |
| In reply to | #66136 |
Richard Damon <Richard@damon-family.org> wrote: (snip) > I would need to do a careful analysis to make sure that adding +1 to the > sqrt would be good enough, my first impression is that I would make sure > the int to double conversion 'rounded up' by adding prn*DBL_EPSILON > before doing the sqrt. As noted, the problem case is a perfect square, where it might be just slightly low. The square root routines I know divide the exponent by two, then do a simple interpolation, which includes a term for the odd exponent case. Next, two (single) or four (double) cycles of Newton-Raphson. It isn't so obvious to me that it can never be just slightly low. > Of course, we also run into the issue that by the standard, sqrt doesn't > have a required precision, we are assuming that it has the typical > accurate results (it might make sense to use a isqrt function which is > defined to be accurate.) About the time I was learning Fortran and the prime number program, I wondered why no ISQRT. There still isn't one, but they now claim generic functions, as long as the argument isn't an INTEGER. Most other languages will do the conversion for you. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-23 02:30 -0700 |
| Message-ID | <kfn380fjk5s.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66065 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > (snip regarding square roots and prime numbers) > >>> I would put a +1 in just to be sure that it rounds up and I >>> don't miss any trial divisors. [snip] >> >> I had habits like that when I started programming. After >> ten years or so I decided I should unlearn them. Sloppy >> thinking leads to sloppy programs - better to be in the >> habit of thinking things through carefully and being exact. > > I agree in general, but depending on the proper implementation > of sqrt() is farther than I might go. [snip] If I thought I couldn't depend on a proper implementation of sqrt() then I wouldn't use sqrt() in such cases. As a matter of mental habit I think it's a bad idea to put in little fudge factors "just in case". In situations where it's important to be exact, be exact. Here we don't need to be numerically exact, as larger values will work, but we should be logically exact.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-22 07:14 +1200 |
| Message-ID | <cs6p53Ff7cmU1@mid.individual.net> |
| In reply to | #62407 |
Tim Rentsch wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 11/05/15 21:00, Bartc wrote: >> >>> With your preferred [Allman] brace style, there will be lots of >>> extraneous vertical space introduced, depending on whether your >>> 'else's follow on on the same line as the "}". >> >> Clearly you see the "extraneous" vertical space as a disadvantage. >> I see it as an advantage. > > How is taking more vertical space an advantage? > >> It has the same visual benefit as an >> empty line (and that visual benefit is very real, which is why >> Usenauts put a blank line between paragraphs), but with the added >> benefit that it's not empty. :-) > > To me, putting a on a character like open brace on a line > intended as a spacing line adds distracting visual clutter; all > cost, no benefit. Apparently your reaction is just the opposite. > What about it is a benefit? Or what benefit would you say it > provides? I've often wondered why I find the Java style of putting the opening brace at the end of a line so jarring and the best I can come up with is that I prefer the visual symmetry of the opening brace aligned with the closing one. I'm sure some psychologists could get a decent grant to investigate why some programmers prefer one code layout and others another :) -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-24 08:24 -0700 |
| Message-ID | <kfnegm66ls9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62425 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>> On 11/05/15 21:00, Bartc wrote: >>> >>>> With your preferred [Allman] brace style, there will be lots of >>>> extraneous vertical space introduced, depending on whether your >>>> 'else's follow on on the same line as the "}". >>> >>> Clearly you see the "extraneous" vertical space as a disadvantage. >>> I see it as an advantage. >> >> How is taking more vertical space an advantage? >> >>> It has the same visual benefit as an >>> empty line (and that visual benefit is very real, which is why >>> Usenauts put a blank line between paragraphs), but with the added >>> benefit that it's not empty. :-) >> >> To me, putting a on a character like open brace on a line >> intended as a spacing line adds distracting visual clutter; all >> cost, no benefit. Apparently your reaction is just the opposite. >> What about it is a benefit? Or what benefit would you say it >> provides? > > I've often wondered why I find the Java style of putting the > opening brace at the end of a line so jarring and the best I can > come up with is that I prefer the visual symmetry of the opening > brace aligned with the closing one. I didn't get much from this answer, but I see there is another response downthread which I think is better, so I will followup there. I should add that you do say you find the placement of opening brace at the end of a line jarring, which is helpful to know and an example of the sort of information I'm looking for (even if I want to dig deeper after hearing it, but that doesn't change the high-order bit that this was useful information).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-05-21 23:39 +0100 |
| Message-ID | <mjlmoj$a17$1@dont-email.me> |
| In reply to | #62407 |
On 21/05/15 15:25, Tim Rentsch wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 11/05/15 21:00, Bartc wrote: >> >>> With your preferred [Allman] brace style, there will be lots of >>> extraneous vertical space introduced, depending on whether your >>> 'else's follow on on the same line as the "}". >> >> Clearly you see the "extraneous" vertical space as a disadvantage. >> I see it as an advantage. > > How is taking more vertical space an advantage? Do you see how you left a blank line between my paragraph and your reply to it? Ask yourself why. >> It has the same visual benefit as an >> empty line (and that visual benefit is very real, which is why >> Usenauts put a blank line between paragraphs), but with the added >> benefit that it's not empty. :-) > > To me, putting a on a character like open brace on a line > intended as a spacing line adds distracting visual clutter; all > cost, no benefit. Apparently your reaction is just the opposite. Indeed. > What about it is a benefit? Or what benefit would you say it > provides? For you, the brace is distracting visual clutter. For me, it's a visual aid. I've already explained this a couple of times, I think. The Allman style gives a very strong emphasis to the structure of a block. I find that emphasis helpful. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-22 11:51 -0700 |
| Message-ID | <87d21ssawz.fsf@kst-u.example.com> |
| In reply to | #62436 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> For you, the brace is distracting visual clutter. For me, it's a
> visual aid. I've already explained this a couple of times, I
> think. The Allman style gives a very strong emphasis to the structure
> of a block. I find that emphasis helpful.
I'm probably repeating things that have already been said, but ...
In Allman style:
if (condition)
{
statement1;
statement2;
statement3;
statement4;
}
The "if", "{", and "}" are all vertically aligned, with the 4 statements
indented.
In K&R style:
if (condition) {
statement1;
statement2;
statement3;
statement4;
}
the "if" and "}" are vertically aligned, with the 4 statements indented.
For me, the vertical alignment of the "if" and the "}" is enough to
make the structure clear at a glance.
For you, apparently, the alignment of the "if" with the "}" is not
enough to make the structure clear at a glance. Is that a fair
statement? If so, can you articulate *why* it's not enough?
One possible objection I can imagine to K&R sthle is that this:
if (condition)
statement;
(which would be followed by statements *not* controlled by the "if") is
difficult to distinguish from this:
if (condition) {
statement;
(which would be followed by statements that *are* controlled by the
"if"). Personally I avoid that by never using the first form.
Allman style does treat "{" and "}" more symmetrically than K&R style
does. In K&R style, "}" clearly marks the end of a block, while "{" is
deliberately shoved out of the way. I can see having an aesthetic
aversion to that (though I don't).
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-23 07:35 +1200 |
| Message-ID | <cs9envFjvmaU1@mid.individual.net> |
| In reply to | #62461 |
Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> [...]
>> For you, the brace is distracting visual clutter. For me, it's a
>> visual aid. I've already explained this a couple of times, I
>> think. The Allman style gives a very strong emphasis to the structure
>> of a block. I find that emphasis helpful.
>
> I'm probably repeating things that have already been said, but ...
>
> In Allman style:
>
> if (condition)
> {
> statement1;
> statement2;
> statement3;
> statement4;
> }
>
> The "if", "{", and "}" are all vertically aligned, with the 4 statements
> indented.
>
> In K&R style:
>
> if (condition) {
> statement1;
> statement2;
> statement3;
> statement4;
> }
>
> the "if" and "}" are vertically aligned, with the 4 statements indented.
>
> For me, the vertical alignment of the "if" and the "}" is enough to
> make the structure clear at a glance.
That is probably the difference. I find myself double checking the if
to ensure the opening brace hasn't accidentally been omitted!
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-05-24 06:36 +0000 |
| Message-ID | <mjrrhg$l6g$1@speranza.aioe.org> |
| In reply to | #62467 |
Ian Collins <ian-news@hotmail.com> wrote:
> Keith Thompson wrote:
(snip)
>> In Allman style:
>> if (condition)
>> {
>> statement1;
>> statement2;
>> statement3;
>> statement4;
>> }
(snip)
>> For me, the vertical alignment of the "if" and the "}" is enough to
>> make the structure clear at a glance.
> That is probably the difference. I find myself double checking the if
> to ensure the opening brace hasn't accidentally been omitted!
I think for me, reading this style, I find myself constantly checking
to be sure that an opening brace isn't there. Even more, it takes
longer to check that something isn't there than it takes to see that
it is.
I think for many of us, it is easiest to see in the style we are
most used to seeing. It takes extra work to read and check a
different style.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-10 07:25 -0700 |
| Message-ID | <kfnzj346qdt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #62467 |
Ian Collins <ian-news@hotmail.com> writes:
> Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [...]
>>> For you, the brace is distracting visual clutter. For me, it's a
>>> visual aid. I've already explained this a couple of times, I
>>> think. The Allman style gives a very strong emphasis to the
>>> structure of a block. I find that emphasis helpful.
>>
>> I'm probably repeating things that have already been said, but ...
>>
>> In Allman style:
>>
>> if (condition)
>> {
>> statement1;
>> statement2;
>> statement3;
>> statement4;
>> }
>>
>> The "if", "{", and "}" are all vertically aligned, with the 4
>> statements indented.
>>
>> In K&R style:
>>
>> if (condition) {
>> statement1;
>> statement2;
>> statement3;
>> statement4;
>> }
>>
>> the "if" and "}" are vertically aligned, with the 4 statements
>> indented.
>>
>> For me, the vertical alignment of the "if" and the "}" is enough to
>> make the structure clear at a glance.
>
> That is probably the difference. I find myself double checking the
> if to ensure the opening brace hasn't accidentally been omitted!
This explains your choice, but why do you feel a need to check?
Taking into account the following
(a) Essentially everyone indents nested statements;
(b) I think it is fair to say there is general consensus that
braces should be used even for a single nested statement;
(c) Pseudo code is almost always written with some sort of
close brace but either without an open brace or without
one on a separate line;
(d) If an open brace is missing, the code won't compile; and
(e) If there is still any remaining doubt, nesting structure
can be checked using a style formatter. (In principle
I believe this could be done automatically, ie, without
requiring a person to check the result, although I am not
aware of anyone having done that.)
Given the above, let me ask again: Why do you feel a need to
check?
(Sorry for the long delay in responding; outside demands on my
time have been unusually pressing recently.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-10 08:44 -0700 |
| Message-ID | <lnzj346mqc.fsf@kst-u.example.com> |
| In reply to | #65111 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Ian Collins <ian-news@hotmail.com> writes:
>> Keith Thompson wrote:
[...]
>>> In K&R style:
>>>
>>> if (condition) {
>>> statement1;
>>> statement2;
>>> statement3;
>>> statement4;
>>> }
>>>
>>> the "if" and "}" are vertically aligned, with the 4 statements
>>> indented.
>>>
>>> For me, the vertical alignment of the "if" and the "}" is enough to
>>> make the structure clear at a glance.
>>
>> That is probably the difference. I find myself double checking the
>> if to ensure the opening brace hasn't accidentally been omitted!
>
> This explains your choice, but why do you feel a need to check?
I won't try to answer the question, which was directed to Ian, but I'll
respond to some of your points.
> Taking into account the following
>
> (a) Essentially everyone indents nested statements;
Agreed.
> (b) I think it is fair to say there is general consensus that
> braces should be used even for a single nested statement;
For certain values of "general consensus". There certainly isn't a
*universal* consensus. In a certain large code base that I won't
identify, there are many occurrences of single nested statements
without braces, even though that violates the coding standards.
(Fixing it is impractical for various reasons.)
> (c) Pseudo code is almost always written with some sort of
> close brace but either without an open brace or without
> one on a separate line;
Hmm. That doesn't match my experience. If I saw pseudo-code like:
if condition
statement
}
I'd find it very odd, and assume the omission of the "{" (or the
presence of the "}" was a typo.
> (d) If an open brace is missing, the code won't compile; and
Good point (though it might if there's a missing closing brace
somewhere).
> (e) If there is still any remaining doubt, nesting structure
> can be checked using a style formatter. (In principle
> I believe this could be done automatically, ie, without
> requiring a person to check the result, although I am not
> aware of anyone having done that.)
>
> Given the above, let me ask again: Why do you feel a need to
> check?
>
> (Sorry for the long delay in responding; outside demands on my
> time have been unusually pressing recently.)
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-10 16:53 +0100 |
| Message-ID | <mnopnb$745$1@dont-email.me> |
| In reply to | #65122 |
On 10/07/2015 16:44, Keith Thompson wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> (d) If an open brace is missing, the code won't compile; and > > Good point (though it might if there's a missing closing brace > somewhere). Or an extra opening one somewhere else. Or a missing */ so that the } (and a big chunk of the program) is inadvertently commented out. (Some people might suggest using a smart editor that can highlight these things, but then we might as well just give up on syntax completely.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 08:57 -0700 |
| Message-ID | <kfn1tgey9du.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65122 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> Keith Thompson wrote:
>
> [...]
>
>>>> In K&R style:
>>>>
>>>> if (condition) {
>>>> statement1;
>>>> statement2;
>>>> statement3;
>>>> statement4;
>>>> }
>>>>
>>>> the "if" and "}" are vertically aligned, with the 4 statements
>>>> indented.
>>>>
>>>> For me, the vertical alignment of the "if" and the "}" is enough to
>>>> make the structure clear at a glance.
>>>
>>> That is probably the difference. I find myself double checking the
>>> if to ensure the opening brace hasn't accidentally been omitted!
>>
>> This explains your choice, but why do you feel a need to check?
>
> I won't try to answer the question, which was directed to Ian, but I'll
> respond to some of your points.
>
>> Taking into account the following
>>
>> (a) Essentially everyone indents nested statements;
>
> Agreed.
>
>> (b) I think it is fair to say there is general consensus that
>> braces should be used even for a single nested statement;
>
> For certain values of "general consensus". There certainly isn't a
> *universal* consensus. In a certain large code base that I won't
> identify, there are many occurrences of single nested statements
> without braces, even though that violates the coding standards.
> (Fixing it is impractical for various reasons.)
Right, not universal. I meant only that it is widely
advocated, not universally followed.
>> (c) Pseudo code is almost always written with some sort of
>> close brace but either without an open brace or without
>> one on a separate line;
>
> Hmm. That doesn't match my experience. If I saw pseudo-code like:
>
> if condition
> statement
> }
>
> I'd find it very odd, and assume the omission of the "{" (or the
> presence of the "}" was a typo.
Sorry, I meant "some sort of close brace" to be taken
generically, eg
IF some condition
action
ENDIF
>> (d) If an open brace is missing, the code won't compile; and
>
> Good point (though it might if there's a missing closing brace
> somewhere).
Sure, but that's unlikely if other close braces are checked (and
presumably they would be), and also why I pointed out (e) below
>> (e) If there is still any remaining doubt, nesting structure
>> can be checked using a style formatter. (In principle
>> I believe this could be done automatically, ie, without
>> requiring a person to check the result, although I am not
>> aware of anyone having done that.)
Comparing the output of a style formatter with the original
source will catch cases like the "missing close brace"
possibility mentioned above.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-05-23 06:27 -0700 |
| Message-ID | <f3ce3b74-01fd-4842-b265-c9c8b78fd724@googlegroups.com> |
| In reply to | #62461 |
On Friday, 22 May 2015 21:51:52 UTC+3, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> [...]
> > For you, the brace is distracting visual clutter. For me, it's a
> > visual aid. I've already explained this a couple of times, I
> > think. The Allman style gives a very strong emphasis to the structure
> > of a block. I find that emphasis helpful.
>
> I'm probably repeating things that have already been said, but ...
>
> In Allman style:
>
> if (condition)
> {
> statement1;
> statement2;
> statement3;
> statement4;
> }
>
> The "if", "{", and "}" are all vertically aligned, with the 4 statements
> indented.
>
> In K&R style:
>
> if (condition) {
> statement1;
> statement2;
> statement3;
> statement4;
> }
>
> the "if" and "}" are vertically aligned, with the 4 statements indented.
>
> For me, the vertical alignment of the "if" and the "}" is enough to
> make the structure clear at a glance.
>
> For you, apparently, the alignment of the "if" with the "}" is not
> enough to make the structure clear at a glance. Is that a fair
> statement? If so, can you articulate *why* it's not enough?
>
> One possible objection I can imagine to K&R style is that this:
>
> if (condition)
> statement;
>
> (which would be followed by statements *not* controlled by the "if") is
> difficult to distinguish from this:
>
> if (condition) {
> statement;
>
> (which would be followed by statements that *are* controlled by the
> "if"). Personally I avoid that by never using the first form.
Indeed. It is because with K&R style (especially when 'condition' is long)
if (condition)
statement;
looks bad but either
if (condition) break;
or
if (condition) {
break;
}
look fine. With Allman style
if (condition) break;
looks bad but
if (condition)
break;
and
if (condition)
{
break;
}
look fine.
> Allman style does treat "{" and "}" more symmetrically than K&R style
> does. In K&R style, "}" clearly marks the end of a block, while "{" is
> deliberately shoved out of the way. I can see having an aesthetic
> aversion to that (though I don't).
If that was the whole reason then people would merge the benefits
of styles somehow (example, not sure if it has name):
if (condition)
{ statement1;
statement2;
statement3;
statement4;
}
However that is among least popular styles.
We emphasize things in code by using white-space. Allman style has the
related curly braces around block on same line but also the visual pause
after control part of branch or loop makes the control part to stand out
not only by indentation. I have seen people who feel that such pause
makes their code more readable using K&R style (if forced by something,
say coding standard) like that:
if (condition) {
statement1;
statement2;
statement3;
statement4;
}
There moving the { to next line makes perfect sense.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-23 16:07 -0500 |
| Message-ID | <mjqq45$53m$1@dont-email.me> |
| In reply to | #62461 |
On 22-May-15 13:51, Keith Thompson wrote:
> One possible objection I can imagine to K&R sthle is that this:
>
> if (condition)
> statement;
>
> (which would be followed by statements *not* controlled by the "if") is
> difficult to distinguish from this:
>
> if (condition) {
> statement;
>
> (which would be followed by statements that *are* controlled by the
> "if"). Personally I avoid that by never using the first form.
Perhaps you don't consider it sufficient, but the _lack_ of indent on
the line following "statement;" indicates fairly clearly that it's not
part of the conditional.
I have no difficulty distinguishing these:
if (condition) {
foo();
bar();
}
vs
if (condition)
foo();
bar();
If someone messes up and indents the latter "bar();", well, then you
have another problem entirely...
Also, I'll admit I've done this a few times to save space:
if (condition)
foo(),
bar();
That's definitely not kosher according to most house styles, but it made
sense at the time and in the specific context.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web