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 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-19 23:22 +0200 |
| Message-ID | <mh1697$49g$1@dont-email.me> |
| In reply to | #60405 |
On 19/04/15 16:25, Malcolm McLean wrote: > On Sunday, April 19, 2015 at 1:58:38 PM UTC+1, Richard Bos wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >> >>> On Saturday, April 18, 2015 at 10:33:43 PM UTC+1, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> >>>>> (Of course maybe getting a value which will perform well given >>>>> the information I've given you may be non-trivial, but in that case >>>>> the problem is interesting. If all values perform as well as each other, >>>>> you don't have that issue, just pick random numbers and you're done). >>>> >>>> What information have you given me? >>>> >>> You've been tasked with writing a program, to reduce the total >>> amount of allocation in a growing buffer, and the input is human >>> composed English-language messages. >> >> You don't pay us enough to write programs on such unbelievably vague >> specifications. "Human composed English-language messages"... _which_ >> human!? Messages of what kind? Who for? >> >>> I don't mind being told I'm wrong if someone else has the right >>> answer. Naturally I object when no-one else can rise to the >>> challenge. >> >> *Sigh* You've not been told that there is an answer and your is not it; >> you've been told, several times now, that there _is no general answer_ >> despite your insistence that there must be. >> > In your view there's no general answer. > So if I grow the buffer by 1 + epsilon, where epsilon is the lowest > number representable on my computer such that 1 * (1+epsilon) is > different to unity, and. to be fair, we ignore any duplicate integers, > I've got an answer that is as good as any other. Agreed? That's your > best shot at the problem. > You've been told this before, but I'll try again. The fact that you can think of different strategies, and show that for some particular choice of inputs one is better than another, does /not/ show there is an optimal solution! Since you are apparently unfamiliar with the English language, mathematics, cooking, and programming, lets pick an analogous problem in a different domain - shopping. For this problem, you have a human doing some shopping. All the shopping has to go into plastic bags that you buy - and every time you buy new bags, you have to move everything out of the old bags and put them in new ones. The cost function is the total cost of all the bags. What is the best way to do the shopping? Clearly if one is buying marbles, buying a new bag for every marble is a poor strategy compared to buying your marbles and bags in a Fibonacci sequence. Invoking Malcolm logic, this proves that an optimum solution exists, and can be found by trial and error. The problem you have given is no more possible, no more realistic, and no more practical than this shopping one.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-19 16:26 -0700 |
| Message-ID | <0734af4b-4b6e-44b5-9f8f-9fba8315e833@googlegroups.com> |
| In reply to | #60463 |
On Sunday, April 19, 2015 at 10:22:51 PM UTC+1, David Brown wrote: > > Since you are apparently unfamiliar with the English language, > mathematics, cooking, and programming, lets pick an analogous problem in > a different domain - shopping. > > For this problem, you have a human doing some shopping. All the > shopping has to go into plastic bags that you buy - and every time you > buy new bags, you have to move everything out of the old bags and put > them in new ones. The cost function is the total cost of all the bags. > What is the best way to do the shopping? > > Clearly if one is buying marbles, buying a new bag for every marble is a > poor strategy compared to buying your marbles and bags in a Fibonacci > sequence. Invoking Malcolm logic, this proves that an optimum solution > exists, and can be found by trial and error. > > > The problem you have given is no more possible, no more realistic, and > no more practical than this shopping one. > Let's see, shall we. Let's first work on the enemy hypothesis. I've been accused of planning to tailor the distribution so that every algorithm is sub- optimal, except mine. So, suppose I'm your enemy. I have access to your source code. You also know that I've got N bytes of human composed text. You don't know how much, but you do know that there is some limit, because there's a limit to the amount of human-composed English text in existence, and by the rules, I'm not allowed to spit fake messages at you generated by a computer. What am I going to do? How will I distribute my N letters of text to maximise the cost to you? Now are you helpless, or is there a strategy you can use to protect yourself?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-20 00:48 +0100 |
| Message-ID | <mh1er8$ka$1@dont-email.me> |
| In reply to | #60480 |
On 20/04/15 00:26, Malcolm McLean wrote: <snip> > So, suppose I'm your enemy. I have access to your source code. > You also know that I've got N bytes of human composed text. You don't > know how much, but you do know that there is some limit, because > there's a limit to the amount of human-composed English text in > existence, and by the rules, I'm not allowed to spit fake messages > at you generated by a computer. > What am I going to do? How will I distribute my N letters of > text to maximise the cost to you? > > Now are you helpless, or is there a strategy you can use to protect > yourself? The most effective strategy would be to add you to a spam filter. (Purely for the purposes of the exercise, obviously.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-20 09:15 +0200 |
| Message-ID | <mh291a$b2$1@dont-email.me> |
| In reply to | #60480 |
On 20/04/15 01:26, Malcolm McLean wrote: > On Sunday, April 19, 2015 at 10:22:51 PM UTC+1, David Brown wrote: >> >> Since you are apparently unfamiliar with the English language, >> mathematics, cooking, and programming, lets pick an analogous problem in >> a different domain - shopping. >> >> For this problem, you have a human doing some shopping. All the >> shopping has to go into plastic bags that you buy - and every time you >> buy new bags, you have to move everything out of the old bags and put >> them in new ones. The cost function is the total cost of all the bags. >> What is the best way to do the shopping? >> >> Clearly if one is buying marbles, buying a new bag for every marble is a >> poor strategy compared to buying your marbles and bags in a Fibonacci >> sequence. Invoking Malcolm logic, this proves that an optimum solution >> exists, and can be found by trial and error. >> >> >> The problem you have given is no more possible, no more realistic, and >> no more practical than this shopping one. >> > Let's see, shall we. > > Let's first work on the enemy hypothesis. I've been accused of > planning to tailor the distribution so that every algorithm is sub- > optimal, except mine. Who accused you of that? At most you've given vague random ideas about distributions, but mostly you have used lots of words to say nothing at all. To the extent that it makes sense to discuss an optimal algorithm when there is no overall cost function to optimise (and there cannot be such a cost function when the distribution is unknown but the cost of the function depends on the size of the input), we already know there is no optimal algorithm except in your imagination. > So, suppose I'm your enemy. I have access to your source code. > You also know that I've got N bytes of human composed text. You don't > know how much, but you do know that there is some limit, because > there's a limit to the amount of human-composed English text in > existence, and by the rules, I'm not allowed to spit fake messages > at you generated by a computer. There is no limit to the size of such an input in the problem you have given. All you have tried to do is give a bunch of increasingly detailed rules (it has to be in English, people can write at most x words per minute, it must be written by humans, etc.), none of which leads to any sort of meaningful figure - and certainly not any realistic figure. Your only two sane choices here are to say there is no upper bound on the size, or to pick a size N and say that is the size of the input. Then you can dispense with most of the waffle about English text. > What am I going to do? How will I distribute my N letters of > text to maximise the cost to you? > And what would this tell us? It does not give any information towards an optimal strategy. > Now are you helpless, or is there a strategy you can use to protect > yourself? > I am strongly tempted to apply the Heathfield algorithm...
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 00:39 -0700 |
| Message-ID | <bb060ce1-d2c3-4479-9297-78234efe5489@googlegroups.com> |
| In reply to | #60490 |
On Monday, April 20, 2015 at 8:16:00 AM UTC+1, David Brown wrote: > On 20/04/15 01:26, Malcolm McLean wrote: > > > Let's first work on the enemy hypothesis. I've been accused of > > planning to tailor the distribution so that every algorithm is sub- > > optimal, except mine. > > Who accused you of that? At most you've given vague random ideas about > distributions, but mostly you have used lots of words to say nothing > at all. > > To the extent that it makes sense to discuss an optimal algorithm when > there is no overall cost function to optimise (and there cannot be such > a cost function when the distribution is unknown but the cost of the > function depends on the size of the input), we already know there is no > optimal algorithm except in your imagination. > OK, I Malcolm have been accused of setting a challenge without telling you the distribution. The other people will submit answers. I'll then invent the distribution that causes their algorithm to have worst case performance, and laugh in triumph. Ok, so that's our working hypothesis. We have an enemy. Now if he could send us infinite bytes there would be no point - he can impose infinite costs on us. So there must be some upper limit to the amount of ammunition he can get his hands on. And we've said that the messages are human-composed English language text. So whether he's a lone wolf tapping away, he employs a bank of people, or he's downloaded all English-language texts from the internet, there's a limit. So if we grow a buffer, then he can send of messages of one or two bytes (depending on whether we allocate the one) and he imposes a cost of N * growth factor on us. But he won't do that, he'll send us the largest message he can, that is exactly one byte over the maximum we can allocate. So we see that we always waste N * (1 - growth factor) -1 bytes, where N is the size of his attack. But we can't respond by making the growth factor tiny, because we've also got to sum the intermediate allocations we have made. So let's assume for the moment that we've restricted him to one attack. We can write an equation for our optimal strategy, given various values of N, agreed? Then we'll open it out, and see if we can go any further. Can we work out an optimal strategy, given that we don't know N?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-20 10:33 +0200 |
| Message-ID | <mh2dir$f3r$2@dont-email.me> |
| In reply to | #60491 |
On 20/04/15 09:39, Malcolm McLean wrote: > On Monday, April 20, 2015 at 8:16:00 AM UTC+1, David Brown wrote: >> On 20/04/15 01:26, Malcolm McLean wrote: >> >>> Let's first work on the enemy hypothesis. I've been accused of >>> planning to tailor the distribution so that every algorithm is sub- >>> optimal, except mine. >> >> Who accused you of that? At most you've given vague random ideas about >> distributions, but mostly you have used lots of words to say nothing >> at all. >> >> To the extent that it makes sense to discuss an optimal algorithm when >> there is no overall cost function to optimise (and there cannot be such >> a cost function when the distribution is unknown but the cost of the >> function depends on the size of the input), we already know there is no >> optimal algorithm except in your imagination. >> > OK, I Malcolm have been accused of setting a challenge without telling > you the distribution. The other people will submit answers. I'll then > invent the distribution that causes their algorithm to have worst > case performance, and laugh in triumph. > > Ok, so that's our working hypothesis. We have an enemy. Now if he > could send us infinite bytes there would be no point - he can impose > infinite costs on us. So there must be some upper limit to the > amount of ammunition he can get his hands on. And we've said that > the messages are human-composed English language text. So whether he's > a lone wolf tapping away, he employs a bank of people, or he's > downloaded all English-language texts from the internet, there's a > limit. > So if we grow a buffer, then he can send of messages of one or two > bytes (depending on whether we allocate the one) and he imposes a > cost of N * growth factor on us. But he won't do that, he'll > send us the largest message he can, that is exactly one byte over > the maximum we can allocate. So we see that we always waste > N * (1 - growth factor) -1 bytes, where N is the size of his > attack. But we can't respond by making the growth factor tiny, > because we've also got to sum the intermediate allocations we > have made. > > So let's assume for the moment that we've restricted him to one > attack. We can write an equation for our optimal strategy, given > various values of N, agreed? No, we can't. > > Then we'll open it out, and see if we can go any further. Can we > work out an optimal strategy, given that we don't know N? > No, we can't.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 01:55 -0700 |
| Message-ID | <4d8c6c38-caa6-43d3-bc65-a6fb84cdef73@googlegroups.com> |
| In reply to | #60496 |
On Monday, April 20, 2015 at 9:33:34 AM UTC+1, David Brown wrote: > On 20/04/15 09:39, Malcolm McLean wrote: > > > So let's assume for the moment that we've restricted him to one > > attack. We can write an equation for our optimal strategy, given > > various values of N, agreed? > > No, we can't. > You maybe can't. Anyone else with a bit of competence at C can. Enemy has N bytes at his disposal. Our strategy is to start at 1 then grow a buffer by a constant. His strategy is to send us the largest number of bytes he can, which is one greater than our last allocation. Our cost is the total number of allocations we make. You can write that function. > > > > Then we'll open it out, and see if we can go any further. Can we > > work out an optimal strategy, given that we don't know N? > > > > No, we can't. > No so hasty. We'll go there later.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-20 11:28 +0200 |
| Message-ID | <mh2gp7$ruu$1@dont-email.me> |
| In reply to | #60499 |
On 20/04/15 10:55, Malcolm McLean wrote: > On Monday, April 20, 2015 at 9:33:34 AM UTC+1, David Brown wrote: >> On 20/04/15 09:39, Malcolm McLean wrote: >> >>> So let's assume for the moment that we've restricted him to one >>> attack. We can write an equation for our optimal strategy, given >>> various values of N, agreed? >> >> No, we can't. >> > You maybe can't. > > Anyone else with a bit of competence at C can. > Enemy has N bytes at his disposal. Our strategy is to start at 1 then grow > a buffer by a constant. His strategy is to send us the largest number of > bytes he can, which is one greater than our last allocation. > > Our cost is the total number of allocations we make. > > You can write that function. I certainly /could/ write that function. But by what series of delusional Malcolm-logic steps do you conclude that this strategy is "optimal" ? Do you even know that the word "optimal" /means/ ? And by that, I mean the word "optimal" as used by everyone else - not one of these private little humpty-dumpty "words mean what I want them to mean" definitions that you are so fond of? > >>> >>> Then we'll open it out, and see if we can go any further. Can we >>> work out an optimal strategy, given that we don't know N? >>> >> >> No, we can't. >> > No so hasty. We'll go there later. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 02:39 -0700 |
| Message-ID | <920ac546-ea78-464f-bc36-6e1d5709b48c@googlegroups.com> |
| In reply to | #60501 |
On Monday, April 20, 2015 at 10:28:16 AM UTC+1, David Brown wrote: > On 20/04/15 10:55, Malcolm McLean wrote: > > On Monday, April 20, 2015 at 9:33:34 AM UTC+1, David Brown wrote: > >> On 20/04/15 09:39, Malcolm McLean wrote: > >> > >>> So let's assume for the moment that we've restricted him to one > >>> attack. We can write an equation for our optimal strategy, given > >>> various values of N, agreed? > >> > >> No, we can't. > >> > > You maybe can't. > > > > Anyone else with a bit of competence at C can. > > Enemy has N bytes at his disposal. Our strategy is to start at 1 then grow > > a buffer by a constant. His strategy is to send us the largest number of > > bytes he can, which is one greater than our last allocation. > > > > Our cost is the total number of allocations we make. > > > > You can write that function. > > I certainly /could/ write that function. But by what series of > delusional Malcolm-logic steps do you conclude that this strategy is > "optimal" ? > > Do you even know that the word "optimal" /means/ ? And by that, I mean > the word "optimal" as used by everyone else - not one of these private > little humpty-dumpty "words mean what I want them to mean" definitions > that you are so fond of? > Put up. Don't snipe. Solve the problem, show that there isn't a solution, or make a good faith best attempt to solve the problem.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-20 12:35 +0200 |
| Message-ID | <mh2kmu$bfr$1@dont-email.me> |
| In reply to | #60502 |
On 20/04/15 11:39, Malcolm McLean wrote: > On Monday, April 20, 2015 at 10:28:16 AM UTC+1, David Brown wrote: >> On 20/04/15 10:55, Malcolm McLean wrote: >>> On Monday, April 20, 2015 at 9:33:34 AM UTC+1, David Brown wrote: >>>> On 20/04/15 09:39, Malcolm McLean wrote: >>>> >>>>> So let's assume for the moment that we've restricted him to one >>>>> attack. We can write an equation for our optimal strategy, given >>>>> various values of N, agreed? >>>> >>>> No, we can't. >>>> >>> You maybe can't. >>> >>> Anyone else with a bit of competence at C can. >>> Enemy has N bytes at his disposal. Our strategy is to start at 1 then grow >>> a buffer by a constant. His strategy is to send us the largest number of >>> bytes he can, which is one greater than our last allocation. >>> >>> Our cost is the total number of allocations we make. >>> >>> You can write that function. >> >> I certainly /could/ write that function. But by what series of >> delusional Malcolm-logic steps do you conclude that this strategy is >> "optimal" ? >> >> Do you even know that the word "optimal" /means/ ? And by that, I mean >> the word "optimal" as used by everyone else - not one of these private >> little humpty-dumpty "words mean what I want them to mean" definitions >> that you are so fond of? >> > > Put up. Don't snipe. > > Solve the problem, show that there isn't a solution, or make a good faith best > attempt to solve the problem. > State the problem in a way that actually makes sense. Define the sizes - don't wibble and waffle about English texts. Define the distributions. Define the requirements and the restrictions for the algorithms. And define what you mean by "optimal". I'll give you some clues here. "Optimal" might mean that the average cost is lowest - this is heavily dependent on the distribution. It might mean that the worst-case cost is lowest - which is totally dependent on the maximum size. It might mean using weighted costs (where short strings get heavier weights), either for lowest worst-case or for best average cost. (And average could mean "mean" or "median".) That's just some ideas for what "optimal" could mean here - but you haven't even hinted at what you want (despite me asking many times). Nor have you given appropriate details and limits in the problem in order for most of these options for "optimal" to make sense - and to the extent that they do make sense, it is immediately obvious that there is no optimal strategy. I outlined a proof earlier - feel free to make it rigorous if you like. Of course, even if you /do/ give us a problem that makes sense and can be answered, that does not mean that I /will/ answer it. I might have done had it come earlier, but it has been such a time-consuming ordeal trying to correct and explain your fundamental misunderstandings about maths, English language, problems, and algorithms, that I am unlikely to bother. If you want to be treated seriously here, you need to start reading other people's posts (like mine, for example), and understanding what we are saying and why you have been wrong in almost every single thing you have said in this thread. And you need to start admitting that, so that you can start learning something here.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 03:58 -0700 |
| Message-ID | <4f95b162-56fd-4c34-b53a-eed666193d39@googlegroups.com> |
| In reply to | #60505 |
On Monday, April 20, 2015 at 11:35:14 AM UTC+1, David Brown wrote: > On 20/04/15 11:39, Malcolm McLean wrote: > > State the problem in a way that actually makes sense. Define the sizes > - don't wibble and waffle about English texts. Define the > distributions. Define the requirements and the restrictions for the > algorithms. And define what you mean by "optimal". > The whole point is that you can't "define the distributions". All you've got is a real world requirement concerning real world data. It's a specific as it can be - we know the population from which our sample is drawn, but we also know that the population is highly stratified, and we can't hope to take an unbiased sample. However we define our sampling strategy, there will be some bias. > > I'll give you some clues here. "Optimal" might mean that the average > cost is lowest - this is heavily dependent on the distribution. It > might mean that the worst-case cost is lowest - which is totally > dependent on the maximum size. It might mean using weighted costs > (where short strings get heavier weights), either for lowest worst-case > or for best average cost. (And average could mean "mean" or "median".) > You've got a cost function. > > That's just some ideas for what "optimal" could mean here - but you > haven't even hinted at what you want (despite me asking many times). > Nor have you given appropriate details and limits in the problem in > order for most of these options for "optimal" to make sense - and to the > extent that they do make sense, it is immediately obvious that there is > no optimal strategy. I outlined a proof earlier - feel free to make it > rigorous if you like. > Let's run with the worst case scenario, the enemy with N bytes of text to throw at us, which he distributes as he pleases, knowing our algorithm. That'll give you some handle on how to at least approach the problem. > > Of course, even if you /do/ give us a problem that makes sense and can > be answered, that does not mean that I /will/ answer it. I might have > done had it come earlier, but it has been such a time-consuming ordeal > trying to correct and explain your fundamental misunderstandings about > maths, English language, problems, and algorithms, that I am unlikely to > bother. > > If you want to be treated seriously here, you need to start reading > other people's posts (like mine, for example), and understanding what we > are saying and why you have been wrong in almost every single thing you > have said in this thread. And you need to start admitting that, so that > you can start learning something here. > You're desire seems to be to get Malcolm to admit that he is wrong. But the challenge is there. I'm not hearing anything convincing. Let's start with the enemy hypothesis. The messages are being sent by an enemy. Our enemy has N bytes at his disposal. He might have infinite bytes, but then he can impose an infinite cost on us, and there's nothing we can do. Another bit of information is that the messages have to be human-composed English language messages. Ok, you can't cope with that information yet, you don't understand how to incorporate it. Or you do understand and you're teasing me. One of the two. So forget it for the time being. Let's assume that our strategy is to start by 1, and increment the amount by a coefficient each time. Unless you can propose a better strategy, that is. On that model, can we write function that returns a cost, given a growth coefficient and an enemy attack of N bytes?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-20 13:37 +0200 |
| Message-ID | <mh2ocr$pil$1@dont-email.me> |
| In reply to | #60507 |
On 20/04/15 12:58, Malcolm McLean wrote: > On Monday, April 20, 2015 at 11:35:14 AM UTC+1, David Brown wrote: >> On 20/04/15 11:39, Malcolm McLean wrote: >> >> State the problem in a way that actually makes sense. Define the sizes >> - don't wibble and waffle about English texts. Define the >> distributions. Define the requirements and the restrictions for the >> algorithms. And define what you mean by "optimal". >> > The whole point is that you can't "define the distributions". All you've got is > a real world requirement concerning real world data. It's a specific as it > can be - we know the population from which our sample is drawn, but we > also know that the population is highly stratified, and we can't hope to take > an unbiased sample. However we define our sampling strategy, there will > be some bias. >> >> I'll give you some clues here. "Optimal" might mean that the average >> cost is lowest - this is heavily dependent on the distribution. It >> might mean that the worst-case cost is lowest - which is totally >> dependent on the maximum size. It might mean using weighted costs >> (where short strings get heavier weights), either for lowest worst-case >> or for best average cost. (And average could mean "mean" or "median".) >> > You've got a cost function. How small a teaspoon do I need to use here? You made a cost function for a single run - basically the sum of all allocations and re-allocations. That's fine, everyone understood it after you wrote it down (which was a few posts after you gave the original problem). If we are to make an optimal strategy or algorithm, we need a cost function that covers /all/ runs. Not just /one/ run - /all/ runs. Let's try and explain it in a simple example - sorting a sequence of size 8. If the given sequence is "a, b, c, e, d, f, g, h", then the optimum strategy is to swap elements 3 and 4 (numbering from 0 - this is a C newsgroup!). You can't beat that algorithm - it is optimal. But is that much use to anyone? No, because it is optimal for a single case. To be useful, we need a /global/ cost function, such as the average number of swaps needed for all 8! permutations of inputs. We can try to find an optimal algorithm for this global cost function, and end up with something like quicksort. Alternatively, we might use the worst-case number of swaps for all 8! permutations, in which case quicksort comes out badly and mergesort or insertionsort are better choices. Maybe we know something about the distribution, rather than assuming it is random (i.e., considering all possible permutations) - if we assume there is only one or two swaps, then bubblesort comes out best. Do you understand this, or do you need more explanation? Do you see the point yet? >> >> That's just some ideas for what "optimal" could mean here - but you >> haven't even hinted at what you want (despite me asking many times). >> Nor have you given appropriate details and limits in the problem in >> order for most of these options for "optimal" to make sense - and to the >> extent that they do make sense, it is immediately obvious that there is >> no optimal strategy. I outlined a proof earlier - feel free to make it >> rigorous if you like. >> > Let's run with the worst case scenario, the enemy with N bytes of text > to throw at us, which he distributes as he pleases, knowing our algorithm. > That'll give you some handle on how to at least approach the problem. When you are dealing with an "enemy", who knows the algorithm, you are making a totally different sort of problem - it is game theory, a prisoners' dilemma, rather than an algorithm for handling a problem. And with these specific details, the answer is clear, simple, and utterly useless. The allocator needs to be able to handle data up to size N. The best (lowest cost) in this case is N, by making a single allocation of size N. There is no way to get a lower cost than this when the enemy throws size N at us. So N is the lowest bound for the worst-case cost. If we always allocate size N at the beginning, then we have enough space regardless of the size we are given - and we do not raise the worst case cost above N. Thus by always allocating size N, we have minimised the worst case sample cost, which is our global cost function. As I said, clear, simple, and utterly useless. Now, do you see the importance of giving a sensible global cost function? And perhaps the importance of giving a sensible distribution? >> >> Of course, even if you /do/ give us a problem that makes sense and can >> be answered, that does not mean that I /will/ answer it. I might have >> done had it come earlier, but it has been such a time-consuming ordeal >> trying to correct and explain your fundamental misunderstandings about >> maths, English language, problems, and algorithms, that I am unlikely to >> bother. >> >> If you want to be treated seriously here, you need to start reading >> other people's posts (like mine, for example), and understanding what we >> are saying and why you have been wrong in almost every single thing you >> have said in this thread. And you need to start admitting that, so that >> you can start learning something here. >> > You're desire seems to be to get Malcolm to admit that he is wrong. > But the challenge is there. I'm not hearing anything convincing. You have been shown to be wrong on a wide variety of your statements in this thread. Just read back in the thread, and see how often multiple people have challenged or corrected you, and you have responded with more white noise or simply ignoring them. I realise that getting you to admit to being wrong is a bit like asking fir to post in English, but I haven't given up hope yet. > > Let's start with the enemy hypothesis. The messages are being sent by an enemy. > Our enemy has N bytes at his disposal. He might have infinite bytes, but then > he can impose an infinite cost on us, and there's nothing we can do. > > Another bit of information is that the messages have to be human-composed English > language messages. Ok, you can't cope with that information yet, you don't understand > how to incorporate it. Or you do understand and you're teasing me. One of the two. > So forget it for the time being. > > Let's assume that our strategy is to start by 1, and increment the amount by > a coefficient each time. Unless you can propose a better strategy, that is. > > On that model, can we write function that returns a cost, given a growth coefficient > and an enemy attack of N bytes? >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 06:04 -0700 |
| Message-ID | <66b7e2b4-e852-4af5-990f-b79d979c0dde@googlegroups.com> |
| In reply to | #60511 |
On Monday, April 20, 2015 at 12:38:08 PM UTC+1, David Brown wrote: > On 20/04/15 12:58, Malcolm McLean wrote: > > If we are to make an optimal strategy or algorithm, we need a cost > function that covers /all/ runs. Not just /one/ run - /all/ runs. > OK, so the one run problem isn't helpful. > > Let's try and explain it in a simple example - sorting a sequence of > size 8. If the given sequence is "a, b, c, e, d, f, g, h", then the > optimum strategy is to swap elements 3 and 4 (numbering from 0 - this is > a C newsgroup!). You can't beat that algorithm - it is optimal. > > But is that much use to anyone? No, because it is optimal for a single > case. To be useful, we need a /global/ cost function, such as the > average number of swaps needed for all 8! permutations of inputs. We > can try to find an optimal algorithm for this global cost function, and > end up with something like quicksort. Alternatively, we might use the > worst-case number of swaps for all 8! permutations, in which case > quicksort comes out badly and mergesort or insertionsort are better > choices. Maybe we know something about the distribution, rather than > assuming it is random (i.e., considering all possible permutations) - if > we assume there is only one or two swaps, then bubblesort comes out best. > > > Do you understand this, or do you need more explanation? Do you see the > point yet? > > > Let's run with the worst case scenario, the enemy with N bytes of text > > to throw at us, which he distributes as he pleases, knowing our algorithm. > > That'll give you some handle on how to at least approach the problem. > > When you are dealing with an "enemy", who knows the algorithm, you are > making a totally different sort of problem - it is game theory, a > prisoners' dilemma, rather than an algorithm for handling a problem. > > And with these specific details, the answer is clear, simple, and > utterly useless. > > The allocator needs to be able to handle data up to size N. The best > (lowest cost) in this case is N, by making a single allocation of size > N. There is no way to get a lower cost than this when the enemy throws > size N at us. So N is the lowest bound for the worst-case cost. If we > always allocate size N at the beginning, then we have enough space > regardless of the size we are given - and we do not raise the worst case > cost above N. Thus by always allocating size N, we have minimised the > worst case sample cost, which is our global cost function. > > As I said, clear, simple, and utterly useless. > > Now, do you see the importance of giving a sensible global cost > function? And perhaps the importance of giving a sensible distribution? > English literature graduates make the best programmers. You've tried to apply a mathematical mindset to the answer, and come up with a useless answer. Assuming enemy has N bytes, what's our optimal strategy? One allocation of N. But I just suggested that as a route into the problem. If you plump for exponential growth, and enemy has N bytes, and will always send you the last allocation, plus one, how does the waste respond? We can't spy on the enemy and really establish N. But we know that he's got to claim that he's sending us "human-composed English messages". He can't hook up a computer and send us random bytes, he's not allowed to do that. So let's have the function. One attack, always of less than N bytes, always tailored to be exactly the maximum he can send that is your last allocation that wouldn't bring him over the lit, plus one. And yes, you'll find a mimimum at x = N, where he sends you two bytes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-20 15:37 +0200 |
| Message-ID | <mh2vdm$klg$1@dont-email.me> |
| In reply to | #60519 |
On 20/04/15 15:04, Malcolm McLean wrote: > On Monday, April 20, 2015 at 12:38:08 PM UTC+1, David Brown wrote: >> On 20/04/15 12:58, Malcolm McLean wrote: >> >> If we are to make an optimal strategy or algorithm, we need a cost >> function that covers /all/ runs. Not just /one/ run - /all/ runs. >> > OK, so the one run problem isn't helpful. >> >> Let's try and explain it in a simple example - sorting a sequence of >> size 8. If the given sequence is "a, b, c, e, d, f, g, h", then the >> optimum strategy is to swap elements 3 and 4 (numbering from 0 - this is >> a C newsgroup!). You can't beat that algorithm - it is optimal. >> >> But is that much use to anyone? No, because it is optimal for a single >> case. To be useful, we need a /global/ cost function, such as the >> average number of swaps needed for all 8! permutations of inputs. We >> can try to find an optimal algorithm for this global cost function, and >> end up with something like quicksort. Alternatively, we might use the >> worst-case number of swaps for all 8! permutations, in which case >> quicksort comes out badly and mergesort or insertionsort are better >> choices. Maybe we know something about the distribution, rather than >> assuming it is random (i.e., considering all possible permutations) - if >> we assume there is only one or two swaps, then bubblesort comes out best. >> >> >> Do you understand this, or do you need more explanation? Do you see the >> point yet? /Please/ answer this. >> >>> Let's run with the worst case scenario, the enemy with N bytes of text >>> to throw at us, which he distributes as he pleases, knowing our algorithm. >>> That'll give you some handle on how to at least approach the problem. >> >> When you are dealing with an "enemy", who knows the algorithm, you are >> making a totally different sort of problem - it is game theory, a >> prisoners' dilemma, rather than an algorithm for handling a problem. >> >> And with these specific details, the answer is clear, simple, and >> utterly useless. >> >> The allocator needs to be able to handle data up to size N. The best >> (lowest cost) in this case is N, by making a single allocation of size >> N. There is no way to get a lower cost than this when the enemy throws >> size N at us. So N is the lowest bound for the worst-case cost. If we >> always allocate size N at the beginning, then we have enough space >> regardless of the size we are given - and we do not raise the worst case >> cost above N. Thus by always allocating size N, we have minimised the >> worst case sample cost, which is our global cost function. >> >> As I said, clear, simple, and utterly useless. >> >> Now, do you see the importance of giving a sensible global cost >> function? And perhaps the importance of giving a sensible distribution? >> > English literature graduates make the best programmers. Bollocks. (And yes, I know that was not a sentence.) It is a myth with no foundation in reality. Being good at English (or at least one's native language) is important for being a good programmer, but it is hardly sufficient. Strong mathematical skills are more relevant. (Note also that you cannot be a good mathematician without good language skills. My mathematics tutor at university put a lot of emphasis on communication and language skills, which I think contributed to my programming ability.) Your English literature degree may have taught you to read books, but you have demonstrated an extraordinary failure to communicate in this thread, as well as your lack of mathematical understanding. > > You've tried to apply a mathematical mindset to the answer, and come up with > a useless answer. Assuming enemy has N bytes, what's our optimal strategy? > One allocation of N. When you ask a stupid question, you get a stupid answer. My strategy is optimal - the maths prove it. It is hardly the fault of mathematics that you have come up with a daft problem. > But I just suggested that as a route into the problem. If you plump for exponential > growth, and enemy has N bytes, and will always send you the last allocation, plus > one, how does the waste respond? But the enemy won't send you the last allocation - he knows your algorithm, so if you use an exponential growth (with any factor you like) he will send N bytes and force you to have a re-allocation of N in addition to everything you have allocated so far, and thus have a worse cost than simply allocating N in the first place. > > We can't spy on the enemy and really establish N. But we know that he's got to claim > that he's sending us "human-composed English messages". He can't hook up a > computer and send us random bytes, he's not allowed to do that. You asked for an answer, after finally giving enough information for an answer to be possible. You don't like the answer, because it doesn't fit your pet theory. So your solution is to change the question yet again? When your English literature exam asked for a discussion of Viola's role in "12th Night", did you reply with "I don't like Viola - let's talk about Rosalind in "As you like it" instead" ? Is this what makes English literature students such great programmers, and mathematicians such bad ones? > > So let's have the function. One attack, always of less than N bytes, always tailored to > be exactly the maximum he can send that is your last allocation that wouldn't bring him > over the lit, plus one. > And yes, you'll find a mimimum at x = N, where he sends you two bytes. > This brings us back to the earlier situation that I already answered (but you ignored, perhaps because you didn't understand it). If you have a strategy with allocations s_1, s_2, s_3, etc., then there will be an N for which 2*s_1, 2*s_2, 2*s_3, etc., would have been a better strategy. This means there is /no/ optimal strategy.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 06:52 -0700 |
| Message-ID | <11aad503-35ec-4f34-9e31-e0d4fd384fb9@googlegroups.com> |
| In reply to | #60522 |
On Monday, April 20, 2015 at 2:38:01 PM UTC+1, David Brown wrote: > > This brings us back to the earlier situation that I already answered > (but you ignored, perhaps because you didn't understand it). > > If you have a strategy with allocations s_1, s_2, s_3, etc., then there > will be an N for which 2*s_1, 2*s_2, 2*s_3, etc., would have been a > better strategy. This means there is /no/ optimal strategy. > But what's N?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-20 16:23 +0200 |
| Message-ID | <mh323j$v6k$1@dont-email.me> |
| In reply to | #60524 |
On 20/04/15 15:52, Malcolm McLean wrote: > On Monday, April 20, 2015 at 2:38:01 PM UTC+1, David Brown wrote: >> >> This brings us back to the earlier situation that I already answered >> (but you ignored, perhaps because you didn't understand it). >> >> If you have a strategy with allocations s_1, s_2, s_3, etc., then there >> will be an N for which 2*s_1, 2*s_2, 2*s_3, etc., would have been a >> better strategy. This means there is /no/ optimal strategy. >> > But what's N? > You've just told me you don't know - that's part of the "specification" of the problem! Look, since you don't like maths, lets just give an example. Please answer /every/ question below - it's the only way to see where you are getting things wrong. (I'm ignoring your minor change that said the attack was always /less/ than N bytes - I presume that's just your loose wording again.) Suppose the maximum size the enemy has, N, is 100. The enemy's best strategy to make you "pay" as much as possible is to send N bytes - 100 bytes in this case. Do you understand this? Do you agree? In order to minimise the cost, your allocator strategy should be to minimise the cost when given N bytes. It can do this by allocating N bytes immediately. Note that this is the /best/ strategy - even if the allocator cannot implement it, because it doesn't know N. Do you understand this? Do you agree? Therefore our allocator can only have an "optimal" strategy if it picks N as its first and only allocation. Without knowing N, there is no way to know the optimal strategy (and no way to be sure it is optimal, as the enemy, who knows our strategy, could choice to be confusing and nasty and send less than N, rather than choosing to make us pay as much as possible). Do you understand this? Do you agree?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 07:32 -0700 |
| Message-ID | <869ef60c-52fa-4a67-9c06-2bbec4bf7b0e@googlegroups.com> |
| In reply to | #60526 |
On Monday, April 20, 2015 at 3:23:50 PM UTC+1, David Brown wrote: > On 20/04/15 15:52, Malcolm McLean wrote: > > Suppose the maximum size the enemy has, N, is 100. The enemy's best > strategy to make you "pay" as much as possible is to send N bytes - 100 > bytes in this case. > > Do you understand this? Do you agree? > Enemy has N bytes. But he's maybe got a range of "best" strategies, if he can see our code. If we allocate 1024 bytes and have done, he can send anything between 1-100 bytes, all are equally good. > > > In order to minimise the cost, your allocator strategy should be to > minimise the cost when given N bytes. It can do this by allocating N > bytes immediately. > > Note that this is the /best/ strategy - even if the allocator cannot > implement it, because it doesn't know N. > Ok so the best strategy is to allocate exactly N bytes, if we know N. But we don't know N, we can't spy on the enemy to see what he has available. So we're back to square one, we've got to estimate N. But we haven't been told the probability distribution of N explicitly, in the way that mathematicians like. We have been told that he's got to at least clim to be sending us human-composed English language messages. Now the number of atoms in the universe has been estimated at 10^82. You agree that if he sends us 10^82 characters, and uses one atom to carry each character, he has no atoms left for the human which is an essential part of the system? Would you a agree that N can't be over 10^8? > > Therefore our allocator can only have an "optimal" strategy if it picks > N as its first and only allocation. Without knowing N, there is no way > to know the optimal strategy (and no way to be sure it is optimal, as > the enemy, who knows our strategy, could choice to be confusing and > nasty and send less than N, rather than choosing to make us pay as much > as possible). > > Do you understand this? Do you agree? > Ok, we don't know N, but we know that N is less than 10^82. Agreed? And we know that N isn't zero, agreed?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-20 22:42 +0200 |
| Message-ID | <mh3oab$s4a$1@dont-email.me> |
| In reply to | #60527 |
On 20/04/15 16:32, Malcolm McLean wrote: > On Monday, April 20, 2015 at 3:23:50 PM UTC+1, David Brown wrote: >> On 20/04/15 15:52, Malcolm McLean wrote: >> >> Suppose the maximum size the enemy has, N, is 100. The enemy's best >> strategy to make you "pay" as much as possible is to send N bytes - 100 >> bytes in this case. >> >> Do you understand this? Do you agree? >> > Enemy has N bytes. > But he's maybe got a range of "best" strategies, if he can see our code. > If we allocate 1024 bytes and have done, he can send anything between 1-100 > bytes, all are equally good. But none are /better/ than sending 1024. And if he can send more than 1024, that would be even better. It is perfectly obvious that no strategy can be better for the enemy than sending the maximum allowed length. Why go to the effort thinking of complicated strategies, or even looking at the allocator's algorithm, when he can simply always send the maximum length? >> >> >> In order to minimise the cost, your allocator strategy should be to >> minimise the cost when given N bytes. It can do this by allocating N >> bytes immediately. >> >> Note that this is the /best/ strategy - even if the allocator cannot >> implement it, because it doesn't know N. >> > Ok so the best strategy is to allocate exactly N bytes, if we know N. > But we don't know N, we can't spy on the enemy to see what he has > available. So we're back to square one, we've got to estimate N. But > we haven't been told the probability distribution of N explicitly, in > the way that mathematicians like. We have been told that he's got > to at least clim to be sending us human-composed English language > messages. > Now the number of atoms in the universe has been estimated at 10^82. > You agree that if he sends us 10^82 characters, and uses one atom to > carry each character, he has no atoms left for the human which is an > essential part of the system? Would you a agree that N can't be over 10^8? Any figure you give here is totally pointless. >> >> Therefore our allocator can only have an "optimal" strategy if it picks >> N as its first and only allocation. Without knowing N, there is no way >> to know the optimal strategy (and no way to be sure it is optimal, as >> the enemy, who knows our strategy, could choice to be confusing and >> nasty and send less than N, rather than choosing to make us pay as much >> as possible). >> >> Do you understand this? Do you agree? >> > Ok, we don't know N, but we know that N is less than 10^82. Agreed? > And we know that N isn't zero, agreed? > Horray - we've made great progress at narrowing down the possibilities. Rather than reading my posts, thinking about them, or answering the questions, you've come up with a pointless argument showing that N is between 1 and 10^82. Marvellous. Get back to me when you have decided to apply the other brain cell to this thread.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-20 21:56 -0700 |
| Message-ID | <28102a8b-4afa-435c-9dcd-e46394898e7d@googlegroups.com> |
| In reply to | #60568 |
On Monday, April 20, 2015 at 9:43:00 PM UTC+1, David Brown wrote: > On 20/04/15 16:32, Malcolm McLean wrote: > > > Enemy has N bytes. > > But he's maybe got a range of "best" strategies, if he can see our code. > > If we allocate 1024 bytes and have done, he can send anything between > > 1-100 bytes, all are equally good. > > But none are /better/ than sending 1024. And if he can send more than > 1024, that would be even better. It is perfectly obvious that no > strategy can be better for the enemy than sending the maximum allowed > length. Why go to the effort thinking of complicated strategies, or > even looking at the allocator's algorithm, when he can simply always > send the maximum length? > You've got to think that you're applying a function to areal problem. Clearly our best strategy is to know in advance what the message size will be, and allocate that many bytes. That's what that minimum represents. So it's not actually a useless observation. But we need the other minimum. Given that our strategy is frozen, given that the enemy has N bytes of data at his disposal, which he's going to send to us. Now I've already suggested that he might send us all the data in one or two byte packets (depending on whether we actually allocate the first byte). Assuming we don't allocate first the byte, then our cost is N * ceil(growth). So he's not going to use this strategy, unless we make N very large. He going to send us the largest message he can, that's just one byte over our last allocation. So to keep things simple, -for now- we just consider one attack. It's a trade off problem. If we grow slowly, we make lots of allocations, but we only take a short last byte. So if calls to realloc are free, and our only concern is to preserve memory, the growth factor should be a trifle below unity. If memory is free, and our only concern is minimise calls to realloc(), then we make one call to allocate the biggest chunk of memory we can. But nether of those apply, as we've set things up, all the calls cost proportional to memory. We can see that if we make the growth really high, we'll save on calls, but we'll have a chunk left over, if we make it really low, we'll make lots of calls, but we won't allocate much excess memory. Once we've considered that, we can move on to considering what the enemy will do next. Unless the growth factor is large in relation to his total stock of text, he'll always send us the largest amount he can, which is one above our last allocation. He wants us to waste as much memory as possible. But he doesn't want to waste his text. And there are two situations we've got to consider, one when the amount of text the enemy has exceeds our maximum allocation, one when we can allocate as much as the enemy has. > > > Now the number of atoms in the universe has been estimated at 10^82. > > You agree that if he sends us 10^82 characters, and uses one atom to > > carry each character, he has no atoms left for the human which is an > > essential part of the system? Would you a agree that N can't be over > > 10^8? > > Any figure you give here is totally pointless. > No, this is your underlying mistake. N is the amount of text the enemy has available. But whilst he is in control of how he distributes that text to send to us, he's not in control of how much he can lay his hands on. (He can of course refuse to send us text, but that's pointless). N is controlled by a physical factor. N is real data. > > Horray - we've made great progress at narrowing down the possibilities. > Rather than reading my posts, thinking about them, or answering the > questions, you've come up with a pointless argument showing that N is > between 1 and 10^82. Marvellous. > > Get back to me when you have decided to apply the other brain cell to > this thread. > It's not pointless. It's the difference between infinite and "unbounded". However much text enemy has, he can always sit at his keyboard and tap out a but more. It's "unbounded" in that sense. But the probability density function for N goes to zero at infinity. The point is, we can't sensibly pluck a number out of the air on 0-infinity, and say "that will be N". We've got to give a physical justification. In this case, the scenario is that every atom in the universe is an English letter. That's utterly ridiculous. So the next scenario is that every atom in the world is an English letter. Shaves off many many orders of magnitude. So the next proposal is that the entire world is a memory chip, which holds the text. Now you can say that all of these suggestions are so ridiculous that the probability is a mathematical, exact zero. Or you can say that the whole world being a memory chip is at least physically possible, it's less ridiculous than the entire universe being letters. But what happens when we get to sane, sensible suggestions for a limit on N? One proposal is that by English-language messages we mean "published texts", and the messages can't go above the length of the longest book considered to be a unitary work. Another person might say "no, he could concatenate all the texts he has, and just all, "Hi guys, here's a list of all the books I want you to read"". It's hard to say, given the spec, whether that would be legitimate or not. And if we allow it, how much text could he get? He could download the WWW, but then we could get him on duplication and say that that doesn't count as human-composed text. We assume that everyone in the world has written a million word novel, which is another "crazy" limit, but not as ridiculous as the former ones. The point is that the sensible, natural interpretation is that N is "the longest book ever written". As we make other suggestions, they get steadily more far-fetched and ridiculous. But I could be wrong about N being a long single book, who's to say. So we've got a probability distribution for N, at least sketched it out. It's got a peak at somewhere near 1 million words, and it decays to zero at infinity. The ridiculous suggestions at the extreme high end are the real world interpretation of an exponential decay process. The point is, it's crucial to know what your equations actually represent, if there's the slightest amount of uncertainty in them. So we see now that we can actually get a handle on the problem. It's not inherently insoluble, but only if you've got flexibility of thought and reasoning.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-21 09:21 +0200 |
| Message-ID | <mh4tn3$8a0$1@dont-email.me> |
| In reply to | #60602 |
On 21/04/15 06:56, Malcolm McLean wrote: > You've got to think that you're applying a function to areal problem If this were a /real/ problem, the /real/ solutions proposed by several people long ago would be appropriate (like streaming the data to a file, or making a linked list of malloc'ed blocks), taking into account /real/ cost functions (rather than your imaginary ones). If it were a /real/ problem, you wouldn't be using the number of atoms in the universe when figuring out the maximum size of an input. It is a totally /artificial/ problem. There's nothing wrong with artificial problems - that's how much of the theory of algorithms gets figured out, and then it can be applied to real problems. But artificial problems have artificial answers. I have shown, clearly (I hope) and mathematically answers to several of the variants of your artificial problems while you change the rules and details in every other post. In no case have the answers matched your imagined and desired result - and in no case have they been useful answers that could be applied in real problems. This demonstrates that your artificial problem bears little relation to any real-life problems. It also shows that some problems don't have answers, and it shows the importance of defining your problem accurately.
[toc] | [prev] | [next] | [standalone]
Page 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web