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 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-22 21:49 +0100 |
| Message-ID | <mh91ff$l11$1@dont-email.me> |
| In reply to | #60791 |
On 22/04/2015 21:25, Morris Dovey wrote: > On 4/22/15 1:38 PM, Keith Thompson wrote: >> Morris Dovey <mrdovey@iedu.com> writes: >>> "Growing" a buffer is an inherently wasteful process - a >>> sub-optimal use of available resources. If/when you want a message >>> in a buffer, just get the message, allocate a buffer of the exact >>> size needed, put the message into it, and return a pointer. >> >> That's not always possible. Consider reading lines from an text >> file. If you're not able to seek (say, if the input is coming in as >> a continuous stream rather than being read from a disk file), then >> you have to be able to deal with arbitrarily long lines unless you >> can impose a maximum line length. > Why not? I did a Google search on [ number of characters in the bible ] > and the first reference came up with "The number of characters in the > Bible is known to a fairly good precision: I counted 4017010 characters > in the Authorized version." If you encounter (or expect to encounter) > LINES longer than that, you may want to adopt some other strategy - but > I haven't (yet) seen a need. 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. > 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.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 16:17 -0500 |
| Message-ID | <mh935i$fuf$1@speranza.aioe.org> |
| In reply to | #60794 |
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. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-22 22:33 +0100 |
| Message-ID | <mh9422$v66$1@dont-email.me> |
| In reply to | #60796 |
On 22/04/2015 22:17, Morris Dovey 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. OK, now I'm curious. If you don't store the characters into a buffer as they are read, and you don't read them again, where *do* you keep the (potentially) millions of characters while they await the buffer you're going to allocate when you've found an end-of-line? Use the stack via recursion? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-22 16:56 -0500 |
| Message-ID | <mh95em$kv2$1@speranza.aioe.org> |
| In reply to | #60800 |
On 4/22/15 4:33 PM, Bartc wrote: > Use the stack via recursion? Yes. -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-23 09:24 +0100 |
| Message-ID | <mhaa6c$e1k$1@dont-email.me> |
| In reply to | #60806 |
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. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-23 02:25 -0700 |
| Message-ID | <286d0d9d-0891-4cc4-ad27-0eaf81359c4d@googlegroups.com> |
| In reply to | #60847 |
On Thursday, April 23, 2015 at 9:24:51 AM UTC+1, Bart wrote: > On 22/04/2015 22:56, Morris Dovey wrote: > > > 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. > It's quite common that dynamic memory requests could in fact be rewritten as expandable variable-length arrays, with only the last request expandable, and everything freed in reverse order. So there's a case for providing a massive stack. > > * If the stack grows, that is little different from growing a buffer. > It's exactly the same problem, except that instead of saying "the input is human-composed English language messages", we're saying, "the input is memory requests from a recursive algorithm". Whilst we can talk about "the largest possible English language text message" in at least a slightly sensible way (the longest published novel in English is Clarissa, at 984,870 words, but of course you have to specify "published by a mainstream publisher), and we can maybe make a stab at the expected message size (we can't get onto that because of messing about by certain people), it become a lot harder when we're talking about something as vague as "memory requests from a recursive algorithm of unknown purpose". > > * 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. > Yes, the stack is a cheat in a sense. But nowadays it is actually a practical solution. But another practical solution is to allocate 10 MB (a high estimate for 1 million words), and throw out anything above that. The machine I'm typing this at won't even notice a request for 10 MB of memory. However that assumes you know you have a modern machine, which wasn't information I gave.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-04-23 08:24 -0400 |
| Message-ID | <Fv5_w.87085$fV3.69385@fx25.iad> |
| In reply to | #60847 |
On 4/23/15 4: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. > But since the original problem had a "cost" function that only counted sum of all bytes allocated on the heap, and implicitly defined the stack to be "free", it becomes the only optimal solution since we aren't given a model for the distribution of the size of requests to come up with any sort of reasonable buffer based solution.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-23 06:18 -0700 |
| Message-ID | <6bebfd70-8a5e-4f0e-a644-676cd1c96eaf@googlegroups.com> |
| In reply to | #60879 |
On Thursday, April 23, 2015 at 1:24:13 PM UTC+1, Richard Damon wrote: > > But since the original problem had a "cost" function that only counted > sum of all bytes allocated on the heap, and implicitly defined the stack > to be "free", it becomes the only optimal solution since we aren't given > a model for the distribution of the size of requests to come up with any > sort of reasonable buffer based solution. > It doesn't really implicitly declare the stack to be free. It implicitly declares the stack to be small in relation to the input, or at least not know to be not small in relation to the input. That's also the position taken by the C standard. 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, Kenny would doubtless have some psychological insight. But we've established a few things - there are physical limits we can put on the size, and we can chase those physical limits exponentially. We've also established that all probability density functions are negligible at infinity (at least if that's the mathematical way to express it), there's no way of defining a PDF such that this isn't the case, even if we try fancy work with fractals. So if you can establish a high physical limit, the probability of actually getting an input up to that physical limit must be negligible. But there's more that we can establish about "human-composed English language text messages". The problem isn't hopeless.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.lists@bsb.me.uk> |
|---|---|
| Date | 2015-04-23 14:47 +0100 |
| Message-ID | <87mw1z6jof.fsf@bsb.me.uk> |
| In reply to | #60886 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > 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. 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. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-23 07:16 -0700 |
| Message-ID | <bc5ff600-46f6-46c6-9205-e09e0867e32a@googlegroups.com> |
| In reply to | #60889 |
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. So we need to establish that that result is solid, that there's no error in the code (always possible), or some unwarranted assumption (maybe the fact that FLT_MAX is likely to be an exact power of 2 somehow biases it). Then we've made our first step. As it turns out, as we pass a ridiculous limit, we get the same result as if we pass a sensible one, maybe minus a tiny amount - I suspect that the optimal answer is to grow by a little bit under 2, and that little bit gets low and lower as N approaches infinity. But it might be that in fact the optimal answer is to grow by infinity at infinity, and isn't something like the series 1/1 +1/2 + 1/3 + 1/4 ... not quite bounded, but you'll never reach ten on a computer running an Intel chip. > > 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. 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. So I flung that back at them. OK, given the assumption that I will do this, what's your best strategy?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-23 17:20 +0200 |
| Message-ID | <mhb2i5$ata$1@dont-email.me> |
| In reply to | #60893 |
On 23/04/15 16:16, Malcolm McLean wrote: > > As it turns out, as we pass a ridiculous limit, we get the same result as if > we pass a sensible one, maybe minus a tiny amount - I suspect that > the optimal answer is to grow by a little bit under 2, and that little bit > gets low and lower as N approaches infinity. But it might be that in fact > the optimal answer is to grow by infinity at infinity, and isn't something > like the series 1/1 +1/2 + 1/3 + 1/4 ... not quite bounded, but you'll > never reach ten on a computer running an Intel chip. I know you don't like maths or facts to get in the way of a good claim, but the sum 1/1 + 1/2 + 1/3 + ... + 1/n approaches ln(n). So you reach 10 after around e^10 steps, or 22026. It's a challenge to get good enough control of rounding errors, but you can get close by counting down rather than up, and it is certainly possible on a normal PC.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-23 08:44 -0700 |
| Message-ID | <e9d4bae6-88f0-45ac-a01f-c55ec68bbd1b@googlegroups.com> |
| In reply to | #60903 |
On Thursday, April 23, 2015 at 4:20:42 PM UTC+1, David Brown wrote: > On 23/04/15 16:16, Malcolm McLean wrote: > > > > As it turns out, as we pass a ridiculous limit, we get the same result as if > > we pass a sensible one, maybe minus a tiny amount - I suspect that > > the optimal answer is to grow by a little bit under 2, and that little bit > > gets low and lower as N approaches infinity. But it might be that in fact > > the optimal answer is to grow by infinity at infinity, and isn't something > > like the series 1/1 +1/2 + 1/3 + 1/4 ... not quite bounded, but you'll > > never reach ten on a computer running an Intel chip. > > I know you don't like maths or facts to get in the way of a good claim, > but the sum 1/1 + 1/2 + 1/3 + ... + 1/n approaches ln(n). So you reach > 10 after around e^10 steps, or 22026. It's a challenge to get good > enough control of rounding errors, but you can get close by counting > down rather than up, and it is certainly possible on a normal PC. > I make no claims to be a mathematician. In fact I've said on several occasions that a mathematician would probably find the problem of finding an optimal coefficient of expansion for a memory buffer/ search term very trivial. But no-one here has proposed a solution.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-25 10:14 +0000 |
| Message-ID | <553b68b4.9334453@news.xs4all.nl> |
| In reply to | #60908 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > I make no claims to be a mathematician. In fact I've said on several occasions > that a mathematician would probably find the problem of finding an > optimal coefficient of expansion for a memory buffer/ search term very trivial. Yes, in the sense that "immediately realising that there _is_ no universal solution for such a randomly phrased problem" is an allowed solution in mathematics. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-25 04:04 -0700 |
| Message-ID | <16eb8307-8d60-4313-ac33-d5538bfdfeaa@googlegroups.com> |
| In reply to | #61061 |
On Saturday, April 25, 2015 at 11:14:53 AM UTC+1, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > Yes, in the sense that "immediately realising that there _is_ no > universal solution for such a randomly phrased problem" is an allowed > solution in mathematics. > That's why a lot of Western mathematicians find fuzzy logic difficult. Japanese and Chinese thinkers are a lot more comfortable with the concept, and it's important in computer programming. We know the optimum strategy under the "enemy" hypothesis, but it's a bit silly and unrealistic. First thing is to agree that the answer for the enemy hypothesis is right, and there is no better strategy given the assumptions. But that's only a first step towards solving the original problem. However we know that growth by 1 + DBL_EPSILON will be suboptimal, and growth by DBL_MAX will be suboptimal. So logic tells us that there's an exponential growth strategy between those two values which is better than either. Maybe one value, or maybe a range of values between which behaviour become chaotic. Can we narrow it down any further, given that the answer for the worst distribution case is 2?
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-25 12:22 +0000 |
| Message-ID | <553b8643.16901578@news.xs4all.nl> |
| In reply to | #61070 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, April 25, 2015 at 11:14:53 AM UTC+1, Richard Bos wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > > Yes, in the sense that "immediately realising that there _is_ no > > universal solution for such a randomly phrased problem" is an allowed > > solution in mathematics. > > > That's why a lot of Western mathematicians find fuzzy logic difficult. There's nothing fuzzy about it. "There is known to be no perfect solution, so just use a good enough one" is perfectly easy to accept for any Western mathematician. It seems to be different for Lit-Critters, but actual scientists and mathematicians find the concept of accepting the imperfection of their own opinions _and_ the concept of there being no perfect solution perfectly understandable. > We know the optimum strategy under the "enemy" hypothesis, but > it's a bit silly and unrealistic. First thing is to agree that > the answer for the enemy hypothesis is right, No. First thing is to realise that your artificial enemy construction is ridiculous, and in the real world there _is_ no single optimal solution and many which are good enough for practical work. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-25 10:53 -0700 |
| Message-ID | <356a8bfd-9750-41fa-aa28-153d109664b9@googlegroups.com> |
| In reply to | #61078 |
On Saturday, April 25, 2015 at 1:22:59 PM UTC+1, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > No. First thing is to realise that your artificial enemy construction is > ridiculous, and in the real world there _is_ no single optimal solution > and many which are good enough for practical work. > It wasn't my suggestion. It was someone else's. I suggested a few tests on real data, and this was rejected - the idea was that I would artificially pick the worst dataset for everybody else's algorithm. Under one particular set of assumptions, the optimum is to multiply by a factor of two. So if we've no better answers, that's got to be the optimum - there's a local minimum at 2 given one set of assumptions, albeit unlikely ones, and we can't say anything else of value. So the optimum is to multiply the buffer by a factor of two. But is there any advance on this logic?
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-23 16:48 +0100 |
| Message-ID | <mhb475$h6d$1@dont-email.me> |
| In reply to | #60903 |
On 23/04/2015 16:20, David Brown wrote: > On 23/04/15 16:16, Malcolm McLean wrote: >> >> As it turns out, as we pass a ridiculous limit, we get the same result as if >> we pass a sensible one, maybe minus a tiny amount - I suspect that >> the optimal answer is to grow by a little bit under 2, and that little bit >> gets low and lower as N approaches infinity. But it might be that in fact >> the optimal answer is to grow by infinity at infinity, and isn't something >> like the series 1/1 +1/2 + 1/3 + 1/4 ... not quite bounded, but you'll >> never reach ten on a computer running an Intel chip. > > I know you don't like maths or facts to get in the way of a good claim, > but the sum 1/1 + 1/2 + 1/3 + ... + 1/n approaches ln(n). So you reach > 10 after around e^10 steps, or 22026. I get 10.00043 after 12367 steps (although on a PC running an AMD chip, not Intel; maybe that makes a difference...). Are you sure that series gives ln(n)? I've tried to look it up and can only see one for ln(1+n), and it's a different series. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-24 12:49 +0200 |
| Message-ID | <mhd71v$8i9$1@dont-email.me> |
| In reply to | #60909 |
On 23/04/15 17:48, Bartc wrote: > On 23/04/2015 16:20, David Brown wrote: >> On 23/04/15 16:16, Malcolm McLean wrote: >>> >>> As it turns out, as we pass a ridiculous limit, we get the same >>> result as if >>> we pass a sensible one, maybe minus a tiny amount - I suspect that >>> the optimal answer is to grow by a little bit under 2, and that >>> little bit >>> gets low and lower as N approaches infinity. But it might be that in >>> fact >>> the optimal answer is to grow by infinity at infinity, and isn't >>> something >>> like the series 1/1 +1/2 + 1/3 + 1/4 ... not quite bounded, but you'll >>> never reach ten on a computer running an Intel chip. >> >> I know you don't like maths or facts to get in the way of a good claim, >> but the sum 1/1 + 1/2 + 1/3 + ... + 1/n approaches ln(n). So you reach >> 10 after around e^10 steps, or 22026. > > I get 10.00043 after 12367 steps (although on a PC running an AMD chip, > not Intel; maybe that makes a difference...). > > Are you sure that series gives ln(n)? I've tried to look it up and can > only see one for ln(1+n), and it's a different series. > I was not very accurate in what I wrote. The series 1/1 + 1/2 + ... + 1/n sums to ln(n) + gamma + error(n), where error(n) is approximately 1/2n and gamma is a constant (about 0.57721). Taking gamma into account (but ignoring the error term, as it gets small for big n), we get to 10 after e^(10 - 0.57721) steps - or 12367. It's always nice when theory and practice agree (once the theory is right, of course :-)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.lists@bsb.me.uk> |
|---|---|
| Date | 2015-04-23 20:40 +0100 |
| Message-ID | <87618m7hvh.fsf@bsb.me.uk> |
| In reply to | #60903 |
David Brown <david.brown@hesbynett.no> writes: > On 23/04/15 16:16, Malcolm McLean wrote: >> >> As it turns out, as we pass a ridiculous limit, we get the same result as if >> we pass a sensible one, maybe minus a tiny amount - I suspect that >> the optimal answer is to grow by a little bit under 2, and that little bit >> gets low and lower as N approaches infinity. But it might be that in fact >> the optimal answer is to grow by infinity at infinity, and isn't something >> like the series 1/1 +1/2 + 1/3 + 1/4 ... not quite bounded, but you'll >> never reach ten on a computer running an Intel chip. > > I know you don't like maths or facts to get in the way of a good claim, > but the sum 1/1 + 1/2 + 1/3 + ... + 1/n approaches ln(n). So you reach > 10 after around e^10 steps, or 22026. It's a challenge to get good > enough control of rounding errors, but you can get close by counting > down rather than up, and it is certainly possible on a normal PC. I don't think adding 1/22026 to something near 10 is much of a challenge for modern FP hardware. For example, in Haskell, we get Prelude> sum [1/n | n <- [1..22026]] 10.577217217899587 Prelude> sum [1/n | n <- reverse [1..22026]] 10.57721721789957 The two sums are in very close agreement. In this case, the forward sum happens slightly more accurate, with the actual value being 10.577217217899580808403980720840... As BartC pointed out we're way over 10 already. Maybe Malcolm was thinking of the number of terms needed for the sum to exceed 100. That's a whopping 15092688622113788323693563264538101449859497 if Martin Gardner was correct in his column in Scientific American. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-23 13:03 -0700 |
| Message-ID | <3e5c7284-d23c-49f0-a4dd-350e50f8a136@googlegroups.com> |
| In reply to | #60937 |
On Thursday, April 23, 2015 at 8:40:57 PM UTC+1, Ben Bacarisse wrote: > > I don't think adding 1/22026 to something near 10 is much of a challenge > for modern FP hardware. For example, in Haskell, we get > > Prelude> sum [1/n | n <- [1..22026]] > 10.577217217899587 > Prelude> sum [1/n | n <- reverse [1..22026]] > 10.57721721789957 > > The two sums are in very close agreement. In this case, the forward sum > happens slightly more accurate, with the actual value being > 10.577217217899580808403980720840... > > As BartC pointed out we're way over 10 already. Maybe Malcolm was > thinking of the number of terms needed for the sum to exceed 100. > That's a whopping 15092688622113788323693563264538101449859497 if Martin > Gardner was correct in his column in Scientific American. > No, Malcolm did a quick in head calculation and underestimated the value at which N becomes "impossible" by a factor of 10. Which is a moral for the buffer growth problem. When numbers get very high, back of envelope calculations will only give the ballpark of the logarithm of the answer.
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web