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 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-23 23:49 +0100 |
| Message-ID | <87mw1y5uid.fsf@bsb.me.uk> |
| In reply to | #60893 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, April 23, 2015 at 2:47:21 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > If you're given a nice equation for the size distribution, then it becomes >> > a different sort of problem. But all you're told is that the input is "human- >> > composed English language messages". >> > So the challenge is how to reason about that distribution. That's something >> > people seem to be unwilling to do, and they become quite aggressive >> > about it - why I don't know, >> >> Part of it is your double standard. That challenge is one you've set >> others, not yourself. Now that you've posted enough for me to know what >> it is you are interested in measuring, it turns out that there is >> nothing about it which depends on the input being "human-composed >> English language messages". That vague and ill-defined term is there >> only for other people to consider -- your experiment would give the same >> result for FLT_MAX bytes drawn from /dev/random. >> > It turns out that if we grow from 1 by repeated multiplication by a constant > over unity, and N bytes is distributed by an enemy in the worst possible > way, then as long as our constant is much smaller than N, and N is much larger > than 1, then the answer is that the optimum is to grow by a factor of > 2. I think you could derive this just from the set up, though I have only an hand-waving argument about that. Think of writing the allocation size as a number in base m -- the multiplier used. The only permitted sizes are then 1, 10, 100 and so on. The costs of these, because you sum all the allocations that lead to the final one, are (roughly) these numbers but with all the digits set to 1 (1, 11, 111, 1111 and so on). Your set up forces N to be written as a sum of numbers with the highest corresponding cost, but since all the digits must be zero or one, this maximum cost is lowest in base 2. As I say, rather vague (I'm sure you can see the holes) but I am not motivated to look very deeply into this particular setup. <snip> >> Another frustrating factor is your refusal to answer questions whilst >> continuing to shift the focus. This topic started simply as a >> distraction from the problems you were having defending some careless >> remarks about finding the minimum of a function. It's then swerved from >> being about finding an optimum strategy of allocations for certain size >> distributions to something quite different -- minimising the worst-case >> cost when the sending knows enough to construct specific message sets. >> With each swerve, you've omitted to answer many specific questions about >> what you mean, so everyone else is playing catch-up. >> > The question is how to grow a buffer. I suggest an answer, which was to grow > by Fibonnaci numbers, and I suggested an experiment. So far you have not done that experiment. You've done another one. I'm not sure why you switched. > that was rejected, and > I was accused of planning to artificially generate data to prove that my > suggestion was right and everyone else's was wrong. You've not addressed the point about about your silly insistence on human-generated English text. That's a vague requirement you insisted be taken into account by everyone else but yourself. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-24 01:07 -0700 |
| Message-ID | <539780f8-fdf3-488b-9bd6-d879fdea3549@googlegroups.com> |
| In reply to | #60963 |
On Thursday, April 23, 2015 at 11:50:57 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > It turns out that if we grow from 1 by repeated multiplication > > by a constant over unity, and N bytes is distributed by an enemy > > in the worst possible way, then as long as our constant is much > > smaller than N, and N is much larger than 1, then the answer is that > > the optimum is to grow by a factor of > > 2. > > I think you could derive this just from the set up, though I have only > an hand-waving argument about that. Think of writing the allocation > size as a number in base m -- the multiplier used. The only permitted > sizes are then 1, 10, 100 and so on. The costs of these, because you > sum all the allocations that lead to the final one, are (roughly) these > numbers but with all the digits set to 1 (1, 11, 111, 1111 and so on). > If we grow by, say ten, and have just shy of a million bytes availbale, we send 100,000 plus 1, then another 100,000 plus one, and so on, nine times. Two is the highest number that forces all digits to be one. > > Your set up forces N to be written as a sum of numbers with the highest > corresponding cost, but since all the digits must be zero or one, this > maximum cost is lowest in base 2. As I say, rather vague (I'm sure you > can see the holes) but I am not motivated to look very deeply into this > particular setup. > The sum of digits is a good way of looking at the problem, however. If the problem bores you, you're under no obligation to work on it. > > I was accused of planning to artificially generate data to prove that my > > suggestion was right and everyone else's was wrong. > > You've not addressed the point about about your silly insistence on > human-generated English text. That's a vague requirement you insisted > be taken into account by everyone else but yourself. > If we say "an unknown number of bytes" what's that supposed to mean? Say we have the series 1, 2*2, 3^3^3, 4^^4^^4^^4, 5^^^5^^^5^^^5^^^5, 6^^^^6^^^^6^^^^6^^^^6^^^^6 ... where ^ is exponentiation, ^^ is tetration, ^^^ quintation or whatever the next operation is called, and so on, and we generate the allocation requests by throwing a 1 sided die and applying the series. Is exponential growth still a viable strategy? I'd say not, you're not significantly chipping away at that last number by taking its logarithm. But it's so large that it couldn't possibly represent characters of human composed text. Maybe it does represent the number of allowed states for some particle in physics. The "human-composed English language text" stipulation is essential.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.lists@bsb.me.uk> |
|---|---|
| Date | 2015-04-24 11:51 +0100 |
| Message-ID | <878udh6bp1.fsf@bsb.me.uk> |
| In reply to | #60977 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, April 23, 2015 at 11:50:57 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > It turns out that if we grow from 1 by repeated multiplication >> > by a constant over unity, and N bytes is distributed by an enemy >> > in the worst possible way, then as long as our constant is much >> > smaller than N, and N is much larger than 1, then the answer is that >> > the optimum is to grow by a factor of >> > 2. >> >> I think you could derive this just from the set up, though I have only >> an hand-waving argument about that. Think of writing the allocation >> size as a number in base m -- the multiplier used. The only permitted >> sizes are then 1, 10, 100 and so on. The costs of these, because you >> sum all the allocations that lead to the final one, are (roughly) these >> numbers but with all the digits set to 1 (1, 11, 111, 1111 and so on). >> > If we grow by, say ten, and have just shy of a million bytes availbale, > we send 100,000 plus 1, then another 100,000 plus one, and so on, nine > times. > Two is the highest number that forces all digits to be one. I have no idea what that means, but I really don't what another question unanswered so I won't ask. >> Your set up forces N to be written as a sum of numbers with the highest >> corresponding cost, but since all the digits must be zero or one, this >> maximum cost is lowest in base 2. As I say, rather vague (I'm sure you >> can see the holes) but I am not motivated to look very deeply into this >> particular setup. >> > The sum of digits is a good way of looking at the problem, however. > > If the problem bores you, you're under no obligation to work > on it. And none if it fascinates me either, even when you have the gall to "task" with it. <snip> >> > I was accused of planning to artificially generate data to prove that my >> > suggestion was right and everyone else's was wrong. >> >> You've not addressed the point about about your silly insistence on >> human-generated English text. That's a vague requirement you insisted >> be taken into account by everyone else but yourself. >> > If we say "an unknown number of bytes" what's that supposed to mean? Exactly what it means. There not puzzle about it unless the context does not make clear what party know what. The only thing that matters about the problem you have finally settled on is the total size of the data sent in the messages. This number is know to the sender and not the receiver. What's the problem with saying that? I find it amazing that you still won't admit that the human-generated English language text condition that you are still banning on about is a red herring. It can accept that the you might once have though it contributes something to the specification, but having now seen that it does not, why not say so? > Say we have the series > 1, 2*2, 3^3^3, 4^^4^^4^^4, 5^^^5^^^5^^^5^^^5, 6^^^^6^^^^6^^^^6^^^^6^^^^6 > ... where ^ is exponentiation, ^^ is tetration, ^^^ quintation or > whatever the next operation is called, and so on, and we generate > the allocation requests by throwing a 1 sided die and applying the > series. > Is exponential growth still a viable strategy? I'd say not, you're > not significantly chipping away at that last number by taking its > logarithm. > But it's so large that it couldn't possibly represent characters > of human composed text. Maybe it does represent the number of allowed > states for some particle in physics. The "human-composed English > language text" stipulation is essential. I'm not prepared to try work out what you mean by these words. That will take hours and you won't answer any questions about it so I'll just ask this: what effect on your solution does this essential stipulation have? If I pose the same question but remove it, and say that the N bytes of data are read from /dev/random, in what way does the solution change? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-24 04:29 -0700 |
| Message-ID | <60a388a2-2a98-4393-9754-f9a1f47f4e3c@googlegroups.com> |
| In reply to | #60985 |
On Friday, April 24, 2015 at 11:52:04 AM UTC+1, Ben Bacarisse wrote: > > Exactly what it means. There not puzzle about it unless the context > does not make clear what party know what. The only thing that matters > about the problem you have finally settled on is the total size of the > data sent in the messages. This number is know to the sender and not > the receiver. What's the problem with saying that? > > I find it amazing that you still won't admit that the human-generated > English language text condition that you are still banning on about is a > red herring. It can accept that the you might once have though it > contributes something to the specification, but having now seen that it > does not, why not say so? > > I'm not prepared to try work out what you mean by these words. That > will take hours and you won't answer any questions about it so I'll just > ask this: what effect on your solution does this essential stipulation > have? If I pose the same question but remove it, and say that the N > bytes of data are read from /dev/random, in what way does the solution > change? > The model is a sub-problem. We need to know that N can be many orders of magnitude larger than the "expected message size" or David Brown chimes in and says "your optimal strategy is to allocate N bytes, there is no other answer ...". So we've got to start small (say with one byte), and x has got to be small in relation to N. Human-composed English language text fulfils those conditions - we can't sensibly put a maximum on what someone will send us and claim it's "human-composed English language text", and the only minimum we have is one byte. It's not the only set of criteria that would fulfil those conditions. As it turns out, the answer is to grow by a factor of 2 / just a whisker under 2, regardless of N. But we'd no way of knowing how things would fall out before actually trying to simulate the system / solve the equation. But we've only got the first answer. In fact the problem didn't suggest there was an enemy trying to stress out the system in a rather silly way. If there is an enemy, we need to grow the buffer by a factor of 2. First result, and I think it's solid.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-24 13:20 +0100 |
| Message-ID | <mhdcch$rqm$1@dont-email.me> |
| In reply to | #60986 |
On 24/04/2015 12:29, Malcolm McLean wrote: > On Friday, April 24, 2015 at 11:52:04 AM UTC+1, Ben Bacarisse wrote: >> have? If I pose the same question but remove it, and say that the N >> bytes of data are read from /dev/random, in what way does the solution >> change? >> > The model is a sub-problem. > We need to know that N can be many orders of magnitude larger than the > "expected message size" or David Brown chimes in and says "your optimal > strategy is to allocate N bytes, there is no other answer ...". So we've got to > start small (say with one byte), and x has got to be small in relation to N. > Human-composed English language text fulfils those conditions - we can't > sensibly put a maximum on what someone will send us and claim it's > "human-composed English language text", and the only minimum we have is > one byte. It's not the only set of criteria that would fulfil those conditions. This is similar to my requirement that 'line-oriented' text input must consist of lines no longer than some reasonable length (eg 1K or 2K characters). Otherwise it's invalid input and there's no point trying to accommodate it. However, you do have to check for that. > As it turns out, the answer is to grow by a factor of 2 / just a whisker under > 2, regardless of N. But we'd no way of knowing how things would fall out > before actually trying to simulate the system / solve the equation. > > But we've only got the first answer. In fact the problem didn't suggest there > was an enemy trying to stress out the system in a rather silly way. If there > is an enemy, we need to grow the buffer by a factor of 2. First result, and > I think it's solid. What enemy? It's quite possible that someone will simply give the wrong kind of input, for example, a 4GB video file, or an executable containing resources, when what is expected is a shopping list. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-24 06:48 -0700 |
| Message-ID | <70fd4aab-c4d0-4b68-8ca6-8594c32ad3ee@googlegroups.com> |
| In reply to | #60990 |
On Friday, April 24, 2015 at 1:20:39 PM UTC+1, Bart wrote: > On 24/04/2015 12:29, Malcolm McLean wrote: > > This is similar to my requirement that 'line-oriented' text input must > consist of lines no longer than some reasonable length (eg 1K or 2K > characters). Otherwise it's invalid input and there's no point trying to > accommodate it. However, you do have to check for that. > Exactly. You need to know something about the data you expect to get. But you don't need to know very much. > > What enemy? It's quite possible that someone will simply give the wrong > kind of input, for example, a 4GB video file, or an executable > containing resources, when what is expected is a shopping list. > The idea is that the enemy gives valid input, but always contrived to be one byte above our last allocation. So if we start at 1 and go 10, 100, 1000 etc he'll send us a series of text files, all with sizes 11, 101, 1001, etc, But they'll be valid text files, we can't legitimately reject them. So I modelled that by saying he's got N bytes, and divides them up in the worst possible way. (Not mathematically perfect, because if you have an English language message, and cut it at a random point, you don't always have two valid English language messages, but you can probably get close enough). It turns out that as long as N is much greater than our first allocation, the optimal strategy is grow the buffer by a factor of 2, regardless of N (at least if N < some massive number). But that only holds if a call to realloc() always costs exactly in proportion to the number of bytes asked for.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-25 10:16 +0000 |
| Message-ID | <553b692d.9455562@news.xs4all.nl> |
| In reply to | #60996 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Friday, April 24, 2015 at 1:20:39 PM UTC+1, Bart wrote: > > What enemy? It's quite possible that someone will simply give the wrong > > kind of input, for example, a 4GB video file, or an executable > > containing resources, when what is expected is a shopping list. > > > The idea is that the enemy gives valid input, but always contrived to be one > byte above our last allocation. No, that's _your_ idea. The rest of us are talking about the problem in the real world, where you have to deal with _all_ circumstances, not just the ones that happen to appear in your textbook. Richard
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-24 15:48 +0100 |
| Message-ID | <mhdl28$tg9$1@dont-email.me> |
| In reply to | #60990 |
On 24/04/2015 15:00, Stefan Ram wrote:
> Bartc <bc@freeuk.com> writes:
>> This is similar to my requirement that 'line-oriented' text input must
>> consist of lines no longer than some reasonable length (eg 1K or 2K
>> characters). Otherwise it's invalid input and there's no point trying to
>> accommodate it. However, you do have to check for that.
>
> That's an advantage of C++. One writes:
>
> #include <iostream>
> #include <string>
> ... { ::std::string line; ::std::cin >> line; ... } ...
>
> and one just does not worry anymore about such stuff.
It can also be a disadvantage. And you still do have to worry about it.
I tried this:
#include <iostream>
#include <string>
int main(void){
std::string line;
std::cin >> line;
std::cout << line;
}
And gave it a file consisting of 3.7 billion "A"s.
To be fair, it dealt with it a lot better than I expected**: only taking
8 minutes and only using 1.2GB of RAM, as I was expecting an
out-of-memory condition, or my machine becoming unresponsive for a long
time.
Still, given erroneous input and with no signs of what it's up to, it
can be worrying for the user who may well have to abort the program.
But giving the same input to one of my programs expecting a line of
text, the result (be it a truncated line, error message, or whatever is
wanted) is instant, without hundreds of MB of RAM used either.
(**I did another test and found out why! By printing the length of the
line instead, the length was truncated to 2147483591 characters.
So, basically, the C++ code doesn't work either! It just silently
truncates to about 2 billion characters instead of the 16KB I used.
Although I'm not still now sure how it manages to fit 2GB of data into
1.2GB of memory, unless there was a memory peak I missed, or it was
swapped out.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-24 10:05 -0700 |
| Message-ID | <a60b985f-30fa-42c1-9d1d-cfedab03a5f0@googlegroups.com> |
| In reply to | #60990 |
On Friday, April 24, 2015 at 3:00:32 PM UTC+1, Stefan Ram wrote:
> Bartc <bc@freeuk.com> writes:
>
> That's an advantage of C++. One writes:
>
> #include <iostream>
> #include <string>
> ... { ::std::string line; ::std::cin >> line; ... } ...
>
> and one just does not worry anymore about such stuff.
.
How long is a piece of string?
The question is how the implementation determines that. It's
reasonable to shunt your problems off to someone else, but that
doesn't make them go away.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-24 22:59 +0100 |
| Message-ID | <87egn73kea.fsf@bsb.me.uk> |
| In reply to | #60986 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, April 24, 2015 at 11:52:04 AM UTC+1, Ben Bacarisse wrote: <snip> >> [...] I'll just >> ask this: what effect on your solution does this essential stipulation >> have? If I pose the same question but remove it, and say that the N >> bytes of data are read from /dev/random, in what way does the solution >> change? >> > The model is a sub-problem. > We need to know that N can be many orders of magnitude larger than the > "expected message size" or David Brown chimes in and says "your optimal > strategy is to allocate N bytes, there is no other answer ...". So we've got to > start small (say with one byte), and x has got to be small in relation to N. > Human-composed English language text fulfils those conditions - we can't > sensibly put a maximum on what someone will send us and claim it's > "human-composed English language text", and the only minimum we have is > one byte. It's not the only set of criteria that would fulfil those > conditions. I never said otherwise. The problem with the stipulation is that it specifies three unnecessary things (being human-generated, being in English and being text) whilst failing to specify the things you need. Using three unnecessary conditions to imply what you want is simply absurd. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-26 00:16 -0700 |
| Message-ID | <ad47f914-eff9-4908-bfcc-bf4040500037@googlegroups.com> |
| In reply to | #61109 |
On Saturday, April 25, 2015 at 11:36:55 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > Human-composed English language text fulfils those conditions - we can't > > sensibly put a maximum on what someone will send us and claim it's > > "human-composed English language text", and the only minimum we have is > > one byte. It's not the only set of criteria that would fulfil those > > conditions. > > I never said otherwise. The problem with the stipulation is that it > specifies three unnecessary things (being human-generated, being in > English and being text) whilst failing to specify the things you need. > Using three unnecessary conditions to imply what you want is simply > absurd. > Firstly, we didn't know a priori what the answer would be. Secondly, we haven't come up with an equation and solved it, we've only done a simulation. So whilst we can show that x = 2 as N becomes very large, we haven't actually shown that if N is vastly over FLT_MAX, x remains 2. Thirdly, whilst it appears to be a result, the enemy with N bytes hypothesis is a bit silly, and actually can't be carried out exactly fulfilling the criteria - you can't take Clarissa, take the last 100,001 bytes, and have an "English language message", you've got to cut a bit more intelligently than that. So that leads us on the the next question, how can we get a more relevant answer to the original question? Any offers, or just assertions that no answer is possible?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-24 04:39 -0700 |
| Message-ID | <d1f0e7c9-7c2d-4cea-8b07-ed82b5904f45@googlegroups.com> |
| In reply to | #60985 |
On Friday, April 24, 2015 at 11:52:04 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > Say we have the series > > 1, 2*2, 3^3^3, 4^^4^^4^^4, 5^^^5^^^5^^^5^^^5, 6^^^^6^^^^6^^^^6^^^^6^^^^6 > > ... where ^ is exponentiation, ^^ is tetration, ^^^ quintation or > > whatever the next operation is called, and so on, and we generate > > the allocation requests by throwing a 1 sided die and applying the > > series. > > Is exponential growth still a viable strategy? I'd say not, you're > > not significantly chipping away at that last number by taking its > > logarithm. > > But it's so large that it couldn't possibly represent characters > > of human composed text. Maybe it does represent the number of allowed > > states for some particle in physics. The "human-composed English > > language text" stipulation is essential. > > I'm not prepared to try work out what you mean by these words. That > will take hours and you won't answer any questions about it so I'll just > ask this: what effect on your solution does this essential stipulation > have? If I pose the same question but remove it, and say that the N > bytes of data are read from /dev/random, in what way does the solution > change? > We've shown by computer simulation that when N is 1000, the answer is a bit less then 2, when it's a million it's as close to 2 as we can measure, when it's FLT_MAX, it's also as close to 2 as we can measure. That does not prove that the answer is 2 as N approaches infinity. Maybe the answer is generated by an unbounded series which grows extremely slowly. However it's not a practical issue, because we know that N can never go anything like as big as FLT_MAX.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-24 22:59 +0100 |
| Message-ID | <87lhhf3kec.fsf@bsb.me.uk> |
| In reply to | #60987 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > We've shown by computer simulation To whom (other than you) does that "we" refer? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-23 08:17 -0500 |
| Message-ID | <mhardd$h6a$1@speranza.aioe.org> |
| In reply to | #60847 |
On 4/23/15 3:24 AM, Bartc wrote: > On 22/04/2015 22:56, Morris Dovey wrote: >> On 4/22/15 4:33 PM, Bartc wrote: >>> Use the stack via recursion? >> >> Yes. > > OK, but I think that will have its own problems that might end up being > worse than the traditional buffer solutions: > > * If the stack is fixed-size, it will overflow and probably crash on > large inputs. > > * If the stack grows, that is little different from growing a buffer. > > * If the stack can grow, but only up to a certain limit, then it > crashes, that combines the worst features! > > * If the stack can grow, then you don't have any control over the steps > it uses (however, it can only grow once to a certain size). > > * If the stack can grow, then usually this will be permanent. If it gets > to a very large size on one particular input, then there is no way of > deallocating that, and the machine might stay crippled. > > * With recursion, a stack can grow and (permanently) eat up memory at at > least a magnitude faster rate than with a simple character buffer. > > * With your scheme, especially if the stack has to be extended, you will > need twice the memory to read large buffers. So for a 1 billion > character buffer, you will need 2 billion characters of storage, and can > only recover half of that. Time to get our feet back on the ground. If you need a spooler, then use a spooler - these routines weren’t intended for slurping up massive amounts of data disguised as a "line" in one go. I trust that you're capable of making sensible choices in the building-blocks you use. :-) Compiled with gcc's -O3 option, getsmx.c generated 65 instructions - which seemed like a reasonable cost for the capability and convenience provided. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-04-22 16:49 -0500 |
| Message-ID | <oi5gjapkln2deekgd5nl4v28gs6miafj5t@4ax.com> |
| In reply to | #60796 |
On Wed, 22 Apr 2015 16:17:40 -0500, Morris Dovey <mrdovey@iedu.com> wrote: >On 4/22/15 3:49 PM, Bartc wrote: >> On 22/04/2015 21:25, Morris Dovey wrote: > >>> The approach I took has been sufficient to my needs. >> >> Which approach is that, to just allocate N bytes of storage according to >> need? But as Keith said, you won't know what N is in advance. You would >> need to over-allocate (as with my fixed-length buffer), or read the >> input twice if possible, or you will have to grow a buffer. (Or, as >> people here like doing, manage without a line-buffer at all. But that >> doesn't solve the problem for when it /is/ needed.) > >That's exactly the approach taken. The line is read once (but not into a >buffer) and the value of N is determined as it's read. At end-of-line >that N value is used to allocate an exact-size buffer into which all the >chars in the line are stored. > >There is no need to over-allocate, read twice, or "grow" (which may >require behind-the-scenes copying) a too-small buffer. All of those >things are "features" of the primitive paradigm which says chars must be >placed into a buffer as they are read. > >I'm simply applying a different paradigm. Even if you can assume that someone else is magically going to have all the storage needed to read and hold a line for you, what about the case where you can have C-like* line continuations? You've got exactly the same problem building the logical line out of the physical lines. *Only as an example, many similar things exist.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 17:01 -0500 |
| Message-ID | <mh95ns$m6e$1@speranza.aioe.org> |
| In reply to | #60804 |
On 4/22/15 4:49 PM, Robert Wessel wrote: > Even if you can assume that someone else is magically going to have > all the storage needed to read and hold a line for you, what about > the case where you can have C-like* line continuations? You've got > exactly the same problem building the logical line out of the > physical lines. Of course. It's a line input function, not an application. :-) > *Only as an example, many similar things exist. They do, and dealing with such issues is what programmers are paid to do. This simply makes the programming task easier. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-22 17:51 -0400 |
| Message-ID | <553817F1.4060701@verizon.net> |
| In reply to | #60796 |
On 04/22/2015 05:17 PM, Morris Dovey wrote: > That's exactly the approach taken. The line is read once (but not into a > buffer) and the value of N is determined as it's read. At end-of-line > that N value is used to allocate an exact-size buffer into which all the > chars in the line are stored. > > There is no need to over-allocate, read twice, or "grow" (which may > require behind-the-scenes copying) a too-small buffer. All of those > things are "features" of the primitive paradigm which says chars must be > placed into a buffer as they are read. > > I'm simply applying a different paradigm. I found that description very confusing, so I tracked back to previous messages your wrote, and found your code for getsml.c, which seems to be what you're talking about (let me know if it's not). I wasn't sufficiently interested the first time you mentioned it to bother reading that code. It seems to me that your code uses recursion to essentially treat the stack itself as a buffer, and automatically assumes (untestably) that the stack is large enough to hold all of the characters. On some implementations of C that I've used, each level of recursion would waste at least 11 bytes of space (to store the return address and to ensure correct alignment) in order to store one byte of data on the stack. I don't think your "different" paradigm is a better paradigm. I think I like just about any of the other "primitive" alternatives mentioned above better than that one.
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 17:35 -0500 |
| Message-ID | <mh97oc$qn5$1@speranza.aioe.org> |
| In reply to | #60805 |
On 4/22/15 4:51 PM, James Kuyper wrote: > On 04/22/2015 05:17 PM, Morris Dovey wrote: > >> That's exactly the approach taken. The line is read once (but not >> into a buffer) and the value of N is determined as it's read. At >> end-of-line that N value is used to allocate an exact-size buffer >> into which all the chars in the line are stored. >> >> There is no need to over-allocate, read twice, or "grow" (which >> may require behind-the-scenes copying) a too-small buffer. All of >> those things are "features" of the primitive paradigm which says >> chars must be placed into a buffer as they are read. >> >> I'm simply applying a different paradigm. > > I found that description very confusing, so I tracked back to > previous messages your wrote, and found your code for getsml.c, which > seems to be what you're talking about (let me know if it's not). I > wasn't sufficiently interested the first time you mentioned it to > bother reading that code. Okay. I'm not a salesman. :-) > It seems to me that your code uses recursion to essentially treat > the stack itself as a buffer, and automatically assumes (untestably) > that the stack is large enough to hold all of the characters. On > some implementations of C that I've used, each level of recursion > would waste at least 11 bytes of space (to store the return address > and to ensure correct alignment) in order to store one byte of data > on the stack. I don't think your "different" paradigm is a better > paradigm. I think I like just about any of the other "primitive" > alternatives mentioned above better than that one. True. I didn't (and won't) address environment/virtualization and implementation issues - but, having said that, I will say that I haven't gone out of my way to ignore the effects of Moore's Law... -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-22 17:45 -0700 |
| Message-ID | <878udjk6yr.fsf@kst-u.example.com> |
| In reply to | #60794 |
Bartc <bc@freeuk.com> writes:
[...]
> I managed for a decade or two with a fixed line-buffer limits of some
> 132 characters. It's grown over the years and I think now it's up to
> 1K or 2K characters. This is for line-oriented input; anything above
> that is not really line-oriented (no-one has a display that wide).
>
> Of course there's plenty of text input that could be longer for
> various reasons (machine-generated database records for example, with
> one record per line), but you just don't class that as simple
> line-oriented data, and you use a different approach.
If you happen to have a set of tools that are already designed to work
with text files with arbitrarily long lines, it can be very handy to use
those same tools with text-like files with *very* long lines. Why
reinvent the wheel? (The GNU coreutils package is an example.)
--
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-04-23 09:29 +0100 |
| Message-ID | <mhaafm$etb$1@dont-email.me> |
| In reply to | #60833 |
On 23/04/2015 01:45, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > [...] >> I managed for a decade or two with a fixed line-buffer limits of some >> 132 characters. It's grown over the years and I think now it's up to >> 1K or 2K characters. This is for line-oriented input; anything above >> that is not really line-oriented (no-one has a display that wide). >> >> Of course there's plenty of text input that could be longer for >> various reasons (machine-generated database records for example, with >> one record per line), but you just don't class that as simple >> line-oriented data, and you use a different approach. > > If you happen to have a set of tools that are already designed to work > with text files with arbitrarily long lines, it can be very handy to use > those same tools with text-like files with *very* long lines. Why > reinvent the wheel? (The GNU coreutils package is an example.) But I haven't got such a tool. And I strongly disagree with tolerating text files with very long lines without complaining. If I /expect/ such files, then I don't class them as line-oriented, and might use a file-oriented approach or whatever is more appropriate. I don't really want to bring down the system just because I like to be tolerant. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web