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 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-18 14:08 +0200 |
| Message-ID | <mgthet$l37$1@dont-email.me> |
| In reply to | #60305 |
On 18/04/15 13:22, Malcolm McLean wrote: > On Saturday, April 18, 2015 at 12:16:32 PM UTC+1, David Brown wrote: >> >> And for this problem, there is /no/ solution. >> > You can easily test various strategies, then feed them messages with > plausible length distributions, and see how each performs under > each hypothesis. No, you can't do that. Your problem (as posed) is completely hypothetical and unrealistic. You can't use trial and error. And even if you /did/ use trial and error, you can't claim to have found an optimum strategy - at best you could see that one strategy was better than another on the test sample used. Plenty of people (myself included) have given ideas and suggestions for efficient and practical ways of dealing with a real-world variation of your problem. Maybe I'll write out a proof of my claim that there is no optimum strategy for the problem you posed. (Of course, in trying to do so I might find I was wrong!). > However you can't really say which of the plausible distributions > is going to be most likely. I'm not quite sure what a "statistical > distribution of statistical distributions" really means in statistical > theory. Whilst I use a lot of mathematics for my job, I'm ultimately > not a mathematician. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-18 06:00 -0700 |
| Message-ID | <b2c5db34-5124-4cee-aa5c-7606566ff95d@googlegroups.com> |
| In reply to | #60309 |
On Saturday, April 18, 2015 at 1:09:04 PM UTC+1, David Brown wrote: > On 18/04/15 13:22, Malcolm McLean wrote: > > On Saturday, April 18, 2015 at 12:16:32 PM UTC+1, David Brown wrote: > >> > >> And for this problem, there is /no/ solution. > >> > > You can easily test various strategies, then feed them messages with > > plausible length distributions, and see how each performs under > > each hypothesis. > > No, you can't do that. Your problem (as posed) is completely > hypothetical and unrealistic. You can't use trial and error. And even > if you /did/ use trial and error, you can't claim to have found an > optimum strategy - at best you could see that one strategy was better > than another on the test sample used. > > Plenty of people (myself included) have given ideas and suggestions for > efficient and practical ways of dealing with a real-world variation of > your problem. > > Maybe I'll write out a proof of my claim that there is no optimum > strategy for the problem you posed. (Of course, in trying to do so I > might find I was wrong!). > We know that if we grow the buffer by one byte each time, we'll get a very poor result. And we know that if we take the maximum physically possible text message, allocate that, we'll get a poor result. So there's a strategy in between which is better than either, and the idea that the problem has no solution at all is obviously false. Ben's suggested that the optimal answer is to grow the buffer by a factor between 1.5 and 3. Does that sound reasonable to you? What about growing by 1.1 or by 10?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-18 21:42 +0200 |
| Message-ID | <mguc13$tbe$1@dont-email.me> |
| In reply to | #60314 |
On 18/04/15 15:00, Malcolm McLean wrote: > On Saturday, April 18, 2015 at 1:09:04 PM UTC+1, David Brown wrote: >> On 18/04/15 13:22, Malcolm McLean wrote: >>> On Saturday, April 18, 2015 at 12:16:32 PM UTC+1, David Brown wrote: >>>> >>>> And for this problem, there is /no/ solution. >>>> >>> You can easily test various strategies, then feed them messages with >>> plausible length distributions, and see how each performs under >>> each hypothesis. >> >> No, you can't do that. Your problem (as posed) is completely >> hypothetical and unrealistic. You can't use trial and error. And even >> if you /did/ use trial and error, you can't claim to have found an >> optimum strategy - at best you could see that one strategy was better >> than another on the test sample used. >> >> Plenty of people (myself included) have given ideas and suggestions for >> efficient and practical ways of dealing with a real-world variation of >> your problem. >> >> Maybe I'll write out a proof of my claim that there is no optimum >> strategy for the problem you posed. (Of course, in trying to do so I >> might find I was wrong!). >> > We know that if we grow the buffer by one byte each time, we'll > get a very poor result. And we know that if we take the maximum > physically possible text message, allocate that, we'll get a poor > result. So there's a strategy in between which is better than > either, and the idea that the problem has no solution at all is > obviously false. > Is this your confusion about minimising and maximising rearing its ugly head again? Finding a worst possible strategy (allocating one byte at a time - since the stated problem has no upper bound on the message size, allocating a single maximal size is not possible) does not imply that there must be a best strategy! > Ben's suggested that the optimal answer is to grow the buffer by a > factor between 1.5 and 3. Does that sound reasonable to you? What > about growing by 1.1 or by 10? > No, Ben did not suggest that this was an "optimal" answer in any way. He said it might be a practical choice to be used in real-life situations with somewhat similar types of problems. But that is a very different thing altogether. You asked for /the/ /optimal/ strategy for the problem as you stated it (with no knowledge of the size of the input - no knowledge of the distribution, and no maximum size, and with very specific cost functions). Since you haven't even said what "optimal" might mean here (we can't talk about "average" cases or costs without a known distribution of the inputs), it is clearly impossible. Since by your own admission you are no mathematician, I would suggest you don't pose half-baked problems and then ask for meaningless answers.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-18 17:47 -0500 |
| Message-ID | <mgumre$ae9$1@dont-email.me> |
| In reply to | #60314 |
On 4/18/2015 8:00 AM, Malcolm McLean wrote: > On Saturday, April 18, 2015 at 1:09:04 PM UTC+1, David Brown wrote: >> On 18/04/15 13:22, Malcolm McLean wrote: >>> On Saturday, April 18, 2015 at 12:16:32 PM UTC+1, David Brown wrote: >>>> >>>> And for this problem, there is /no/ solution. >>>> >>> You can easily test various strategies, then feed them messages with >>> plausible length distributions, and see how each performs under >>> each hypothesis. >> >> No, you can't do that. Your problem (as posed) is completely >> hypothetical and unrealistic. You can't use trial and error. And even >> if you /did/ use trial and error, you can't claim to have found an >> optimum strategy - at best you could see that one strategy was better >> than another on the test sample used. >> >> Plenty of people (myself included) have given ideas and suggestions for >> efficient and practical ways of dealing with a real-world variation of >> your problem. >> >> Maybe I'll write out a proof of my claim that there is no optimum >> strategy for the problem you posed. (Of course, in trying to do so I >> might find I was wrong!). >> > We know that if we grow the buffer by one byte each time, we'll > get a very poor result. And we know that if we take the maximum > physically possible text message, allocate that, we'll get a poor > result. So there's a strategy in between which is better than > either, and the idea that the problem has no solution at all is > obviously false. You don't actually know any of those things. The strategy of growing the buffer one byte each time will be optimal if the input is always one byte. The take the maximum possible will be optimal if the input is always the maximum possible. Ultimately, that's why there's no optimal solution. What's optimal depends on the input distribution and that isn't known. For real world scenarios that are vaguely reminiscent of yours, rather than trying to find optimal solutions, the goal is to find a good enough solution. > Ben's suggested that the optimal answer is to grow the buffer by a > factor between 1.5 and 3. Does that sound reasonable to you? What > about growing by 1.1 or by 10? He said that using a buffer that grows by a factor between 1.5 and 3 was normal, not optimal. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 00:11 -0700 |
| Message-ID | <6afa8b15-6dec-4c68-9ec5-ffdce4b45ff6@googlegroups.com> |
| In reply to | #60355 |
On Saturday, April 18, 2015 at 11:47:16 PM UTC+1, Martin Shobe wrote: > On 4/18/2015 8:00 AM, Malcolm McLean wrote: > > On Saturday, April 18, 2015 at 1:09:04 PM UTC+1, David Brown wrote: > >> On 18/04/15 13:22, Malcolm McLean wrote: > >>> On Saturday, April 18, 2015 at 12:16:32 PM UTC+1, David Brown wrote: > >>>> > >>>> And for this problem, there is /no/ solution. > >>>> > >>> You can easily test various strategies, then feed them messages with > >>> plausible length distributions, and see how each performs under > >>> each hypothesis. > >> > >> No, you can't do that. Your problem (as posed) is completely > >> hypothetical and unrealistic. You can't use trial and error. And even > >> if you /did/ use trial and error, you can't claim to have found an > >> optimum strategy - at best you could see that one strategy was better > >> than another on the test sample used. > >> > >> Plenty of people (myself included) have given ideas and suggestions for > >> efficient and practical ways of dealing with a real-world variation of > >> your problem. > >> > >> Maybe I'll write out a proof of my claim that there is no optimum > >> strategy for the problem you posed. (Of course, in trying to do so I > >> might find I was wrong!). > >> > > We know that if we grow the buffer by one byte each time, we'll > > get a very poor result. And we know that if we take the maximum > > physically possible text message, allocate that, we'll get a poor > > result. So there's a strategy in between which is better than > > either, and the idea that the problem has no solution at all is > > obviously false. > > You don't actually know any of those things. The strategy of growing the > buffer one byte each time will be optimal if the input is always one > byte. The take the maximum possible will be optimal if the input is > always the maximum possible. Ultimately, that's why there's no optimal > solution. What's optimal depends on the input distribution and that > isn't known. > > For real world scenarios that are vaguely reminiscent of yours, rather > than trying to find optimal solutions, the goal is to find a good enough > solution. > You've been told that the input is human-composed English language text messages. That's the crucial bit of information you've haven't taken on board. It also makes a mathematical proof that there is no optimal answer very difficult, because you can't define what we know about human- composed English language messages in a rigorous way, but nor is it sensible to say we know nothing about them. An experimentally devised optimal answer isn't difficult, however, and that might lead you into realising that in fact there's quite a bit we can say about human-composed text messages. For example, will the probability density function be a maximum at infinity, or will it tend to zero at infinity? What about zero?
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-19 12:52 +0000 |
| Message-ID | <5533a3e9.13938359@news.xs4all.nl> |
| In reply to | #60367 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, April 18, 2015 at 11:47:16 PM UTC+1, Martin Shobe wrote: > > You don't actually know any of those things. The strategy of growing the > > buffer one byte each time will be optimal if the input is always one > > byte. The take the maximum possible will be optimal if the input is > > always the maximum possible. Ultimately, that's why there's no optimal > > solution. What's optimal depends on the input distribution and that > > isn't known. > You've been told that the input is human-composed English language text > messages. So now you know that it's likely to lie somewhere between "See Spot run!" and "no thats no way for him has he no manners nor no refinement nor no nithing in his nature slapping us behind like that on my bottom because I didn't call him Hugh the ignoramus that doesn't know poetry from a cabbage thats what you get for not keeping them in their proper place [...9 pages omitted...] and then he asked me would I yes to say yes my mountain flower and first I put my arms around him yes and drew him down to me so he could feel my breasts all perfume yes and his heart was going like mad and yes I said yes I will Yes." Good luck with your optimum. Richard
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-19 09:10 -0500 |
| Message-ID | <mh0cvr$vp5$1@dont-email.me> |
| In reply to | #60367 |
On 4/19/2015 2:11 AM, Malcolm McLean wrote: > On Saturday, April 18, 2015 at 11:47:16 PM UTC+1, Martin Shobe wrote: >> On 4/18/2015 8:00 AM, Malcolm McLean wrote: >>> On Saturday, April 18, 2015 at 1:09:04 PM UTC+1, David Brown wrote: >>>> On 18/04/15 13:22, Malcolm McLean wrote: >>>>> On Saturday, April 18, 2015 at 12:16:32 PM UTC+1, David Brown wrote: >>>>>> >>>>>> And for this problem, there is /no/ solution. >>>>>> >>>>> You can easily test various strategies, then feed them messages with >>>>> plausible length distributions, and see how each performs under >>>>> each hypothesis. >>>> >>>> No, you can't do that. Your problem (as posed) is completely >>>> hypothetical and unrealistic. You can't use trial and error. And even >>>> if you /did/ use trial and error, you can't claim to have found an >>>> optimum strategy - at best you could see that one strategy was better >>>> than another on the test sample used. >>>> >>>> Plenty of people (myself included) have given ideas and suggestions for >>>> efficient and practical ways of dealing with a real-world variation of >>>> your problem. >>>> >>>> Maybe I'll write out a proof of my claim that there is no optimum >>>> strategy for the problem you posed. (Of course, in trying to do so I >>>> might find I was wrong!). >>>> >>> We know that if we grow the buffer by one byte each time, we'll >>> get a very poor result. And we know that if we take the maximum >>> physically possible text message, allocate that, we'll get a poor >>> result. So there's a strategy in between which is better than >>> either, and the idea that the problem has no solution at all is >>> obviously false. >> >> You don't actually know any of those things. The strategy of growing the >> buffer one byte each time will be optimal if the input is always one >> byte. The take the maximum possible will be optimal if the input is >> always the maximum possible. Ultimately, that's why there's no optimal >> solution. What's optimal depends on the input distribution and that >> isn't known. >> >> For real world scenarios that are vaguely reminiscent of yours, rather >> than trying to find optimal solutions, the goal is to find a good enough >> solution. >> > You've been told that the input is human-composed English language text > messages. > That's the crucial bit of information you've haven't taken on board. Not unless by human-composed English language text messages you're also imposing additional unstated assumptions. Such messages can be as short as 1 letter and if our system is small enough they can also be the maximum allowable. > It also makes a mathematical proof that there is no optimal answer > very difficult, because you can't define what we know about human- > composed English language messages in a rigorous way, but nor is > it sensible to say we know nothing about them. Some things we can say about it is that messages in English can be as short as one letter and have no upper bound. > An experimentally devised optimal answer isn't difficult, however, > and that might lead you into realising that in fact there's quite > a bit we can say about human-composed text messages. > For example, will the probability density function be a maximum > at infinity, or will it tend to zero at infinity? What about zero? Since both those points lie outside the domain of English language message lengths that should be obvious. But it's now quite clear that you are again playing the game where you give us only some of the information and then dribble out bits and pieces of additional information when others show that the answer you want doesn't follow from the original. From the above, it's quite clear that instead of all we know is that they are human-composed messages in the English language, you have a particular distribution in mind. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 07:21 -0700 |
| Message-ID | <5e0cb6c7-bafc-4145-8b29-5929a8b57033@googlegroups.com> |
| In reply to | #60401 |
On Sunday, April 19, 2015 at 3:11:10 PM UTC+1, Martin Shobe wrote: > On 4/19/2015 2:11 AM, Malcolm McLean wrote: > > Some things we can say about it is that messages in English can be as > short as one letter and have no upper bound. > Human-composed messages in English? Imagine someone learned to write at age five, lived to be 120 (like the sage Hillel) and wrote constantly for six days a week from dawn until bedtime. Now what's the a priority probability of that being the message? > > > An experimentally devised optimal answer isn't difficult, however, > > and that might lead you into realising that in fact there's quite > > a bit we can say about human-composed text messages. > > For example, will the probability density function be a maximum > > at infinity, or will it tend to zero at infinity? What about zero? > > Since both those points lie outside the domain of English language > message lengths that should be obvious. But it's now quite clear that > you are again playing the game where you give us only some of the > information and then dribble out bits and pieces of additional > information when others show that the answer you want doesn't follow > from the original. From the above, it's quite clear that instead of all > we know is that they are human-composed messages in the English > language, you have a particular distribution in mind. > All you know is that the messages are human-composed messages in the English language. It's a highly stratified population (all text written in English by all people anywhere) and you're taking one sub-sample from it. But the sample does represent an underlying process of writing. So the length distribution can't be Cantor dust or some other mathematically pathological function. It's got to arise from an underlying physical process of human writing.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-19 12:54 -0500 |
| Message-ID | <mh0q2s$i35$1@dont-email.me> |
| In reply to | #60404 |
On 4/19/2015 9:21 AM, Malcolm McLean wrote: > On Sunday, April 19, 2015 at 3:11:10 PM UTC+1, Martin Shobe wrote: >> On 4/19/2015 2:11 AM, Malcolm McLean wrote: >> Some things we can say about it is that messages in English can be as >> short as one letter and have no upper bound. > Human-composed messages in English? > Imagine someone learned to write at age five, lived to be 120 (like > the sage Hillel) and wrote constantly for six days a week from dawn > until bedtime. > Now what's the a priority probability of that being the message? A priori probabilities are usually uniform distributions over a finite space. The only finite space I can see that makes sense here is the space of messages actually composed. I don't know how large that is, but the probability you asked for will be very close to zero. However, if the process of getting the human composed messages to our program filters out all messages that aren't composed by someone who learned to write at age five, lived to be 120, and wrote constantly for six days a week from dawn until bedtime. The chances of seeing such a message in our input would be 100%. (As long as there was at least one such person). >>> An experimentally devised optimal answer isn't difficult, however, >>> and that might lead you into realising that in fact there's quite >>> a bit we can say about human-composed text messages. >>> For example, will the probability density function be a maximum >>> at infinity, or will it tend to zero at infinity? What about zero? >> Since both those points lie outside the domain of English language >> message lengths that should be obvious. But it's now quite clear that >> you are again playing the game where you give us only some of the >> information and then dribble out bits and pieces of additional >> information when others show that the answer you want doesn't follow >> from the original. From the above, it's quite clear that instead of all >> we know is that they are human-composed messages in the English >> language, you have a particular distribution in mind. > All you know is that the messages are human-composed messages in > the English language. It's a highly stratified population (all > text written in English by all people anywhere) and you're taking > one sub-sample from it. But the sample does represent an underlying > process of writing. > So the length distribution can't be Cantor dust or some other > mathematically pathological function. It's got to arise from an > underlying physical process of human writing. Dribble. Dribble. We're now one step closer to knowing what the distribution you had in mind was. And no, you can't conclude that the length distribution isn't pathological in some sense from the information given. The two "pathological" distributions I mentioned above are still possible. You haven't stated your restrictions on how the sub-sampling is done (yet). Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 11:18 -0700 |
| Message-ID | <2f761b0b-5f06-4902-955a-440871341812@googlegroups.com> |
| In reply to | #60444 |
On Sunday, April 19, 2015 at 6:54:39 PM UTC+1, Martin Shobe wrote: > On 4/19/2015 9:21 AM, Malcolm McLean wrote: > > A priori probabilities are usually uniform distributions over a finite > space. The only finite space I can see that makes sense here is the > space of messages actually composed. > Right. Now we've got a solid claim. That's one possibility. The only difficulty is you can't establish the total amount of human-composed text in existence. > > And no, you can't conclude that the length distribution isn't > pathological in some sense from the information given. The two > "pathological" distributions I mentioned above are still possible. You > haven't stated your restrictions on how the sub-sampling is done (yet). > So we can say that an enemy, determined to sabotage our system, might concatenate all the text in the world together and send it as one message, or he might chop it up into one letter chunks and send those as messages. We can nit pick about whether that really fulfils the criteria of "human composed messages", but we mustn't crash if that happens (other than the unavoidable situation of the computer running out of memory).
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-20 09:58 -0500 |
| Message-ID | <mh344r$74b$1@dont-email.me> |
| In reply to | #60447 |
On 4/19/2015 1:18 PM, Malcolm McLean wrote: > On Sunday, April 19, 2015 at 6:54:39 PM UTC+1, Martin Shobe wrote: >> On 4/19/2015 9:21 AM, Malcolm McLean wrote: >> >> A priori probabilities are usually uniform distributions over a finite >> space. The only finite space I can see that makes sense here is the >> space of messages actually composed. >> > Right. Now we've got a solid claim. > That's one possibility. The only difficulty is you can't establish the > total amount of human-composed text in existence. What other possibilities are you envisioning? >> And no, you can't conclude that the length distribution isn't >> pathological in some sense from the information given. The two >> "pathological" distributions I mentioned above are still possible. You >> haven't stated your restrictions on how the sub-sampling is done (yet). > So we can say that an enemy, determined to sabotage our system, might > concatenate all the text in the world together and send it as one > message, or he might chop it up into one letter chunks and send those > as messages. We can nit pick about whether that really fulfils > the criteria of "human composed messages", but we mustn't crash if > that happens (other than the unavoidable situation of the computer > running out of memory). Doesn't have to be an enemy, but there does have to be some process that is doing the selection from the space of all human-composed text messages and feeding the selected messages to our program. Without restrictions on what that process does, the pathological distributions still can't be ruled out. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 08:09 -0700 |
| Message-ID | <0df3d1f4-087a-4386-b877-baf4dcfca9e9@googlegroups.com> |
| In reply to | #60530 |
On Monday, April 20, 2015 at 3:58:40 PM UTC+1, Martin Shobe wrote: > > Doesn't have to be an enemy, but there does have to be some process that > is doing the selection from the space of all human-composed text > messages and feeding the selected messages to our program. Without > restrictions on what that process does, the pathological distributions > still can't be ruled out. > Exactly. But the restriction is that it has to be some process drawn from the real world, we're not allowed to set up a computer to generate artificial data. We've got to be able to claim that these are "real messages". So if we have an enemy, he can get his hands on all the human-generated English language text in the world. He can then chop them up into messages of one byte each, and send those, and we can have an argument about whether he has cheated. or he can concatenate them together and send the whole lot in one chunk, and we can also argue that he has cheated. So those are two limiting cases. Words are fuzzy. But it doesn't mean they are meaningless.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-20 13:06 -0500 |
| Message-ID | <mh3f58$kts$1@dont-email.me> |
| In reply to | #60531 |
On 4/20/2015 10:09 AM, Malcolm McLean wrote: > On Monday, April 20, 2015 at 3:58:40 PM UTC+1, Martin Shobe wrote: >> Doesn't have to be an enemy, but there does have to be some process that >> is doing the selection from the space of all human-composed text >> messages and feeding the selected messages to our program. Without >> restrictions on what that process does, the pathological distributions >> still can't be ruled out. >> > Exactly. > But the restriction is that it has to be some process drawn from the real world, > we're not allowed to set up a computer to generate artificial data. We've > got to be able to claim that these are "real messages". They would be. > So if we have an enemy, he can get his hands on all the human-generated English > language text in the world. He can then chop them up into messages of one byte > each, and send those, and we can have an argument about whether he has cheated. > or he can concatenate them together and send the whole lot in one chunk, and > we can also argue that he has cheated. > So those are two limiting cases. I wasn't considering stuff like that. However, the sampling process might be one that only selects one character messages or it might be one that only selects very large messages. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-19 07:32 -0700 |
| Message-ID | <87pp70p4t6.fsf@kst-u.example.com> |
| In reply to | #60367 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> You've been told that the input is human-composed English language text
> messages.
> That's the crucial bit of information you've haven't taken on board.
> It also makes a mathematical proof that there is no optimal answer
> very difficult, because you can't define what we know about human-
> composed English language messages in a rigorous way, but nor is
> it sensible to say we know nothing about them.
>
> An experimentally devised optimal answer isn't difficult, however,
> and that might lead you into realising that in fact there's quite
> a bit we can say about human-composed text messages.
> For example, will the probability density function be a maximum
> at infinity, or will it tend to zero at infinity? What about zero?
An experimentally devised optimal answer is impossible, because
constructing an experiment based on your stated requirements is
impossible unless we add more requirements that you haven't stated.
Given any allegedly optimal solution, I can construct an experiment
consistent with your requiremnts that breaks it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 09:03 -0700 |
| Message-ID | <50a6a05c-e4d4-4601-b469-0a60e546ca16@googlegroups.com> |
| In reply to | #60409 |
On Sunday, April 19, 2015 at 3:32:12 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [ > An experimentally devised optimal answer is impossible, because > constructing an experiment based on your stated requirements is > impossible unless we add more requirements that you haven't stated. > > Given any allegedly optimal solution, I can construct an experiment > consistent with your requiremnts that breaks it. > No it's not. The input is "human-composed text messages". So we know a few things. For example, a message can't be zero letters, or it isn't a message at all. And it cant be longer than any human process could possibly produce - we know it's not being spat out by a computer somewhere. Can it be one letter? There are two one letter words in the English language, "I" and "a". So what do you think is the probability that a "human generated messages" will consist of a large number of one letter messages, all either "I" or "a"? Think of the meaning conveyed by these two messages, compared with the set of all things people might want to say. What about two letters? But text messages are highly stratified. That is to say, if you select messages on one basis, such as "articles in magazines", they're going to be very different to messages selected on another basis, such as "tweets", or "letters to the Times". But we know that our messages are going to be some subset of all human-composed English-language messages. We've got that information. So we can conduct an experiment, which is to select sets of messages on some basis or other, then see how strategies perform. We're taking a sample of samples, if you like - a sample of statistical distributions, but not in some metaphysical sense, but based on a real dataset. You can also construct a non-optimal input. You can argue that that's something we need to consider - the malicious worst case scenario. By definition, we'll perform worse on this than for any other input, but if we're not catastrophically bad, then that's better than a strategy that fails castrophically.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-19 16:30 +0100 |
| Message-ID | <874moc87aa.fsf@bsb.me.uk> |
| In reply to | #60367 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > An experimentally devised optimal answer isn't difficult, It might be harder than you think since you need some bounds for the two parameters and they might be hard to estimate in an experimental situation. But sure, for every input set there will be an initial size and multiplier that minimises your cost function. Why do you think these numbers will be interesting? There is every chance (from not much thinking I'll admit) that the results will be "all over the place" and will simply reflect the input set you choose to use. That's very far from what seemed to be you original suggestion that there might be an optimal strategy in general. And are you still prepared to say that a formula that minimises the number of calls will be optimal for your cost model? It is in some rather contrived cases, but do you really think it will be so in any realistic experimental situation? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-19 12:58 +0100 |
| Message-ID | <mh056t$446$1@dont-email.me> |
| In reply to | #60314 |
On 18/04/2015 14:00, Malcolm McLean wrote: > We know that if we grow the buffer by one byte each time, we'll > get a very poor result. Not necessarily. Maybe the buffer only needs to grow to 20 bytes. Maybe the cost of growing it by one byte is almost zero. Maybe the enlarged buffer can be reused for subsequent operations, so the cost is one-time. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 05:37 -0700 |
| Message-ID | <0b1ce986-5641-48d0-9309-20829d7aad02@googlegroups.com> |
| In reply to | #60392 |
On Sunday, April 19, 2015 at 12:58:25 PM UTC+1, Bart wrote: > On 18/04/2015 14:00, Malcolm McLean wrote: > > We know that if we grow the buffer by one byte each time, we'll > > get a very poor result. > > Not necessarily. Maybe the buffer only needs to grow to 20 bytes. Maybe > the cost of growing it by one byte is almost zero. Maybe the enlarged > buffer can be reused for subsequent operations, so the cost is one-time. > That's why I gave a cost function. There's the cost of taking a probe (the cost of call to malloc/realloc) and the cost of taking a chunk (the "fine" for asking for more memory than you need). If we set either to zero we can solve the problem trivially either by growing the buffer by one byte or demanding all the memory in the machine. So I said, arbitrarily, that the cost is the sum of the total amounts asked for in malloc() / realloc(). That's not too unrealistic if you're operating in a high- security environment where you need to zero out memory before getting it.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-18 08:00 -0500 |
| Message-ID | <mgtkg9$vbp$1@dont-email.me> |
| In reply to | #60305 |
On 4/18/2015 6:22 AM, Malcolm McLean wrote: > On Saturday, April 18, 2015 at 12:16:32 PM UTC+1, David Brown wrote: >> >> And for this problem, there is /no/ solution. >> > You can easily test various strategies, then feed them messages with > plausible length distributions, and see how each performs under > each hypothesis. No you can't. The best that that will give you is the best of the strategies you tried for the actual distributions you gave them. > However you can't really say which of the plausible distributions > is going to be most likely. I'm not quite sure what a "statistical > distribution of statistical distributions" really means in statistical > theory. It means a statistical distribution. What I mean here is if you describe something as a statistical distributions of statistical distributions what that something is is a statistical distribution. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-18 19:28 +0100 |
| Message-ID | <877ft9azpt.fsf@bsb.me.uk> |
| In reply to | #60304 |
David Brown <david.brown@hesbynett.no> writes: > On 17/04/15 21:52, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Friday, April 17, 2015 at 4:04:41 PM UTC+1, Martin Shobe wrote: >>>> On 4/17/2015 6:37 AM, Malcolm McLean wrote: >>>> >>>> There is nothing superior in terms of the metric you've chosen. This >>>> method mallocs exactly the amount needed for each input. Malloc any >>>> less, and you don't have enough for that input. >>>> >>> Ok, so that the best attempt from Martin Shobe. >> >> Martin Shobe did provide a solution. He commented on the fact that >> you Sigh! I just noticed the worst of typos: a missing "not": "Martin did *not* provide a solution -- he commented on the fact that you..." >> appear to have misunderstood the code posted by Morris Dovey. >> >> Morris's code is not a solution to the problem you posed -- it's a way >> to avoid the problem altogether by using the stack instead. Your >> problem (as posed) seemed to be to find the optimal multiplier for >> growing an input buffer. > > And for this problem, there is /no/ solution. Quite. I think you made this point to me before and I forgot to answer at the tome and didn't mark the message. Sorry. I think Malcolm is trying to avoid this fact by talking vaguely about input distributions. For some trivial distributions of inputs there is an optimal solution, but that's not really interesting. (The obvious trivial one being a single, known, input size.) -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web