Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60000 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2015-04-13 21:19 -0700 |
| Last post | 2015-04-14 13:03 +0100 |
| Articles | 20 on this page of 303 — 23 participants |
Back to article view | Back to comp.lang.c
SAFEcode G G <gdotone@gmail.com> - 2015-04-13 21:19 -0700
Re: SAFEcode Ian Collins <ian-news@hotmail.com> - 2015-04-14 17:12 +1200
Re: SAFEcode Ian Collins <ian-news@hotmail.com> - 2015-04-14 17:19 +1200
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-14 00:24 -0500
Re: SAFEcode G G <gdotone@gmail.com> - 2015-04-13 23:45 -0700
SAFEcode asetofsymbols@gmail.com - 2015-04-13 22:30 -0700
Re: SAFEcode Robbie Hatley <see.my.sig@for.my.address> - 2015-04-14 00:14 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 10:33 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 02:01 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-14 10:23 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 11:49 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 04:31 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 14:54 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 06:39 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 16:10 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 08:11 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-14 23:58 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 01:25 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 11:11 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 02:35 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 13:52 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 06:04 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-15 08:08 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 08:57 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 18:24 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 09:45 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-15 19:09 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 22:29 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-16 08:23 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 10:44 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-16 11:22 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-19 15:33 +0000
Re: SAFEcode Steve Thompson <stevet810@gmail.com> - 2015-04-16 04:38 +0000
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-16 14:12 -0500
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-17 09:28 +0200
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 09:33 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 02:08 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 09:43 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 08:04 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 17:08 -0500
Re: SAFEcode Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 08:07 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-15 12:29 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 22:56 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-16 10:29 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 04:46 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-16 13:08 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 08:42 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-16 16:47 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-16 16:53 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 10:52 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-16 22:11 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-17 10:22 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 02:17 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-17 05:56 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 04:37 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 10:04 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 08:38 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-17 20:52 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-18 13:16 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-18 04:22 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-18 14:08 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-18 06:00 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-18 21:42 +0200
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-18 17:47 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 00:11 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-19 12:52 +0000
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-19 09:10 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 07:21 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-19 12:54 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 11:18 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 09:58 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 08:09 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 13:06 -0500
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-19 07:32 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 09:03 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 16:30 +0100
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-19 12:58 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 05:37 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-18 08:00 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-18 19:28 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-18 09:37 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 11:37 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-19 09:56 -0500
Re: SAFEcode Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 15:49 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 18:13 -0500
Re: SAFEcode Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-28 12:46 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-20 16:50 -0500
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-17 10:31 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-17 21:09 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 19:01 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-18 15:18 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-18 09:00 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-18 21:52 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 00:02 -0700
Re: SAFEcode asetofsymbols@gmail.com - 2015-04-19 00:40 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 03:52 -0700
Re: SAFEcode asetofsymbols@gmail.com - 2015-04-21 09:02 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-19 12:58 +0000
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 07:25 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-19 15:51 +0000
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-19 23:22 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 16:26 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 00:48 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 09:15 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 00:39 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 10:33 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 01:55 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 11:28 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 02:39 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 12:35 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 03:58 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 13:37 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 06:04 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 15:37 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 06:52 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 16:23 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 07:32 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 22:42 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 21:56 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 09:21 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 01:00 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 10:37 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 01:59 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 12:21 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 03:45 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-21 10:05 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 12:14 +0200
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-21 08:18 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 08:51 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 09:44 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 01:38 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 03:45 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 02:13 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 04:29 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 03:29 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 10:30 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 09:13 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 13:03 -0500
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 11:38 -0700
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 15:25 -0500
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-22 21:49 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 16:17 -0500
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-22 22:33 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 16:56 -0500
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-23 09:24 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 02:25 -0700
Re: SAFEcode Richard Damon <Richard@Damon-Family.org> - 2015-04-23 08:24 -0400
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 06:18 -0700
Re: SAFEcode Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-23 14:47 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 07:16 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-23 17:20 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 08:44 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:14 +0000
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-25 04:04 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-25 12:22 +0000
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-25 10:53 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-23 16:48 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-24 12:49 +0200
Re: SAFEcode Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-23 20:40 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 13:03 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-23 23:49 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 01:07 -0700
Re: SAFEcode Ben Bacarisse <ben.lists@bsb.me.uk> - 2015-04-24 11:51 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 04:29 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-24 13:20 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 06:48 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:16 +0000
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-24 15:48 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 10:05 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-24 22:59 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-26 00:16 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-24 04:39 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-24 22:59 +0100
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-23 08:17 -0500
Re: SAFEcode Robert Wessel <robertwessel2@yahoo.com> - 2015-04-22 16:49 -0500
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 17:01 -0500
Re: SAFEcode James Kuyper <jameskuyper@verizon.net> - 2015-04-22 17:51 -0400
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-22 17:35 -0500
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 17:45 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-23 09:29 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-23 08:29 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-23 08:55 -0700
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-23 21:11 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 06:23 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 13:08 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 20:17 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 12:43 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-23 11:52 +0000
Re: SAFEcode Robert Wessel <robertwessel2@yahoo.com> - 2015-04-23 13:53 -0500
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-25 10:18 +0000
Re: SAFEcode Morris Dovey <mrdovey@iedu.com> - 2015-04-25 21:37 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-20 12:05 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 04:28 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 04:38 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-20 12:40 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 14:11 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 06:31 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 16:31 +0200
Re: SAFEcode jadill33@gmail.com - 2015-04-20 09:38 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-20 22:52 +0200
Re: SAFEcode asetofsymbols@gmail.com - 2015-04-20 11:10 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-20 22:43 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-20 22:59 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 09:27 +0200
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 15:12 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 07:31 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-21 16:43 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 08:01 -0700
Re: SAFEcode raltbos@xs4all.nl (Richard Bos) - 2015-04-21 22:29 +0000
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-21 11:09 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 10:13 -0700
Re: SAFEcode gwowen <gwowen@gmail.com> - 2015-04-21 10:22 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 16:51 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 02:52 +0100
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-21 14:44 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 16:58 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 01:11 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-21 17:31 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 10:09 +0200
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 10:50 +0100
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-22 11:12 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 11:37 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 05:54 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 15:31 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 06:48 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 16:29 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 16:13 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 08:22 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 16:25 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 10:35 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 13:24 -0500
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-23 01:18 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-23 06:11 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-23 09:36 +0200
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 08:38 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 13:04 +0200
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 09:52 -0500
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 16:23 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 10:28 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 08:16 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 13:53 -0500
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-22 12:45 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 16:44 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 22:58 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 09:53 +0200
Re: SAFEcode gwowen <gwowen@gmail.com> - 2015-04-21 10:15 -0700
Re: SAFEcode Martin Shobe <martin.shobe@yahoo.com> - 2015-04-21 13:57 -0500
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 23:01 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-21 23:46 +0100
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 01:49 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 08:32 +0100
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-22 10:02 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-21 12:06 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 20:18 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-21 12:30 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-21 21:30 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-21 13:39 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-21 20:21 +0100
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-22 10:24 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-22 09:46 +0100
Re: SAFEcode gwowen <gwowen@gmail.com> - 2015-04-22 02:57 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-22 08:42 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 16:19 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 09:08 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-16 08:55 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 11:03 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-16 11:35 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-17 10:28 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-17 09:51 +0100
Re: SAFEcode Phil Carmody <pc+usenet@asdf.org> - 2015-04-20 11:28 +0300
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-17 10:32 +0200
Re: SAFEcode Bartc <bc@freeuk.com> - 2015-04-14 15:24 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 08:03 -0700
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-14 18:48 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 12:43 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-14 21:52 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 13:16 -0700
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-14 21:39 +0100
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-15 01:20 +0100
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-15 01:29 +0100
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 01:32 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-15 08:17 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 09:13 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-15 18:33 +0200
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 10:02 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-15 20:55 +0200
Re: SAFEcode Robert Wessel <robertwessel2@yahoo.com> - 2015-04-15 19:27 -0500
Re: SAFEcode Phil Carmody <pc+usenet@asdf.org> - 2015-04-20 11:53 +0300
Re: SAFEcode Ian Collins <ian-news@hotmail.com> - 2015-04-16 14:51 +1200
Re: SAFEcode Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 02:13 -0700
Re: SAFEcode Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-04-15 08:14 +0200
Re: SAFEcode Richard Heathfield <rjh@cpax.org.uk> - 2015-04-14 21:02 +0100
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-14 08:33 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 08:54 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-14 11:43 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 12:41 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-14 13:08 -0700
Re: SAFEcode Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-14 14:02 -0700
Re: SAFEcode Keith Thompson <kst-u@mib.org> - 2015-04-14 15:29 -0700
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 10:03 +0200
Re: SAFEcode David Brown <david.brown@hesbynett.no> - 2015-04-15 10:02 +0200
Re: SAFEcode Phil Carmody <pc+usenet@asdf.org> - 2015-04-20 11:13 +0300
Re: SAFEcode Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-14 13:03 +0100
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-18 09:37 -0500 |
| Message-ID | <mgtq82$95i$1@speranza.aioe.org> |
| In reply to | #60260 |
On 4/17/15 2:52 PM, Ben Bacarisse wrote: > Morris's code is not a solution to the problem you posed -- it's a > way to avoid the problem altogether by using the stack instead. > Your problem (as posed) seemed to be to find the optimal multiplier > for growing an input buffer. Exactly so - we've had this discussion before, with not very satisfying results. My opinion is that any scheme that involves expanding the buffer during input is sub-optimal. The code I had originally posted took advantage of the gcc extension to allow nested functions in order to achieve a significant stack space savings. It was well and properly boo'd as not strictly conforming, but is the version I normally use. :-) I've uploaded that (non-conforming!) code to http://www.iedu.com/tmp/getsmx.c -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-19 11:37 +0100 |
| Message-ID | <87a8y49zf0.fsf@bsb.me.uk> |
| In reply to | #60321 |
Morris Dovey <mrdovey@iedu.com> writes: > On 4/17/15 2:52 PM, Ben Bacarisse wrote: > >> Morris's code is not a solution to the problem you posed -- it's a >> way to avoid the problem altogether by using the stack instead. >> Your problem (as posed) seemed to be to find the optimal multiplier >> for growing an input buffer. > > Exactly so - we've had this discussion before, with not very satisfying > results. My opinion is that any scheme that involves expanding the > buffer during input is sub-optimal. > > The code I had originally posted took advantage of the gcc extension to > allow nested functions in order to achieve a significant stack space > savings. It was well and properly boo'd as not strictly conforming, but > is the version I normally use. :-) > > I've uploaded that (non-conforming!) code to > http://www.iedu.com/tmp/getsmx.c A neat idea to save space, but a shame that it's not standard C. By the way, do you really need the struct in this version now that you are not passing it down? I think the code would be clearer without it. I wonder if it would be worth using a small array in the standard C version, i.e. reading up to N chars per recursive call rather than just one? That way you could ameliorate the per-byte cost of stack space making it more palatable to recursion haters? I may have a play with that, though it's likely to be more messy than your version. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-19 09:56 -0500 |
| Message-ID | <mh0fma$dim$1@speranza.aioe.org> |
| In reply to | #60382 |
On 4/19/15 5:37 AM, Ben Bacarisse wrote:
> A neat idea to save space, but a shame that it's not standard C. By the
> way, do you really need the struct in this version now that you are
> not passing it down? I think the code would be clearer without it.
Immediately after uploading I asked myself the same question. :-)
char *getsm(FILE *f)
{ char *p = NULL;
size_t n = 0;
char *g(void)
{ int c;
if (c = fgetc(f), c != EOF && c != '\n')
{ ++n;
p = g();
if (n)
{ --n;
if (p) *--p = (char)c;
}
}
else
{ if (c == EOF && !n) return NULL;
if (p = malloc(n + 1)) *(p += n) = '\0';
else errno = ENOMEM;
}
return p;
}
return g();
}
--
Morris Dovey
http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-22 15:49 -0700 |
| Message-ID | <kfnr3rbsrrx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60417 |
Morris Dovey <mrdovey@iedu.com> writes:
> On 4/19/15 5:37 AM, Ben Bacarisse wrote:
>> A neat idea to save space, but a shame that it's not standard C.
>> By the way, do you really need the struct in this version now
>> that you are not passing it down? I think the code would be
>> clearer without it.
>
> Immediately after uploading I asked myself the same question. :-)
>
> char *getsm(FILE *f)
> { char *p = NULL;
> size_t n = 0;
> char *g(void)
> { int c;
> if (c = fgetc(f), c != EOF && c != '\n')
> { ++n;
> p = g();
> if (n)
> { --n;
> if (p) *--p = (char)c;
> }
> }
> else
> { if (c == EOF && !n) return NULL;
> if (p = malloc(n + 1)) *(p += n) = '\0';
> else errno = ENOMEM;
> }
> return p;
> }
> return g();
> }
Let me congratulate you on a clever scheme. Quite nice.
The implementation you give uses more machinery than it
needs to. Here is a simplified version in standard C
(which incidentally also has the size limit parameter
mentioned in your other post). The only concession is
one additional parameter on the initial call, but that
could be seen as a plus since it allows getting a string
while leaving space at the beginning of the allocated area
for, eg, a struct that refers to it (or has it as a flexible
array member). Of course, if we want to avoid having to pass
the extra parameter, that can easily be done by wrapping the
call in a one-line inline function. Oh, I almost forgot -
this version also does a chunk of characters at each level
of recursion rather than just one.
char *
getline_plus( FILE *fp, size_t n, size_t most ){
enum { K = 256 };
char b[K], *p = 0;
for( size_t k = 0; k < K; k++ ){
int c = fgetc( fp ), EOL = c == EOF || c == '\n';
if( ! EOL && k < most ) b[k] = c;
else if( c == EOF && n+k == 0 ) return p;
else if( ! EOL ) return errno = EMSGSIZE, p;
else if( (p = malloc( n+k+1 )) == 0 ) return errno = ENOMEM, p;
else return p += n, p[k] = 0, memcpy( p, b, k ), p;
}
p = getline_plus( fp, n+K, most-K );
return p ? p -= K, memcpy( p, b, K ), p : p;
}
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 18:13 -0500 |
| Message-ID | <mh99uj$vbg$1@speranza.aioe.org> |
| In reply to | #60823 |
On 4/22/15 5:49 PM, Tim Rentsch wrote:
> char *
> getline_plus( FILE *fp, size_t n, size_t most ){
> enum { K = 256 };
> char b[K], *p = 0;
>
> for( size_t k = 0; k < K; k++ ){
> int c = fgetc( fp ), EOL = c == EOF || c == '\n';
> if( ! EOL && k < most ) b[k] = c;
>
> else if( c == EOF && n+k == 0 ) return p;
> else if( ! EOL ) return errno = EMSGSIZE, p;
> else if( (p = malloc( n+k+1 )) == 0 ) return errno = ENOMEM, p;
>
> else return p += n, p[k] = 0, memcpy( p, b, k ), p;
> }
>
> p = getline_plus( fp, n+K, most-K );
> return p ? p -= K, memcpy( p, b, K ), p : p;
> }
Interesting! I like the trajectory of your thought!
I think I might play with this... :-)
--
Morris Dovey
http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-28 12:46 -0700 |
| Message-ID | <kfnfv7kc9yb.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60826 |
Morris Dovey <mrdovey@iedu.com> writes:
> On 4/22/15 5:49 PM, Tim Rentsch wrote:
>> char *
>> getline_plus( FILE *fp, size_t n, size_t most ){
>> enum { K = 256 };
>> char b[K], *p = 0;
>>
>> for( size_t k = 0; k < K; k++ ){
>> int c = fgetc( fp ), EOL = c == EOF || c == '\n';
>> if( ! EOL && k < most ) b[k] = c;
>>
>> else if( c == EOF && n+k == 0 ) return p;
>> else if( ! EOL ) return errno = EMSGSIZE, p;
>> else if( (p = malloc( n+k+1 )) == 0 ) return errno = ENOMEM, p;
>>
>> else return p += n, p[k] = 0, memcpy( p, b, k ), p;
>> }
>>
>> p = getline_plus( fp, n+K, most-K );
>> return p ? p -= K, memcpy( p, b, K ), p : p;
>> }
>
> Interesting! I like the trajectory of your thought!
> I think I might play with this... :-)
Glad to hear you liked it. Two afterthoughts on the code.
First, the idea that it could be used with a non-zero value for
'n' on the first call (to allocate some extra initial space) is
flawed, because getting to EOF wouldn't ever return a null
pointer. Oops! The second point is the code could be simplified
slightly following an idea shown in a similar function given by
Stefan Ram elsethread (disclaimer: not compiled, let alone
tested):
char *
getline_plus( FILE *fp, size_t n, size_t most ){
enum { K = 256 };
char b[K], *p = 0;
for( size_t k = 0; k < K; k++ ){
int c = fgetc( fp ), EOL = c == EOF || c == '\n';
if( ! EOL && k < most ) b[k] = c;
else if( c == EOF && n+k == 0 ) return p;
else if( ! EOL ) return errno = EMSGSIZE, p;
else if( (p = malloc( n+k+1 )) == 0 ) return errno = ENOMEM, p;
else return memcpy( p+n, b, k ), p[n+k] = 0, p;
}
p = getline_plus( fp, n+K, most-K );
return p ? memcpy( p+n, b, K ), p : p;
}
This formulation is a little nicer I think since 'p' is never
modifed after being given its initial value.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-20 16:50 -0500 |
| Message-ID | <mh3sa9$gn$1@speranza.aioe.org> |
| In reply to | #60382 |
On 4/19/15 5:37 AM, Ben Bacarisse wrote: > Morris Dovey <mrdovey@iedu.com> writes: > >> On 4/17/15 2:52 PM, Ben Bacarisse wrote: > A neat idea to save space, but a shame that it's not standard C. By the > way, do you really need the struct in this version now that you are > not passing it down? I think the code would be clearer without it. I agree - and uploaded a new version without the struct. Because the world has become a bit less friendly since I wrote that code, I've written a very similar function that takes a size_t maximum line/message and aborts the operation with a EMSGSIZE error if that limit is exceeded. See http://www.iedu.com/tmp/getsmlx.c for source. I’ve done some prelim testing that looked good, but please let me know if you spot any problems. > I wonder if it would be worth using a small array in the standard C > version, i.e. reading up to N chars per recursive call rather than just > one? That way you could ameliorate the per-byte cost of stack space > making it more palatable to recursion haters? I may have a play with > that, though it's likely to be more messy than your version. Give it a whirl and please share anything that seems worthwhile! :-) -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-17 10:31 -0700 |
| Message-ID | <87egnir7aj.fsf@kst-u.example.com> |
| In reply to | #60212 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> I've been accused of talking nonsense.
> Now I might well be wrong, I'm not a mathematician.
>
> But I've posed a problem and proposed an answer. No-one else has proposed
> an alternative solution, much less proved that their alternative is correct.
> They've just asserted that I am talking nonsense and nit picked at things
> like the jargon use of "minimise" to mean "any search for extrema".
> (It's fair enough for someone who doesn't understand to be confused, I
> don't blame anyone for that. It's the nit picking that gets wearing).
I do understand your claim that "minimise" is a jargon term for
"any search for extrema". I simply don't believe it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-17 21:09 +0100 |
| Message-ID | <874moecya9.fsf@bsb.me.uk> |
| In reply to | #60212 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, April 16, 2015 at 10:11:47 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> It sounds like you are setting this as a challenge. I am not aware of >> any optimal strategy, but, in terms of memory actually used and copied, >> any exponential growth pattern avoids the quadratic behaviour of the >> naive approach. Are you saying that a Fibonacci pattern of allocations >> is known to have some theoretical advantage? I don't recall ever seeing >> that used (though a Fibonacci-like pattern of sizes is sometimes used in >> allocators that have fixed-sized blocks held in free lists). >> > I've been accused of talking nonsense. > Now I might well be wrong, I'm not a mathematician. > > But I've posed a problem and proposed an answer. I missed the proposed answer. What was it? > No-one else has proposed > an alternative solution, much less proved that their alternative is correct. > They've just asserted that I am talking nonsense and nit picked at things > like the jargon use of "minimise" to mean "any search for extrema". > (It's fair enough for someone who doesn't understand to be confused, I > don't blame anyone for that. It's the nit picking that gets wearing). > > But now you can check me out. > > Write that function, with various buffer-growing strategies. > > Then test it on a series of inputs with various hypotheses for what > the statistical distribution of "human-composed English language > messages" might be.Try linear between 1 word and 1000 words, linear > between 20,000 words and 200,000 words (novels), all 25 word tweets, > half gaussian, log-normal, and anything else you can think of that > might be realistic. Why would anyone spend time doing this work, especially with the rather artificial cost model you've proposed? In practice, it's a non-problem for most people. They use some fixed multiplier (so as to avoid the O(N^2) cost from a linear policy) and they are done. I doubt anyone uses a multiplier much larger than 3 or one much smaller than 1.5, but I also doubt anyone chooses it based on much study of the distribution of inputs. I'd consider setting a minimum start size based on such a study, but that's about it. > Am I right, wrong, or talking nonsense? This is new topic. Previously you appeared to be talking about searching for extremas (or possibly zeros) in costly-to-evaluate functions. The only claim I can recall you've made in relation to allocation strategies is this: "So, clearly, our best strategy is to get a statistical distribution of the messages coming in, and then work out some sort of formula that minimises the number of calls". That's hard to asses as right or wrong because of the vagueness of "some sort of formula". Given the cost model you've proposed, it's certainly not obvious that fewer calls corresponds to lower costs, though it will do for some formulas and some distributions of inputs. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-17 19:01 -0700 |
| Message-ID | <d97a4777-f4a9-41fa-8ffc-81e659db1e9b@googlegroups.com> |
| In reply to | #60262 |
On Friday, April 17, 2015 at 9:09:33 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Why would anyone spend time doing this work, especially with the rather > artificial cost model you've proposed? > > In practice, it's a non-problem for most people. They use some fixed > multiplier (so as to avoid the O(N^2) cost from a linear policy) and > they are done. I doubt anyone uses a multiplier much larger than 3 or > one much smaller than 1.5, but I also doubt anyone chooses it based on > much study of the distribution of inputs. I'd consider setting a > minimum start size based on such a study, but that's about it. > So most people say "the optimal answer is to grow the buffer by a factor of between 1.5 and 3". Fair enough. Doesn't that observation interest you? You've got two costs, the cost of making a call / doing a probe, and the cost of taking a chunk. I've unified them, not in a very artificial way. The problem's not contrived, either, lots of people knock up such code to cope with more or less that situation. > > "So, clearly, our best strategy is to get a statistical distribution > of the messages coming in, and then work out some sort of formula that > minimises the number of calls". > > That's hard to asses as right or wrong because of the vagueness of "some > sort of formula". Given the cost model you've proposed, it's certainly > not obvious that fewer calls corresponds to lower costs, though it will > do for some formulas and some distributions of inputs. > If you know the statistical distribution of the messages coming in, then you can optimise the strategy to cope with that distribution. To take a trivial example, if you know that every message is exactly 1K, you've got an optimal strategy there and then. But all you know is that the messages are English language text composed by a human. No one has actually sent you any messages yet, you don't really know what to expect, other than some very vague ballparks. So really the question boils down to, what's the statistical distribution of statistical distributions? But we don't need to go there yet.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-18 15:18 +0100 |
| Message-ID | <87sibxbjvl.fsf@bsb.me.uk> |
| In reply to | #60286 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, April 17, 2015 at 9:09:33 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Why would anyone spend time doing this work, especially with the rather >> artificial cost model you've proposed? >> >> In practice, it's a non-problem for most people. They use some fixed >> multiplier (so as to avoid the O(N^2) cost from a linear policy) and >> they are done. I doubt anyone uses a multiplier much larger than 3 or >> one much smaller than 1.5, but I also doubt anyone chooses it based on >> much study of the distribution of inputs. I'd consider setting a >> minimum start size based on such a study, but that's about it. >> > So most people say "the optimal answer is to grow the buffer by a > factor of between 1.5 and 3". Fair enough. Doesn't that observation > interest you? No. I'd be interested if someone really thought it was optimal (in some technical sense), but the situation is too vague for that to be the case. Do you find it interesting? > You've got two costs, the cost of making a call / doing a probe, > and the cost of taking a chunk. I've unified them, not in a very > artificial way. It's not very artificial, just rather artificial. more to the point, it's your invented measure and I see no particular interest in it (I may be wrong of course) but the context was that you suggested I do a non-trivial body of work based on it. I don't see any reason to do that. If you like the measure, you do the work. > The problem's not contrived, either, lots of people knock up such > code to cope with more or less that situation. >> >> "So, clearly, our best strategy is to get a statistical distribution >> of the messages coming in, and then work out some sort of formula that >> minimises the number of calls". >> >> That's hard to asses as right or wrong because of the vagueness of "some >> sort of formula". Given the cost model you've proposed, it's certainly >> not obvious that fewer calls corresponds to lower costs, though it will >> do for some formulas and some distributions of inputs. >> > If you know the statistical distribution of the messages coming in, > then you can optimise the strategy to cope with that distribution. > To take a trivial example, if you know that every message is > exactly 1K, you've got an optimal strategy there and then. > > But all you know is that the messages are English language text composed > by a human. No one has actually sent you any messages yet, you don't > really know what to expect, other than some very vague ballparks. > > So really the question boils down to, what's the statistical distribution > of statistical distributions? But we don't need to go there yet. Do you have anything substantive to say? Can you justify the only substantive thing you've said so far, which is that a formula that minimises the number of calls is clearly optimal? Obviously it is in some trivial cases, but your remark was a general one, and I think it's probably false in general. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-18 09:00 -0700 |
| Message-ID | <1e76a971-acde-4797-968a-2c39247dd5ed@googlegroups.com> |
| In reply to | #60320 |
On Saturday, April 18, 2015 at 3:18:14 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > You've got two costs, the cost of making a call / doing a probe, > > and the cost of taking a chunk. I've unified them, not in a very > > artificial way. > > It's not very artificial, just rather artificial. more to the point, > it's your invented measure and I see no particular interest in it (I may > be wrong of course) but the context was that you suggested I do a > non-trivial body of work based on it. I don't see any reason to do > that. If you like the measure, you do the work. > It's not exactly hard work. You think that the answer is to grow the buffer by multiplying by a factor between 1.5 and 3 every time the input exceeds the size. So pick a starting size and a multiplication factor. (Of course maybe getting a value which will perform well given the information I've given you may be non-trivial, but in that case the problem is interesting. If all values perform as well as each other, you don't have that issue, just pick random numbers and you're done). > > Do you have anything substantive to say? Can you justify the only > substantive thing you've said so far, which is that a formula that > minimises the number of calls is clearly optimal? Obviously it is in > some trivial cases, but your remark was a general one, and I think it's > probably false in general. > The task is to minimise the cost function. Or maximise the negative of the cost function if you prefer to think of it that way. You can legitimately nit-pick at the cost function.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-18 21:52 +0100 |
| Message-ID | <87zj659l5c.fsf@bsb.me.uk> |
| In reply to | #60325 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, April 18, 2015 at 3:18:14 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > You've got two costs, the cost of making a call / doing a probe, >> > and the cost of taking a chunk. I've unified them, not in a very >> > artificial way. >> >> It's not very artificial, just rather artificial. more to the point, >> it's your invented measure and I see no particular interest in it (I may >> be wrong of course) but the context was that you suggested I do a >> non-trivial body of work based on it. I don't see any reason to do >> that. If you like the measure, you do the work. >> > It's not exactly hard work. It don't think you have any idea. For one thing, you seem to think there is a simple answer. If there were, the work might be easy, but using your odd cost model, the optimal strategy will very likely be chaotic -- depending on the input sizes in a way that will be very hard (maybe impossible) to characterise. > You think that the answer is to grow the buffer by multiplying by a > factor between 1.5 and 3 every time the input exceeds the size. So > pick a starting size and a multiplication factor. No I don't -- please don't misrepresent me. I don't even think that there *is* an answer in the sense you mean, and I am almost certain that no small number in the rage 1.5 to 3 is optimal (using your cost function) for anything but contrived input size distributions. I am absolutely certain that no one multiplier is optimal (using your cost function) in any general sense. It's well known (and easy to show) that using a factor as close as possible to 1 (but ensuring that the buffer does grow by at least 1 byte) minimises the "waste" (the allocated but unused bytes) at the expense of more calls, and that using a larger factor reduces the number of re-allocation calls at the expense of more waste. People just use a small number as a pragmatic solution to a problem that is rarely worth more effort. > (Of course maybe getting a value which will perform well given > the information I've given you may be non-trivial, but in that case > the problem is interesting. If all values perform as well as each other, > you don't have that issue, just pick random numbers and you're done). What information have you given me? >> Do you have anything substantive to say? Can you justify the only >> substantive thing you've said so far, which is that a formula that >> minimises the number of calls is clearly optimal? Obviously it is in >> some trivial cases, but your remark was a general one, and I think it's >> probably false in general. Was it a general remark? Did I misunderstand it? (Not being a "competent adult speaker" I probably got the wrong end of your meaning.) > The task is to minimise the cost function. Or maximise the negative > of the cost function if you prefer to think of it that way. What are you waiting for? > You can legitimately nit-pick at the cost function. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 00:02 -0700 |
| Message-ID | <e9b1db92-77ea-438f-8212-acb6186e7396@googlegroups.com> |
| In reply to | #60351 |
On Saturday, April 18, 2015 at 10:33:43 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > (Of course maybe getting a value which will perform well given > > the information I've given you may be non-trivial, but in that case > > the problem is interesting. If all values perform as well as each other, > > you don't have that issue, just pick random numbers and you're done). > > What information have you given me? > You've been tasked with writing a program, to reduce the total amount of allocation in a growing buffer, and the input is human composed English-language messages. The last bit of information makes the problem, in David Brown's word's "half-baked". If I told you that the messages had a uniform linear distribution between 1 and 1024 bytes, you could work out an answer. But the situation as it is the the more realistic one. (Yes, you can nit-pick at the cost function). > > > The task is to minimise the cost function. Or maximise the negative > > of the cost function if you prefer to think of it that way. > > What are you waiting for? > Will do it. It's easy enough to perform the tests. Just wondering if anyone either knew the answer, or could explain why there isn't one (e.g. it's a Cantor dust type problem, such that being in a clear area isn't going to help us predict the non-clear area in any way). I don't mind being told I'm wrong if someone else has the right answer. Naturally I object when no-one else can rise to the challenge.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-04-19 00:40 -0700 |
| Message-ID | <95c00492-68f8-462f-a243-6eb790f88de1@googlegroups.com> |
| In reply to | #60366 |
But what do you speak? Cpu speed > human speed So there is no problem at all... I think the resize would use For input give people: Size[0]=1024 Size[i]=Size[i-1]+1024 But i don't know if it is right
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 03:52 -0700 |
| Message-ID | <b00faadf-d904-4ff4-bf78-ff9b605cd47b@googlegroups.com> |
| In reply to | #60368 |
On Sunday, April 19, 2015 at 8:40:34 AM UTC+1, asetof...@gmail.com wrote: > But what do you speak? > Cpu speed > human speed > So there is no problem at all... > > I think the resize would use > For input give people: > Size[0]=1024 > Size[i]=Size[i-1]+1024 > But i don't know if it is right > That's the first person who has actually put his head above the parapet. 1K is a reasonable stab at what we might expect a "human-generated message" to be. Then increase linearly by the step size.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-04-21 09:02 -0700 |
| Message-ID | <96030c95-cc9d-4f4c-8c99-ca2c55cea6e0@googlegroups.com> |
| In reply to | #60368 |
I wrote:<< But what do you speak? Cpu speed > human speed So there is no problem at all... I think the resize would use For input give people: Size[0]=1024 Size[i]=Size[i-1]+1024 But i don't know if it is right>> I forget at end resize the size of effective message len... But what about: Size[0]=800 Size[i]=Size[i-1]+2000 Size[max_i+1] = the effective len
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-19 12:58 +0000 |
| Message-ID | <5533a5ef.14456031@news.xs4all.nl> |
| In reply to | #60366 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, April 18, 2015 at 10:33:43 PM UTC+1, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > > > (Of course maybe getting a value which will perform well given > > > the information I've given you may be non-trivial, but in that case > > > the problem is interesting. If all values perform as well as each other, > > > you don't have that issue, just pick random numbers and you're done). > > > > What information have you given me? > > > You've been tasked with writing a program, to reduce the total > amount of allocation in a growing buffer, and the input is human > composed English-language messages. You don't pay us enough to write programs on such unbelievably vague specifications. "Human composed English-language messages"... _which_ human!? Messages of what kind? Who for? > I don't mind being told I'm wrong if someone else has the right > answer. Naturally I object when no-one else can rise to the > challenge. *Sigh* You've not been told that there is an answer and your is not it; you've been told, several times now, that there _is no general answer_ despite your insistence that there must be. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 07:25 -0700 |
| Message-ID | <9937e438-7b95-4573-a760-efb828e862aa@googlegroups.com> |
| In reply to | #60397 |
On Sunday, April 19, 2015 at 1:58:38 PM UTC+1, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > On Saturday, April 18, 2015 at 10:33:43 PM UTC+1, Ben Bacarisse wrote: > > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > > > > > (Of course maybe getting a value which will perform well given > > > > the information I've given you may be non-trivial, but in that case > > > > the problem is interesting. If all values perform as well as each other, > > > > you don't have that issue, just pick random numbers and you're done). > > > > > > What information have you given me? > > > > > You've been tasked with writing a program, to reduce the total > > amount of allocation in a growing buffer, and the input is human > > composed English-language messages. > > You don't pay us enough to write programs on such unbelievably vague > specifications. "Human composed English-language messages"... _which_ > human!? Messages of what kind? Who for? > > > I don't mind being told I'm wrong if someone else has the right > > answer. Naturally I object when no-one else can rise to the > > challenge. > > *Sigh* You've not been told that there is an answer and your is not it; > you've been told, several times now, that there _is no general answer_ > despite your insistence that there must be. > In your view there's no general answer. So if I grow the buffer by 1 + epsilon, where epsilon is the lowest number representable on my computer such that 1 * (1+epsilon) is different to unity, and. to be fair, we ignore any duplicate integers, I've got an answer that is as good as any other. Agreed? That's your best shot at the problem.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-19 15:51 +0000 |
| Message-ID | <5533ce97.24863718@news.xs4all.nl> |
| In reply to | #60405 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Sunday, April 19, 2015 at 1:58:38 PM UTC+1, Richard Bos wrote: > > *Sigh* You've not been told that there is an answer and your is not it; > > you've been told, several times now, that there _is no general answer_ > > despite your insistence that there must be. > > > In your view there's no general answer. > So if I grow the buffer by 1 + epsilon, where epsilon is the lowest > number representable on my computer such that 1 * (1+epsilon) is > different to unity, and. to be fair, we ignore any duplicate integers, > I've got an answer that is as good as any other. Agreed? That's your > best shot at the problem. That's not only not what I said, that's not even close to what I said, but you insist on misreading it like that, not just from me but from most other contributors to this thread. I must conclude that either you're an imbecile or you're dishonest, and to be very frank, right now my inclination is towards the latter. By now, it is _your_ onus to prove me, and the rest of us, wrong. Richard
[toc] | [prev] | [next] | [standalone]
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web