Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60006 > unrolled thread
| Started by | Robbie Hatley <see.my.sig@for.my.address> |
|---|---|
| First post | 2015-04-14 00:14 -0700 |
| Last post | 2015-04-14 13:03 +0100 |
| Articles | 20 on this page of 297 — 22 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-22 16:13 +0100 |
| Message-ID | <mh8dp0$sq0$1@dont-email.me> |
| In reply to | #60731 |
On 22/04/15 14:31, David Brown wrote:
> On 22/04/15 12:37, Richard Heathfield wrote:
>> On 22/04/15 10:50, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> <snip>
>>>> I've always had a soft-spot for Graham's number, which I think qualifies
>>>> as "seriously large". Not only can you not "represent it using logs",
>>>> but it needs several layers of new notation in order to find a way to
>>>> describe it.
>>>>
>>>> It is the best proven upper bound for the answer to a difficult
>>>> combinatorics problem. But the great thing is that the actual answer to
>>>> the problem is likely to be 6!
>>>
>>> It's always risky using ! for emphasis when talking about
>>> combinatorics!! So, just be clear, you mean 6, of course, not 720.
>>
>> Thank you! I thought he meant 720!!!
>>
>>> But
>>> the lower bound has been improved of late. I think it's 13 now but it's
>>> still a shockingly wide range.
>>
>> A question with a slightly narrower range:
>>
>> What is the largest number that the C language *guarantees* can be
>> represented *exactly* across *all* ISO standards, in a hosted environment?
>>
>> You may use any normal (integer) number base, but hacks are out. By
>> "hacks", I mean named constants (like "Graham's Number"), operators
>> (e.g. "^=integer power: 9^9^9^9^9^9..."), and so on. It's a C puzzle,
>> not a word puzzle.
>>
>> I'll try to set a decent bar, and then let's see if it can be improved.
>>
>> 2.2.4.1 of C89 will appear somewhere in C90 with different numbering,
>> and guarantees us an object of 32767 bytes. We are also guaranteed 127
>> identifiers with block scope declared in one block. So we can use one of
>> those to count the "string", so we don't need a null terminator.
>>
>> 2.2.1 of the same standard gives us a guarantee that we have at least 91
>> different symbols we can use, so we'll work in base 91. So the highest
>> number we can represent is 32767 digits of maximum value (90), giving us
>> an integer equal to 91^32767 - 1, which in base ten is the following
>> 64192-digit number:
>
> I make that 100 symbols (C11 draft N1570, 5.2.1, as that's what I have
> on-hand) - I think you forgot the space and control characters in the
> "basic execution character set". But there could be differences between
> the standards.
One of the few rules I imposed was that the code had to work under all
of the Standards. You are correct that I forgot the space and control
characters, but that actually brings it up to 95, not 100, in C90 at
least (and it has to work under C90 as well as C99 and C11).
>
> C11 also ups the limits to 65535 bytes in an object (for hosted
> environments).
I think it was actually C99 that did that, but in any case such an
object is not guaranteed to exist under C90.
> That brings us to 99...999 (with 131070 nines).
>
> However, I don't see why we can't just have our 65535 bytes (C bytes,
> not necessarily octets) as unsigned chars. That gives us 256 ^ 65535 -
> 1 as the maximum value, with 157824 digits (1014207253....8383538175).
Yes, it was daft of me not to think of that. According to the rules I
imposed, it's actually 256^32767 - 1, which is a 78911-base-ten-digit
number: 6294241083928...275802148180852735
> But that's a rather boring problem, if we only represent numbers
> directly like that. Lets allow our 65KB
32767-byte
"object" to include C source
> code as well (relying only on features of ISO C, of course). Perhaps we
> should say that it must be only C source code. The problem now is not
> to find the biggest number that can be represented (since it's easy to
> spit out ridiculously large numbers of digits),
I would agree that while(1) putchar('9') is not within the spirit of the
game!
> but to find the smallest
> number that /cannot/ be represented.
I assume you're not talking about vastly negative numbers. Rather, you
want the smallest number that can't be represented to be as big as
possible (in the positive direction).
>
> To get started, we should have a limit rather smaller than 65KB. With a
> limit of 46 characters, I think 10 is the limit:
>
> #include <stdio.h>
> int main(void){puts("9");}
To make it a fully legitimate program under all standards, you have to
add return 0; making it 55 characters. But it can't represent 0, so it
doesn't get you very far. Am I right in thinking that you what you are
really asking for is 1 greater than the largest number that /can/ be
represented? This still eliminates while(1)putchar('9').
> Obviously that can be extended with a 10^n - 1 being representable using
> 45+n characters. But when do we beat that?
55+n.
For reference, #include <stdio.h> has 19 characters (including newline),
and int main(void){return 0;} 26 characters (including newline), making
45. So we can take that as a constant, and focus on the function body
(discounting the return), which in your case is puts("9"); for 10
characters over and above the program furniture, or more generally 9+n
for 10^n - 1.
I can beat it at 36 (modulo furniture), at which your program could
display a number one lower than 10^28, using this code:
#include <stdio.h>
unsigned long i;int main(void){while(++i)put("9");return 0;}
and the smallest unrepresentable number (largest representable + 1) is
10^(2^32) because C only guarantees us 32 bits in an unsigned long int.
--
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-22 08:22 -0700 |
| Message-ID | <7c389fca-9cca-4cd6-8b5b-b9eac433edb3@googlegroups.com> |
| In reply to | #60736 |
On Wednesday, April 22, 2015 at 4:13:40 PM UTC+1, Richard Heathfield wrote:
>
> I would agree that while(1) putchar('9') is not within the spirit of the
> game!
>
How about this.
We represent our numbers using Fibonacci notation.
So our first byte is fib 1, 1, our second fib2, also 1, then it
goes 3, 5, 8, 13 ... etc.
A characteristic is than no numbers can be represented by consecutive
ones, because two consecutive ones mean that you set both to zero
and set the next digit.
So we fire up rand(), and emit 1s and zeros, until we get two consecutive ones,
which indicates end of sequence, and we stop.
Does that meet the requirements?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-22 16:25 +0100 |
| Message-ID | <mh8eg2$vra$2@dont-email.me> |
| In reply to | #60738 |
On 22/04/15 16:22, Malcolm McLean wrote:
> On Wednesday, April 22, 2015 at 4:13:40 PM UTC+1, Richard Heathfield wrote:
>>
>> I would agree that while(1) putchar('9') is not within the spirit of the
>> game!
>>
> How about this.
> We represent our numbers using Fibonacci notation.
> So our first byte is fib 1, 1, our second fib2, also 1, then it
> goes 3, 5, 8, 13 ... etc.
>
> A characteristic is than no numbers can be represented by consecutive
> ones, because two consecutive ones mean that you set both to zero
> and set the next digit.
>
> So we fire up rand(), and emit 1s and zeros, until we get two consecutive ones,
> which indicates end of sequence, and we stop.
> Does that meet the requirements?
Firstly, which game are you playing, mine or David's?
If you're playing my game, no. If you're playing David's, what is the
smallest number your program cannot represent?
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-22 10:35 -0700 |
| Message-ID | <87wq14jcbq.fsf@kst-u.example.com> |
| In reply to | #60736 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 22/04/15 14:31, David Brown wrote:
[...]
>> #include <stdio.h>
>> int main(void){puts("9");}
>
> To make it a fully legitimate program under all standards, you have to
> add return 0; making it 55 characters.
[...]
That depends on what you mean by "legitimate" (a term the standard
doesn't define). In C90, falling off the end of main() causes the
termination status returned to the host environment to be undefined.
(I think calling it "unspecified" rather than "undefined" would
have been clearer and more accurate.) The behavior of the program
is not undefined, only its termination status. It still produces
the required output, assuming a properly running conforming hosted
implementation.
--
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 | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-22 13:24 -0500 |
| Message-ID | <mh8ovf$fca$1@dont-email.me> |
| In reply to | #60736 |
On 4/22/2015 10:13 AM, Richard Heathfield wrote:
> On 22/04/15 14:31, David Brown wrote:
>> To get started, we should have a limit rather smaller than 65KB. With a
>> limit of 46 characters, I think 10 is the limit:
>>
>> #include <stdio.h>
>> int main(void){puts("9");}
>
> To make it a fully legitimate program under all standards, you have to
> add return 0; making it 55 characters. But it can't represent 0, so it
> doesn't get you very far. Am I right in thinking that you what you are
> really asking for is 1 greater than the largest number that /can/ be
> represented? This still eliminates while(1)putchar('9').
I think what he's asking for is the smallest natural number that can't
be placed on the standard output stream using a base 10 representation.
(With your restrictions on having it work for all conformant hosted
implementations of any of the C standards).
(I know he didn't mention a particular radix notation, but there needs
to be one to make it interesting. Otherwise, the following could
represent any natural number greater than 1. You could instead require
that bases other than base-10 be explicit.)
#include <stdio.h>
int main(void){puts("10");return 0;}
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-23 01:18 +0200 |
| Message-ID | <mh9a6o$o5s$1@dont-email.me> |
| In reply to | #60736 |
On 22/04/15 17:13, Richard Heathfield wrote:
> On 22/04/15 14:31, David Brown wrote:
>> But that's a rather boring problem, if we only represent numbers
>> directly like that. Lets allow our 65KB
>
> 32767-byte
>
> "object" to include C source
>> code as well (relying only on features of ISO C, of course). Perhaps we
>> should say that it must be only C source code. The problem now is not
>> to find the biggest number that can be represented (since it's easy to
>> spit out ridiculously large numbers of digits),
>
> I would agree that while(1) putchar('9') is not within the spirit of the
> game!
>
>> but to find the smallest
>> number that /cannot/ be represented.
>
> I assume you're not talking about vastly negative numbers. Rather, you
> want the smallest number that can't be represented to be as big as
> possible (in the positive direction).
Yes.
>
>>
>> To get started, we should have a limit rather smaller than 65KB. With a
>> limit of 46 characters, I think 10 is the limit:
>>
>> #include <stdio.h>
>> int main(void){puts("9");}
>
> To make it a fully legitimate program under all standards, you have to
> add return 0; making it 55 characters. But it can't represent 0, so it
> doesn't get you very far. Am I right in thinking that you what you are
> really asking for is 1 greater than the largest number that /can/ be
> represented? This still eliminates while(1)putchar('9').
>
>> Obviously that can be extended with a 10^n - 1 being representable using
>> 45+n characters. But when do we beat that?
>
> 55+n.
>
> For reference, #include <stdio.h> has 19 characters (including newline),
> and int main(void){return 0;} 26 characters (including newline), making
> 45. So we can take that as a constant, and focus on the function body
> (discounting the return), which in your case is puts("9"); for 10
> characters over and above the program furniture, or more generally 9+n
> for 10^n - 1.
>
I agree about the "modulo furniture", just to keep things easier and
avoid getting bogged down in the details of how "main" can be defined
(arguably that's more on topic for this newsgroup, and an interesting
challenge to some people). Maybe we can think of another metric rather
than character counts, such as counting tokens in some way, and ignoring
white space - then we can keep the code more readable :-)
> I can beat it at 36 (modulo furniture), at which your program could
> display a number one lower than 10^28, using this code:
>
> #include <stdio.h>
> unsigned long i;int main(void){while(++i)put("9");return 0;}
>
> and the smallest unrepresentable number (largest representable + 1) is
> 10^(2^32) because C only guarantees us 32 bits in an unsigned long int.
>
No, all you have done there is generate a single large number -
10^(2^32) - 1. But how would you generate 10^(2^32) - 2 with the same
size of source code? Or 10^27? (Numbers under 10^27 can be written
with simple puts in 36 characters.)
With 40 characters we can do all numbers up to 10^31 in the same way,
and also 10^31 - that is the stage at which compression (in this format)
becomes helpful:
int i=31;int main(void){puts("1");while(i--)puts("0");return 0;}
However, since posing the question, I've read a little from the modern
library of Alexandria:
<http://en.wikipedia.org/wiki/Kolmogorov_complexity>
It turns out that this is actually going to be a very boring problem,
because few numbers are compressible in this way.
Ah well, this thread was getting too long anyway.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-23 06:11 +0100 |
| Message-ID | <mh9usv$cgh$1@dont-email.me> |
| In reply to | #60828 |
On 23/04/15 00:18, David Brown wrote: > > However, since posing the question, I've read a little from the modern > library of Alexandria: > > <http://en.wikipedia.org/wiki/Kolmogorov_complexity> > > > It turns out that this is actually going to be a very boring problem, > because few numbers are compressible in this way. > > Ah well, this thread was getting too long anyway. What was the shortest length at which it was too long? -- 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-23 09:36 +0200 |
| Message-ID | <mha7cr$4in$2@dont-email.me> |
| In reply to | #60839 |
On 23/04/15 07:11, Richard Heathfield wrote: > On 23/04/15 00:18, David Brown wrote: > >> >> However, since posing the question, I've read a little from the modern >> library of Alexandria: >> >> <http://en.wikipedia.org/wiki/Kolmogorov_complexity> >> >> >> It turns out that this is actually going to be a very boring problem, >> because few numbers are compressible in this way. >> >> Ah well, this thread was getting too long anyway. > > > What was the shortest length at which it was too long? > That would be 8 levels up the tree, when the full tree width was last visible in Thunderbird on my computer with the column widths I had been using previously.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-22 08:38 -0700 |
| Message-ID | <87pp6wkwb6.fsf@kst-u.example.com> |
| In reply to | #60731 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> But that's a rather boring problem, if we only represent numbers
> directly like that. Lets allow our 65KB "object" to include C source
> code as well (relying only on features of ISO C, of course). Perhaps we
> should say that it must be only C source code. The problem now is not
> to find the biggest number that can be represented (since it's easy to
> spit out ridiculously large numbers of digits), but to find the smallest
> number that /cannot/ be represented.
>
> To get started, we should have a limit rather smaller than 65KB. With a
> limit of 46 characters, I think 10 is the limit:
>
> #include <stdio.h>
> int main(void){puts("9");}
>
> Obviously that can be extended with a 10^n - 1 being representable using
> 45+n characters. But when do we beat that?
Sticking to 46 characters, the space between #include and <stdio.h> is
optional:
#include<stdio.h>
int main(void){puts("99");}
And arguably we can do this:
#include<stdio.h>
int main(){puts("999999");}
A very strict reading of the standard implies (to me at least) that
`int main()` has undefined behavior, but it's very likely that it's
intended to be permitted and well defined. With that assumption,
this is the best I can do in C99 and C11:
int puts();int main(){puts("9999999999999");}
If we allow C90:
main(){puts("9999999999999999999999999999");}
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-22 13:04 +0200 |
| Message-ID | <mh7v5n$2jp$1@dont-email.me> |
| In reply to | #60715 |
On 22/04/15 11:50, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > <snip> >> I've always had a soft-spot for Graham's number, which I think qualifies >> as "seriously large". Not only can you not "represent it using logs", >> but it needs several layers of new notation in order to find a way to >> describe it. >> >> It is the best proven upper bound for the answer to a difficult >> combinatorics problem. But the great thing is that the actual answer to >> the problem is likely to be 6! > > It's always risky using ! for emphasis when talking about > combinatorics!! So, just be clear, you mean 6, of course, not 720. Yes, I meant $6$! and not $6!$. But it's a good point. > But > the lower bound has been improved of late. I think it's 13 now but it's > still a shockingly wide range. > Great, now I'm going to have to look for a new edition of "The Dictionary of Curious and Interesting Numbers" (Graham's number is the last entry). I hope they've updated it with this breakthrough.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-22 09:52 -0500 |
| Message-ID | <mh8chf$no5$1@dont-email.me> |
| In reply to | #60693 |
On 4/21/2015 6:58 PM, Malcolm McLean wrote: > On Tuesday, April 21, 2015 at 8:44:26 PM UTC+1, Martin Shobe wrote: >> On 4/21/2015 12:13 PM, Malcolm McLean wrote: >>> Now we've also got to assume that the point at which the PDF goes >>> to "negligible" is also representable using logs. >> What would it mean that a point is representable using logs? Why would >> we have to assume it? You don't appear to use that (whatever that is) >> anywhere. > Let's say we get a much text as there are atoms in the universe. > 10^82 bytes. So if we grow a buffer by repeated multiplication by > ten, only 82 steps - hardly a challenge, it's even doable if we must > ask for the sizes by hand. > But if we get seriously large numbers, such that we can't write down > the logarithm, we're in trouble. If something is growing for N steps, > super-exponentially, we can't hope to find it by repeatedly asking > "too high?" "too low?" and multiplying by a factor. Like the Cantor dust, the only purpose it's serving is to increase the number of technical terms. It otherwise has no bearing to the problem at hand. Now what about the other questions I asked? Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-22 16:23 +0100 |
| Message-ID | <mh8ebl$vra$1@dont-email.me> |
| In reply to | #60735 |
On 22/04/15 16:16, Malcolm McLean wrote: <snip> > When numbers get seriously large, you can't represent them exactly. > For practical purposes, that means above about 1000 - there's seldom > much point in giving more than three significant figures to a human. Malcolm, if you want to discuss this in more detail, you can reach me on my mobile: 07 500 000 000. > So in science we resort to logs > > 1.23 e10 That's 180 degrees away from being a log. <snip> -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-22 10:28 -0700 |
| Message-ID | <874mo8kr79.fsf@kst-u.example.com> |
| In reply to | #60739 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 22/04/15 16:16, Malcolm McLean wrote:
>
> <snip>
>
>> When numbers get seriously large, you can't represent them exactly.
>> For practical purposes, that means above about 1000 - there's seldom
>> much point in giving more than three significant figures to a human.
>
> Malcolm, if you want to discuss this in more detail, you can reach me
> on my mobile: 07 500 000 000.
>
>> So in science we resort to logs
>>
>> 1.23 e10
>
> That's 180 degrees away from being a log.
>
> <snip>
Not really. In the C floating-point constant 1.23e10, for example, 10
is the (base-10) logarithm of the value that's multiplied by 1.23 to
give the value of the constant.
--
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-22 08:16 -0700 |
| Message-ID | <b318e939-6dfb-4f02-9247-3678d8e309ff@googlegroups.com> |
| In reply to | #60735 |
On Wednesday, April 22, 2015 at 3:52:37 PM UTC+1, Martin Shobe wrote: > On 4/21/2015 6:58 PM, Malcolm McLean wrote: > > On Tuesday, April 21, 2015 at 8:44:26 PM UTC+1, Martin Shobe wrote: > >> On 4/21/2015 12:13 PM, Malcolm McLean wrote: > >>> Now we've also got to assume that the point at which the PDF goes > >>> to "negligible" is also representable using logs. > > >> What would it mean that a point is representable using logs? Why would > >> we have to assume it? You don't appear to use that (whatever that is) > >> anywhere. > > > Let's say we get a much text as there are atoms in the universe. > > 10^82 bytes. So if we grow a buffer by repeated multiplication by > > ten, only 82 steps - hardly a challenge, it's even doable if we must > > ask for the sizes by hand. > > > But if we get seriously large numbers, such that we can't write down > > the logarithm, we're in trouble. If something is growing for N steps, > > super-exponentially, we can't hope to find it by repeatedly asking > > "too high?" "too low?" and multiplying by a factor. > > Like the Cantor dust, the only purpose it's serving is to increase the > number of technical terms. It otherwise has no bearing to the problem at > hand. Now what about the other questions I asked? > > Martin Shobe Martin: >What would it mean that a point is representable using logs? Why would >we have to assume it? You don't appear to use that (whatever that is) >anywhere. When numbers get seriously large, you can't represent them exactly. For practical purposes, that means above about 1000 - there's seldom much point in giving more than three significant figures to a human. So in science we resort to logs 1.23 e10 and so on. That's fine, until the number after the e becomes unrepresentable (so it goes above 1000, in human terms). But it's very rare to want to express an number above 1.00 e1000. But eventually our x.xx exxx system will break down, because infinity is infinity. There's no limit on how high a real number can go. Malcolm > Another thing we've got assume is that there > is such a point. Martin > Again, why? You don't appear to use that anywhere. We're chasing an unbounded point, using exponential growth. We have to know that the process will terminate in "representable steps". There's a wonderful book called On, Two, Three Infinity which explains what happens as numbers get very large. > Malcolm > So my question was, is there a pathological PDF such that we can't say that it > becomes negligible as x approaches infinity? > Martin > Yes >
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-22 13:53 -0500 |
| Message-ID | <mh8qlc$m75$1@dont-email.me> |
| In reply to | #60740 |
On 4/22/2015 10:16 AM, Malcolm McLean wrote: > On Wednesday, April 22, 2015 at 3:52:37 PM UTC+1, Martin Shobe wrote: >> On 4/21/2015 6:58 PM, Malcolm McLean wrote: >>> On Tuesday, April 21, 2015 at 8:44:26 PM UTC+1, Martin Shobe wrote: >>>> On 4/21/2015 12:13 PM, Malcolm McLean wrote: >>>>> Now we've also got to assume that the point at which the PDF goes >>>>> to "negligible" is also representable using logs. >> >>>> What would it mean that a point is representable using logs? Why would >>>> we have to assume it? You don't appear to use that (whatever that is) >>>> anywhere. >> >>> Let's say we get a much text as there are atoms in the universe. >>> 10^82 bytes. So if we grow a buffer by repeated multiplication by >>> ten, only 82 steps - hardly a challenge, it's even doable if we must >>> ask for the sizes by hand. >> >>> But if we get seriously large numbers, such that we can't write down >>> the logarithm, we're in trouble. If something is growing for N steps, >>> super-exponentially, we can't hope to find it by repeatedly asking >>> "too high?" "too low?" and multiplying by a factor. >> >> Like the Cantor dust, the only purpose it's serving is to increase the >> number of technical terms. It otherwise has no bearing to the problem at >> hand. Now what about the other questions I asked? >> >> Martin Shobe > > Martin: > >> What would it mean that a point is representable using logs? Why would >> we have to assume it? You don't appear to use that (whatever that is) >> anywhere. > > When numbers get seriously large, you can't represent them exactly. > For practical purposes, that means above about 1000 - there's seldom > much point in giving more than three significant figures to a human. > > So in science we resort to logs > > 1.23 e10 > > and so on. > > That's fine, until the number after the e becomes unrepresentable > (so it goes above 1000, in human terms). But it's very rare to > want to express an number above 1.00 e1000. > > But eventually our x.xx exxx system will break down, because > infinity is infinity. There's no limit on how high a real number can > go. None of that is relevant. > > Malcolm >> Another thing we've got assume is that there >> is such a point. > > Martin >> Again, why? You don't appear to use that anywhere. > > We're chasing an unbounded point, using exponential growth. > We have to know that the process will terminate in "representable > steps". > There's a wonderful book called On, Two, Three Infinity which > explains what happens as numbers get very large. None of that is relevant to what we've been discussing. In any case, you don't need to know if it will terminate in "representable steps". We only care about representation if we have to represent the number of steps. Even if we find that we can't represent the number of steps, it will still either terminate or not and if it terminates, there will still be a number of steps in which it will terminate. Now what about the other questions? The ones about what x was, what you had 8, 32, and 64 of, which standard deviation you were referring to, etc. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-22 12:45 -0700 |
| Message-ID | <14a7f808-3c8b-4a7f-9065-255b2bc6c43e@googlegroups.com> |
| In reply to | #60778 |
On Wednesday, April 22, 2015 at 7:53:37 PM UTC+1, Martin Shobe wrote: > On 4/22/2015 10:16 AM, Malcolm McLean wrote: > > On Wednesday, April 22, 2015 at 3:52:37 PM UTC+1, Martin Shobe wrote: > >> On 4/21/2015 6:58 PM, Malcolm McLean wrote: > >>> On Tuesday, April 21, 2015 at 8:44:26 PM UTC+1, Martin Shobe wrote: > >>>> On 4/21/2015 12:13 PM, Malcolm McLean wrote: > >>>>> Now we've also got to assume that the point at which the PDF goes > >>>>> to "negligible" is also representable using logs. > >> > >>>> What would it mean that a point is representable using logs? Why would > >>>> we have to assume it? You don't appear to use that (whatever that is) > >>>> anywhere. > >> > >>> Let's say we get a much text as there are atoms in the universe. > >>> 10^82 bytes. So if we grow a buffer by repeated multiplication by > >>> ten, only 82 steps - hardly a challenge, it's even doable if we must > >>> ask for the sizes by hand. > >> > >>> But if we get seriously large numbers, such that we can't write down > >>> the logarithm, we're in trouble. If something is growing for N steps, > >>> super-exponentially, we can't hope to find it by repeatedly asking > >>> "too high?" "too low?" and multiplying by a factor. > >> > >> Like the Cantor dust, the only purpose it's serving is to increase the > >> number of technical terms. It otherwise has no bearing to the problem at > >> hand. Now what about the other questions I asked? > >> > >> Martin Shobe > > > > Martin: > > > >> What would it mean that a point is representable using logs? Why would > >> we have to assume it? You don't appear to use that (whatever that is) > >> anywhere. > > > > When numbers get seriously large, you can't represent them exactly. > > For practical purposes, that means above about 1000 - there's seldom > > much point in giving more than three significant figures to a human. > > > > So in science we resort to logs > > > > 1.23 e10 > > > > and so on. > > > > That's fine, until the number after the e becomes unrepresentable > > (so it goes above 1000, in human terms). But it's very rare to > > want to express an number above 1.00 e1000. > > > > But eventually our x.xx exxx system will break down, because > > infinity is infinity. There's no limit on how high a real number can > > go. > > None of that is relevant. > > > > > Malcolm > >> Another thing we've got assume is that there > >> is such a point. > > > > Martin > >> Again, why? You don't appear to use that anywhere. > > > > We're chasing an unbounded point, using exponential growth. > > We have to know that the process will terminate in "representable > > steps". > > There's a wonderful book called On, Two, Three Infinity which > > explains what happens as numbers get very large. > > None of that is relevant to what we've been discussing. In any case, you > don't need to know if it will terminate in "representable steps". We > only care about representation if we have to represent the number of > steps. Even if we find that we can't represent the number of steps, it > will still either terminate or not and if it terminates, there will > still be a number of steps in which it will terminate. > When numbers get really big you don't reduce the size of the number in any meaningful way by taking its logarithm. You need to read the book.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-22 16:44 -0500 |
| Message-ID | <mh94lu$1o5$1@dont-email.me> |
| In reply to | #60783 |
On 4/22/2015 2:45 PM, Malcolm McLean wrote: > On Wednesday, April 22, 2015 at 7:53:37 PM UTC+1, Martin Shobe wrote: >> On 4/22/2015 10:16 AM, Malcolm McLean wrote: >>> On Wednesday, April 22, 2015 at 3:52:37 PM UTC+1, Martin Shobe wrote: >>>> On 4/21/2015 6:58 PM, Malcolm McLean wrote: >>>>> On Tuesday, April 21, 2015 at 8:44:26 PM UTC+1, Martin Shobe wrote: >>>>>> On 4/21/2015 12:13 PM, Malcolm McLean wrote: >>>>>>> Now we've also got to assume that the point at which the PDF goes >>>>>>> to "negligible" is also representable using logs. >>>> >>>>>> What would it mean that a point is representable using logs? Why would >>>>>> we have to assume it? You don't appear to use that (whatever that is) >>>>>> anywhere. >>>> >>>>> Let's say we get a much text as there are atoms in the universe. >>>>> 10^82 bytes. So if we grow a buffer by repeated multiplication by >>>>> ten, only 82 steps - hardly a challenge, it's even doable if we must >>>>> ask for the sizes by hand. >>>> >>>>> But if we get seriously large numbers, such that we can't write down >>>>> the logarithm, we're in trouble. If something is growing for N steps, >>>>> super-exponentially, we can't hope to find it by repeatedly asking >>>>> "too high?" "too low?" and multiplying by a factor. >>>> >>>> Like the Cantor dust, the only purpose it's serving is to increase the >>>> number of technical terms. It otherwise has no bearing to the problem at >>>> hand. Now what about the other questions I asked? >>>> >>>> Martin Shobe >>> >>> Martin: >>> >>>> What would it mean that a point is representable using logs? Why would >>>> we have to assume it? You don't appear to use that (whatever that is) >>>> anywhere. >>> >>> When numbers get seriously large, you can't represent them exactly. >>> For practical purposes, that means above about 1000 - there's seldom >>> much point in giving more than three significant figures to a human. >>> >>> So in science we resort to logs >>> >>> 1.23 e10 >>> >>> and so on. >>> >>> That's fine, until the number after the e becomes unrepresentable >>> (so it goes above 1000, in human terms). But it's very rare to >>> want to express an number above 1.00 e1000. >>> >>> But eventually our x.xx exxx system will break down, because >>> infinity is infinity. There's no limit on how high a real number can >>> go. >> >> None of that is relevant. >> >>> >>> Malcolm >>>> Another thing we've got assume is that there >>>> is such a point. >>> >>> Martin >>>> Again, why? You don't appear to use that anywhere. >>> >>> We're chasing an unbounded point, using exponential growth. >>> We have to know that the process will terminate in "representable >>> steps". >>> There's a wonderful book called On, Two, Three Infinity which >>> explains what happens as numbers get very large. >> >> None of that is relevant to what we've been discussing. In any case, you >> don't need to know if it will terminate in "representable steps". We >> only care about representation if we have to represent the number of >> steps. Even if we find that we can't represent the number of steps, it >> will still either terminate or not and if it terminates, there will >> still be a number of steps in which it will terminate. >> > When numbers get really big you don't reduce the size of the number > in any meaningful way by taking its logarithm. > You need to read the book. In any meaningful way? That is a flat-out falsehood. If that's representative of its quality, reading it would be a waste of time. (Note: I'm not saying that reading it is a waste of time, you've had some issues recently when it comes to understanding what others have said here. I suspect that this is similar.) It's also not relevant to what we've been discussing. (And I noticed you've snipped the other questions.) Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-21 22:58 +0100 |
| Message-ID | <87fv7tcdpm.fsf@bsb.me.uk> |
| In reply to | #60662 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Tuesday, April 21, 2015 at 5:09:10 PM UTC+1, Martin Shobe wrote: >> On 4/21/2015 9:31 AM, Malcolm McLean wrote: >> >> Your "understanding" how linguistically competent adult >> speakers communicate with each other appears to be interfering with your >> ability to understand what people are telling you. You can have a PDF >> over Cantor dust. You can have a PDF over [0,1]^n that is non-zero only >> at points in the Cantor dust set. However, Cantor dust is not even a >> function, let alone a PDF. >> > So what does the Chinese hat mean? That you like tired old stereotypes? <snip> > So my question was, is there a pathological PDF such that we can't say > that it becomes negligible as x approaches infinity? I floated the > idea of a Cantor dust function as such a possibility - lots of points, > all of infinitesimal width, but an infinite number of them, scatted > chaotically over the whole interval 0 to infinity. It appears that not > only is that physically impossible, it doesn't make any mathematical > sense either. That was the question. It would have been better to ask it then. The Cantor set is a red herring -- doubly so: it's both bounded and has zero measure. It's just another land mine you've laid in the path to understanding what you are going on about. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-22 09:53 +0200 |
| Message-ID | <mh7k0n$q0h$1@dont-email.me> |
| In reply to | #60662 |
On 21/04/15 19:13, Malcolm McLean wrote: > On Tuesday, April 21, 2015 at 5:09:10 PM UTC+1, Martin Shobe wrote: >> On 4/21/2015 9:31 AM, Malcolm McLean wrote: >> >> Your "understanding" how linguistically competent adult >> speakers communicate with each other appears to be interfering with your >> ability to understand what people are telling you. You can have a PDF >> over Cantor dust. You can have a PDF over [0,1]^n that is non-zero only >> at points in the Cantor dust set. However, Cantor dust is not even a >> function, let alone a PDF. >> > So what does the Chinese hat mean? > > The issue is that any search that starts from zero is predicated on the supposition > that the PDF goes to zero as it approaches infinity. So if our PDF is a Gaussian, > there is no point at which is is zero, it's positive for any value. But it gets very > low after 3 standard deviations, and very low indeed after five. So let's say our > search function is O(2^x). If 8 is acceptable, 32 barely doable, and 64 catastrophic, > that's likely OK, we've got to take a huge number of samples before we'll get even > one with an sd of six. > Now we've also got to assume that the point at which the PDF goes to "negligible" > is also representable using logs. Another thing we've got assume is that there > is such a point. > So my question was, is there a pathological PDF such that we can't say that it > becomes negligible as x approaches infinity? I floated the idea of a Cantor dust > function as such a possibility - lots of points, all of infinitesimal width, but > an infinite number of them, scatted chaotically over the whole interval 0 to > infinity. It appears that not only is that physically impossible, it doesn't make > any mathematical sense either. > That was the question. > Here's an problem for you to solve, Malcolm. An enemy takes a selection of topics and phrases from a variety of maths books on completely unrelated topics, and puts these in a bag. He then draws a dozen of them out at random, mixes in a selection of numbers found by rolling dice, and scatters mathematically empty phrases like "very low", "barely doable" and "negligible" between some of the terms. Finally he uses his well-developed language skills to fill it all out into a few grammatically correct paragraphs. The challenge is to find the best strategy for persuading the enemy that they are not making sense.
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2015-04-21 10:15 -0700 |
| Message-ID | <ce2f2d1b-e6e3-440e-886c-ff7f9d1ef04d@googlegroups.com> |
| In reply to | #60659 |
On Tuesday, April 21, 2015 at 5:09:10 PM UTC+1, Martin Shobe wrote: > Your "understanding" how linguistically competent adult > speakers communicate with each other appears to be interfering with your > ability to understand what people are telling you. You can have a PDF > over Cantor dust. Can you? It'd have to be a seriously weird one though. It's easy to think of a discrete distribution on a countable set, and it's easy to think of a distribution on a set with measure (a traditional PDF), but an uncountable set of measure zero... How do you set it up so it CDF sums/integrates to 1?
[toc] | [prev] | [next] | [standalone]
Page 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web