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 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-17 08:07 -0700 |
| Message-ID | <kfnh9seyerk.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60210 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, April 16, 2015 at 8:12:42 PM UTC+1, Martin Shobe wrote: >> On 4/15/2015 11:38 PM, Steve Thompson wrote: >> >> The bit about roots and minimums is more obscure. Yes, you can >> transform the problem of finding a root for a function, f, into >> the problem of finding the minimum of |f|. However, I can't see >> any advantage to it. You've lost information by doing so (in >> particular, the sign of f(x)). In the particular case given, you >> are stuck with a try everything until you find a zero approach >> instead of being able to perform a binary search. > > You could square a function, then pass it to a general-purpose > minimiser. An extremely poor idea. In almost all cases this will entail more work and also produce worse results.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-15 12:29 -0700 |
| Message-ID | <87h9shrxzq.fsf@kst-u.example.com> |
| In reply to | #60091 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, April 15, 2015 at 5:24:57 PM UTC+1, David Brown wrote:
>> On 15/04/15 17:57, Malcolm McLean wrote:
>> > On Wednesday, April 15, 2015 at 4:08:16 PM UTC+1, Keith Thompson wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >>
>> > That's just usage.
>> > People say "minimisation" when they're trying to find a maximum,
>> > conventionally you invert the function.
>>
>> Let me get this straight - when /you/ say "minimise", you sometimes mean
>> "find a 0", and sometimes "find a maximum". What do you call it when
>> you want to find a minimum? Painting the function pink? Translating it
>> to Chinese?
>>
> Minimise often means maximise. Conventionally you search for a minimum, and
> invert the sign if you actually want a maximum.
> That's legitimately confusing, but it's how people who deal with these things
> day in and day out talk.
Whether that remarkable claim is accurate or not, *I* have never heard
the word "minimise" (or "minimize") used in that way. I do not deal
with these things day in and day out, and chances are most other people
here don't either.
If you're using technical jargon from a field that most of your readers
are not familiar with, it is *your* responsibility to be clear, not ours
to infer that "minimise" means finding the argument for which a function
that can return -1, 0, or +1 returns 0, or failing that transitions from
-1 to +1.
>> I don't even know where to start with your complete misunderstanding of
>> the word "derivative" - perhaps you forgot to mention that you use the
>> word "derivative" here to mean different species of fish.
>>
> You can think of the function as a step, with the points above the critical value
> as one and the points below as minus one. Or you can think of it as a valley
> with the critical value as the lowest point, and one side pointing down,
> and the other side also pointing down, but from the other direction.
You're saying that you can think of the function (which function?) in
two entirely inconsistent ways. Using crude ASCII graphics (you may
need to use a fixed-width font to view this), you first describe a
function whose graph would look something like this (the + and |
characters are meant to be vertically aligned):
+-------------
|
------------+
and then a function whose graph would look something like this:
----------\ /---------
\ /
V
You say these are two ways to think of the same function. I say
they're different functions.
The closest I can get to making your descriptions make sense is
that the second graph is of the negated derivative of the function
represented by the first (negated so that using the word "minimise"
makes some kind of sense) -- except that the functions you've been
desribing have a discontinuity where they transition from -1 to +1,
and have no defined derivative at that point.
And what does this have to do either with C or with the point you
were trying to make about the golden ratio?
--
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-15 22:56 -0700 |
| Message-ID | <79e51590-587b-4fc3-8d7d-8c942be64d1b@googlegroups.com> |
| In reply to | #60100 |
On Wednesday, April 15, 2015 at 8:29:57 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > You're saying that you can think of the function (which function?) in > two entirely inconsistent ways. Using crude ASCII graphics (you may > need to use a fixed-width font to view this), you first describe a > function whose graph would look something like this (the + and | > characters are meant to be vertically aligned): > > +------------- > | > ------------+ > > and then a function whose graph would look something like this: > > ----------\ /--------- > \ / > V > > You say these are two ways to think of the same function. I say > they're different functions. > They're not really. The function is "too low", "too high" or "just right". So you can think of it as looking for a step, or you can think of it as looking for the low point of a valley with two walls pointing you to the answer. It's what visualisation works for you. > > The closest I can get to making your descriptions make sense is > that the second graph is of the negated derivative of the function > represented by the first (negated so that using the word "minimise" > makes some kind of sense) -- except that the functions you've been > desribing have a discontinuity where they transition from -1 to +1, > and have no defined derivative at that point. > > And what does this have to do either with C or with the point you > were trying to make about the golden ratio? > The question is how to probe something you know next to nothing about. For example, we've opened a stream, which we know will send us a human-composed message in English text. We want to store it in a memory buffer. Every time we ask for memory, we get charged on a per byte basis (the malloc zeroes out memory, so if you ask for 20K, that's ten times as expensive as asking for 2K). realloc() has exactly the same cost as malloc(). So, clearly, our best strategy is to get a statistical distribution of the messages coming in, and then work out some sort of formula that minimises the number of calls. But we can't do that if we're on version 0. We haven't had any messages to analyse yet. All we know is that the program is expected to handle "human-composed messages in English text". So what's our best strategy now?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-16 10:29 +0100 |
| Message-ID | <mgnvc6$l93$1@dont-email.me> |
| In reply to | #60111 |
On 16/04/15 06:56, Malcolm McLean wrote: <snip> > The question is how to probe something you know next to nothing about. > For example, we've opened a stream, which we know will send us a > human-composed message in English text. We want to store it in a > memory buffer. Every time we ask for memory, we get charged on a > per byte basis (the malloc zeroes out memory, so if you ask for 20K, > that's ten times as expensive as asking for 2K). realloc() has > exactly the same cost as malloc(). > So, clearly, our best strategy is to get a statistical distribution > of the messages coming in, and then work out some sort of formula > that minimises the number of calls. No, the best strategy is to change what we want, very slightly. Instead of storing it in memory, we store it in a file, counting bytes as we go. We can then, if we wish, use that count to define a VLA and then read the whole file into that VLA, reducing the number of calls to malloc/realloc to 0, and thus eliminating the cost entirely. The trouble with analogies is that they break so easily. -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-16 04:46 -0700 |
| Message-ID | <1b6b5751-1777-4731-a9ac-d34437780abf@googlegroups.com> |
| In reply to | #60122 |
On Thursday, April 16, 2015 at 10:29:46 AM UTC+1, Richard Heathfield wrote: > On 16/04/15 06:56, Malcolm McLean wrote: > > > The question is how to probe something you know next to nothing about. > > For example, we've opened a stream, which we know will send us a > > human-composed message in English text. We want to store it in a > > memory buffer. Every time we ask for memory, we get charged on a > > per byte basis (the malloc zeroes out memory, so if you ask for 20K, > > that's ten times as expensive as asking for 2K). realloc() has > > exactly the same cost as malloc(). > > So, clearly, our best strategy is to get a statistical distribution > > of the messages coming in, and then work out some sort of formula > > that minimises the number of calls. > > No, the best strategy is to change what we want, very slightly. Instead > of storing it in memory, we store it in a file, counting bytes as we go. > We can then, if we wish, use that count to define a VLA and then read > the whole file into that VLA, reducing the number of calls to > malloc/realloc to 0, and thus eliminating the cost entirely. > > The trouble with analogies is that they break so easily. > If you've genuinely got no other constraints than calls to realloc() then you can do things differently. But it's a real problem. The statistical distribution answer is likely to be impractical. The "farm out to disk" answer is going to be too slow and put junk on someone's hard drive. The "allocate lots of sections and join them up" solution means your peak memory use is double - in the problem as I posed it, not a prohibitive penalty, but likely a constraint, and it's too much complicated code. People genuinely do have streams of data coming in, they want to increase buffer size to accommodate the stream,and they want to minimise both memory take and reallocations. (The unrealistic part is that you have a balance between memory take and reallocations/copies in real life, which means that it's a much harder optimisation problem).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-16 13:08 +0100 |
| Message-ID | <mgo8lp$k7u$1@dont-email.me> |
| In reply to | #60132 |
On 16/04/15 12:46, Malcolm McLean wrote: <snip> > If you've genuinely got no other constraints than calls to realloc() then > you can do things differently. In other words, the problem statement was imprecise. > But it's a real problem. The statistical distribution answer is likely to be > impractical. The "farm out to disk" answer is going to be too slow and > put junk on someone's hard drive. You'd be surprised. Firstly, disks are astoundingly fast nowadays. Secondly, servers are cheap, so it doesn't have to be "someone's" hard drive. It can be a RAID in the data centre. That way, it's the shareholders' hard drive, and they don't have access anyway, so that's all right. > The "allocate lots of sections and join > them up" solution means your peak memory use is double - in the > problem as I posed it, not a prohibitive penalty, but likely a constraint, > and it's too much complicated code. Actually, the real, true, genuine, correct, legitimate, copper-bottomed answer to your question is that malloc and realloc are far cheaper than you suggested, and your constraint was therefore an artificial one. > People genuinely do have streams of data coming in, they want to increase > buffer size to accommodate the stream,and they want to minimise > both memory take and reallocations. (The unrealistic part is that you > have a balance between memory take and reallocations/copies in real > life, which means that it's a much harder optimisation problem). If you have more data coming in than one machine can comfortably handle, then either you're the Met Office, in which case you already have a good solution to this problem, or (almost certainly) your data don't actually need to be related to each other in anything other than a meta-relationship, so you can simply farm out different tasks to different machines. For example, if three thousand people are all uploading videos to you at the same time, you may need to be able to store them all, but you probably don't need to have them all in one particular computer's memory at the same time. Or if you're receiving image data for rendering, you don't need to have every image in the same computer's memory at the same time - you can hurl the images into the rendering farm. I'm not saying we should be wasteful of resources - of course I'm not - but you'll not be saving money by trying to squeeze every last milli-ounce of performance out of a machine by coming up with tricksy algorithms when it's quicker and cheaper to throw another box at the problem instead. -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-16 08:42 -0700 |
| Message-ID | <719091a8-bd17-44a1-a986-fccd90282c6a@googlegroups.com> |
| In reply to | #60136 |
On Thursday, April 16, 2015 at 1:08:28 PM UTC+1, Richard Heathfield wrote: > On 16/04/15 12:46, Malcolm McLean wrote: > > > If you've genuinely got no other constraints than calls to realloc() then > > you can do things differently. > > In other words, the problem statement was imprecise. > I should have specified that you can only have one buffer, and the data must always be maintained in a contiguous state in the buffer. That does make the problem sound artificial. > > Actually, the real, true, genuine, correct, legitimate, copper-bottomed > answer to your question is that malloc and realloc are far cheaper than > you suggested, and your constraint was therefore an artificial one. > Ok, so think of a C++ vector. We have to implement push_back(). Or think of the original problem where we're trying to find the point at which memory runs out. Or, as I recast it, we're doing a search for the size of a fish. Or you're probing the free energy landscape of biomolecule and you want to find the local minimum in a given direction in configuration space. It's all essentially the same problem. The last one could gobble up weeks of supercomputer time. > > I'm not saying we should be wasteful of resources - of course I'm not - > but you'll not be saving money by trying to squeeze every last > milli-ounce of performance out of a machine by coming up with tricksy > algorithms when it's quicker and cheaper to throw another box at the > problem instead. > I try to give a simple, familiar example. What we're really after is sampling free energy surfaces. But a lot of people aren't very familiar with entropy, enthalpy, partial derivatives, Hessian matrices and all the apparatus of that subset of programming. Most people have seen a few fishes, maybe even caught one.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-16 16:47 +0100 |
| Message-ID | <87iocw9itn.fsf@bsb.me.uk> |
| In reply to | #60111 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > For example, we've opened a stream, which we know will send us a > human-composed message in English text. We want to store it in a > memory buffer. Every time we ask for memory, we get charged on a > per byte basis (the malloc zeroes out memory, so if you ask for 20K, > that's ten times as expensive as asking for 2K). realloc() has > exactly the same cost as malloc(). > So, clearly, our best strategy is to get a statistical distribution > of the messages coming in, and then work out some sort of formula > that minimises the number of calls. Can you prove that (or have I made the mistake of taking you literally again)? Given the cost model you've proposed, the optimal strategy would seem to involve minimising the number of bytes allocated, not the number of calls made. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-16 16:53 +0100 |
| Message-ID | <mgolrj$62p$1@dont-email.me> |
| In reply to | #60145 |
On 16/04/15 16:47, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > <snip> >> For example, we've opened a stream, which we know will send us a >> human-composed message in English text. We want to store it in a >> memory buffer. Every time we ask for memory, we get charged on a >> per byte basis (the malloc zeroes out memory, so if you ask for 20K, >> that's ten times as expensive as asking for 2K). realloc() has >> exactly the same cost as malloc(). >> So, clearly, our best strategy is to get a statistical distribution >> of the messages coming in, and then work out some sort of formula >> that minimises the number of calls. > > Can you prove that (or have I made the mistake of taking you literally > again)? Given the cost model you've proposed, the optimal strategy > would seem to involve minimising the number of bytes allocated, not the > number of calls made. Since minimising is the same as maximising, you can use as many bytes as you like and it won't cost you any extra. Or perhaps even using as few bytes as you can will still result in an unmanageable fee. So the best strategy would appear to buy your memory from a more reasonable supplier. -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-16 10:52 -0700 |
| Message-ID | <58fa4013-d529-4a33-9efb-84e73bf90169@googlegroups.com> |
| In reply to | #60145 |
On Thursday, April 16, 2015 at 4:47:17 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > <snip> > > For example, we've opened a stream, which we know will send us a > > human-composed message in English text. We want to store it in a > > memory buffer. Every time we ask for memory, we get charged on a > > per byte basis (the malloc zeroes out memory, so if you ask for 20K, > > that's ten times as expensive as asking for 2K). realloc() has > > exactly the same cost as malloc(). > > So, clearly, our best strategy is to get a statistical distribution > > of the messages coming in, and then work out some sort of formula > > that minimises the number of calls. > > Can you prove that (or have I made the mistake of taking you literally > again)? Given the cost model you've proposed, the optimal strategy > would seem to involve minimising the number of bytes allocated, not the > number of calls made. > malloc(10) costs 10 units, malloc(20) costs 20 units realloc(ptr, 10) costs 10 units, realloc(ptr, 20) costs 20 units. So if we start with ptr = malloc(1) and then call ptr = realloc(ptr, 2), ptr = realloc(ptr, 3) etc it's an expensive algorithm, costing N^2/2 (plus N/2, since I'm under attack for being unclear and wrong in every respect). We're only allowed one buffer, I must clarify. Otherwise you can generate lots of buffers of one byte and trivially get an optimal answer.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-16 22:11 +0100 |
| Message-ID | <87bnin93sm.fsf@bsb.me.uk> |
| In reply to | #60165 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, April 16, 2015 at 4:47:17 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> <snip> >> > For example, we've opened a stream, which we know will send us a >> > human-composed message in English text. We want to store it in a >> > memory buffer. Every time we ask for memory, we get charged on a >> > per byte basis (the malloc zeroes out memory, so if you ask for 20K, >> > that's ten times as expensive as asking for 2K). realloc() has >> > exactly the same cost as malloc(). >> > So, clearly, our best strategy is to get a statistical distribution >> > of the messages coming in, and then work out some sort of formula >> > that minimises the number of calls. >> >> Can you prove that (or have I made the mistake of taking you literally >> again)? Given the cost model you've proposed, the optimal strategy >> would seem to involve minimising the number of bytes allocated, not the >> number of calls made. >> > malloc(10) costs 10 units, malloc(20) costs 20 units > realloc(ptr, 10) costs 10 units, realloc(ptr, 20) costs 20 units. Ah, so the cost is not per byte used but per byte asked for. I suppose I could have inferred that from the remark about realloc having the same cost as malloc, but I took that to mean that reallocated memory costs the same as allocated-once memory. > So if we start with ptr = malloc(1) and then call > ptr = realloc(ptr, 2), ptr = realloc(ptr, 3) etc it's an expensive algorithm, > costing N^2/2 (plus N/2, since I'm under attack for being unclear and wrong > in every respect). That's what big O and friends are for -- the cost function is O(N^2). I've lost track of where this was going, but if there is a connection with golden section search I am now in a position to follow it. > We're only allowed one buffer, I must clarify. Otherwise you can generate lots > of buffers of one byte and trivially get an optimal answer. It sounds like you are setting this as a challenge. I am not aware of any optimal strategy, but, in terms of memory actually used and copied, any exponential growth pattern avoids the quadratic behaviour of the naive approach. Are you saying that a Fibonacci pattern of allocations is known to have some theoretical advantage? I don't recall ever seeing that used (though a Fibonacci-like pattern of sizes is sometimes used in allocators that have fixed-sized blocks held in free lists). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-17 10:22 +0200 |
| Message-ID | <mgqfr8$mcv$1@dont-email.me> |
| In reply to | #60175 |
On 16/04/15 23:11, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Thursday, April 16, 2015 at 4:47:17 PM UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> <snip> >>>> For example, we've opened a stream, which we know will send us a >>>> human-composed message in English text. We want to store it in a >>>> memory buffer. Every time we ask for memory, we get charged on a >>>> per byte basis (the malloc zeroes out memory, so if you ask for 20K, >>>> that's ten times as expensive as asking for 2K). realloc() has >>>> exactly the same cost as malloc(). >>>> So, clearly, our best strategy is to get a statistical distribution >>>> of the messages coming in, and then work out some sort of formula >>>> that minimises the number of calls. >>> >>> Can you prove that (or have I made the mistake of taking you literally >>> again)? Given the cost model you've proposed, the optimal strategy >>> would seem to involve minimising the number of bytes allocated, not the >>> number of calls made. >>> >> malloc(10) costs 10 units, malloc(20) costs 20 units >> realloc(ptr, 10) costs 10 units, realloc(ptr, 20) costs 20 units. > > Ah, so the cost is not per byte used but per byte asked for. I suppose > I could have inferred that from the remark about realloc having the same > cost as malloc, but I took that to mean that reallocated memory costs > the same as allocated-once memory. > >> So if we start with ptr = malloc(1) and then call >> ptr = realloc(ptr, 2), ptr = realloc(ptr, 3) etc it's an expensive algorithm, >> costing N^2/2 (plus N/2, since I'm under attack for being unclear and wrong >> in every respect). > > That's what big O and friends are for -- the cost function is O(N^2). > I've lost track of where this was going, but if there is a connection > with golden section search I am now in a position to follow it. > >> We're only allowed one buffer, I must clarify. Otherwise you can generate lots >> of buffers of one byte and trivially get an optimal answer. > > It sounds like you are setting this as a challenge. I am not aware of > any optimal strategy, but, in terms of memory actually used and copied, > any exponential growth pattern avoids the quadratic behaviour of the > naive approach. Are you saying that a Fibonacci pattern of allocations > is known to have some theoretical advantage? I don't recall ever seeing > that used (though a Fibonacci-like pattern of sizes is sometimes used in > allocators that have fixed-sized blocks held in free lists). > There is /no/ theoretical optimal strategy, because the size of the incoming data is unbounded. For any strategy (exponential, linear, quadratic, constant, Fibonacci, whatever you like), you would generate a sequence of allocation sizes - s_i, (say 1, 1, 2, 3, 5, 8, 13, etc. for a Fibonacci strategy). No matter what sequence you pick, there will be a size N of the incoming data such that for all data sizes n > N, the sequence 2*s_i (2, 2, 4, 6, 10, 16, 26, etc., in this case) will be more efficient. I haven't proved this assertion, but I am quite confident that I /could/ prove it. I know that you, Ben, have a lot of experience in algorithm complexity - does your gut feeling agree with me here? In the real world, of course, there are different factors - the cost of a malloc/realloc has a significant constant factor as well as a cost based on the size, and there are practical considerations about the size of the memory blocks that work best. You might find that allocating in units of 4K - 16 bytes is the most efficient because it suits the malloc implementation - and you would use 16 bytes from that block to implement a linked list and avoid the realloc and copying. And possibly, depending on the source of the data, you would use statistical analysis on the incoming streams to guess the sizes of the data and thus make fewer, bigger allocations without wasting too much space. In similar situations, it is not uncommon to use an exponential growth (to avoid the quadratic behaviour, as you said) - but powers of 2 are more typical because they are simple and work well. Sometimes you want exponential growth but not as aggressive, or with more steps - and Fibonacci growth would be one possibility. But there is no theoretical advantage over it compared to, say, powers of 1.5 or powers of sqrt(2), or non-uniform allocation (B, 1.5*B, 2B, 3B, 4B, 6B, 8B, 12B, 16B - approximating powers of sqrt(2) but using nicer numbers).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-17 02:17 -0700 |
| Message-ID | <514d1b8f-b51e-407c-bba7-3da7f9dc8e5e@googlegroups.com> |
| In reply to | #60175 |
On Thursday, April 16, 2015 at 10:11:47 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > It sounds like you are setting this as a challenge. I am not aware of > any optimal strategy, but, in terms of memory actually used and copied, > any exponential growth pattern avoids the quadratic behaviour of the > naive approach. Are you saying that a Fibonacci pattern of allocations > is known to have some theoretical advantage? I don't recall ever seeing > that used (though a Fibonacci-like pattern of sizes is sometimes used in > allocators that have fixed-sized blocks held in free lists). > I've been accused of talking nonsense. Now I might well be wrong, I'm not a mathematician. But I've posed a problem and proposed an answer. No-one else has proposed an alternative solution, much less proved that their alternative is correct. They've just asserted that I am talking nonsense and nit picked at things like the jargon use of "minimise" to mean "any search for extrema". (It's fair enough for someone who doesn't understand to be confused, I don't blame anyone for that. It's the nit picking that gets wearing). But now you can check me out. Write that function, with various buffer-growing strategies. Then test it on a series of inputs with various hypotheses for what the statistical distribution of "human-composed English language messages" might be.Try linear between 1 word and 1000 words, linear between 20,000 words and 200,000 words (novels), all 25 word tweets, half gaussian, log-normal, and anything else you can think of that might be realistic. Am I right, wrong, or talking nonsense?
[toc] | [prev] | [next] | [standalone]
| From | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-04-17 05:56 -0500 |
| Message-ID | <mgqosj$bf7$1@speranza.aioe.org> |
| In reply to | #60212 |
On 4/17/15 4:17 AM, Malcolm McLean wrote: > Am I right, wrong, or talking nonsense? Yes. I went through this exercise and settled for a function that recursed until end of input, then allocated an exact-sized buffer, and stored the input into that buffer as each instance returned. The cost of char input was small, and the recursive call imposed very little execution overhead. There is a risk of running out of (stack) space with a 'large' input, so a certain amount of prudence is required - but 200000 words wouldn't be a problem on any of my last half-dozen or so machines. Code has already been posted to c.l.c - and it's online at http://www.iedu.com/mrd/c/getsm.c -- Morris Dovey http://www.iedu.com/Solar
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-17 04:37 -0700 |
| Message-ID | <25777086-a693-4f9f-915d-e40270b64ab3@googlegroups.com> |
| In reply to | #60218 |
On Friday, April 17, 2015 at 11:56:32 AM UTC+1, Morris Dovey wrote: > On 4/17/15 4:17 AM, Malcolm McLean wrote: > > > Am I right, wrong, or talking nonsense? > > Yes. I went through this exercise and settled for a function that > recursed until end of input, then allocated an exact-sized buffer, and > stored the input into that buffer as each instance returned. > > The cost of char input was small, and the recursive call imposed very > little execution overhead. There is a risk of running out of (stack) > space with a 'large' input, so a certain amount of prudence is required > - but 200000 words wouldn't be a problem on any of my last half-dozen or > so machines. > > Code has already been posted to c.l.c - and it's online at > http://www.iedu.com/mrd/c/getsm.c > Ok, so that's the first best attempt to solve the problem. Anyone offering anything superior?
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-17 10:04 -0500 |
| Message-ID | <mgr7c7$c0h$1@dont-email.me> |
| In reply to | #60222 |
On 4/17/2015 6:37 AM, Malcolm McLean wrote: > On Friday, April 17, 2015 at 11:56:32 AM UTC+1, Morris Dovey wrote: >> On 4/17/15 4:17 AM, Malcolm McLean wrote: >> >>> Am I right, wrong, or talking nonsense? >> >> Yes. I went through this exercise and settled for a function that >> recursed until end of input, then allocated an exact-sized buffer, and >> stored the input into that buffer as each instance returned. >> >> The cost of char input was small, and the recursive call imposed very >> little execution overhead. There is a risk of running out of (stack) >> space with a 'large' input, so a certain amount of prudence is required >> - but 200000 words wouldn't be a problem on any of my last half-dozen or >> so machines. >> >> Code has already been posted to c.l.c - and it's online at >> http://www.iedu.com/mrd/c/getsm.c >> > Ok, so that's the first best attempt to solve the problem. > > Anyone offering anything superior? 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. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-17 08:38 -0700 |
| Message-ID | <37d076d8-7e30-43b4-b1fa-e01a5c43a7dd@googlegroups.com> |
| In reply to | #60236 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-17 20:52 +0100 |
| Message-ID | <87d232cz2n.fsf@bsb.me.uk> |
| In reply to | #60242 |
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 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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-18 13:16 +0200 |
| Message-ID | <mgtecc$a9u$1@dont-email.me> |
| In reply to | #60260 |
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 > 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.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-18 04:22 -0700 |
| Message-ID | <90fe17bc-41e0-4263-b347-1c1ec97b3aa4@googlegroups.com> |
| In reply to | #60304 |
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. 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]
Page 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web