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 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-15 01:32 -0700 |
| Message-ID | <81adfa15-9a4f-4d3a-8113-61240f04bdd6@googlegroups.com> |
| In reply to | #60067 |
On Wednesday, April 15, 2015 at 1:20:34 AM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Tuesday, April 14, 2015 at 8:52:31 PM UTC+1, Johannes Bauer wrote:
> >> On 14.04.2015 21:43, Malcolm McLean wrote:
> >>
> >> >>>> int f(long long int x){
> >> >>>> return x!=6839003422641637678;
> >> >>>> }
> >> >>>>
> >> >>> You can't minimise a golf course function. (That's one with a
> >> >>> flat area and a tiny
> >> >>> minimum).
> >> >>
> >> >> Clearly one can. However, as in so many of your threads, your words are
> >> >> no doubt to be interpreted with all the extra words added in to make
> >> >> what you are saying something correct.
> >> >
> >> > The meaning is defined by the natural language of the words.
> >>
> >> So then can I assume that by you "can't minimise" a function you mean
> >> that I can't write this:
> >>
> >> void minimize_unminimizable(void) {
> >> for (long long int i = 0; i < LLONG_MAX; i++) {
> >> if (f(i) == 0) {
> >> printf("Minimum: %lld\n", i);
> >> }
> >> }
> >> }
> >>
> >> That would be a very peculiar natural language meaning of the word
> >> "can't" because for something that I "can't" do I sure as hell just did.
> >>
> > It wouldn't be an unusual use of natural language.
> >
> > I said "a golf course function". Add a dimension.
>
> (1) So you placed that comment after an exampled of a one-argument
> function in a thread about minimising one-argument functions, but you
> did not intend your words to be interpreted as referring to one-argument
> functions? Would you agree that that is, at best, rather deceptive?
>
> (2) Are you claiming that Johannes Bauer's example code can not be
> extended to functions of more than one argument?
>
It's a case of understanding how linguistically competent adult
speakers communicate with each other.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-15 08:17 -0700 |
| Message-ID | <87lhhts9ob.fsf@kst-u.example.com> |
| In reply to | #60075 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
>> >> On 14.04.2015 21:43, Malcolm McLean wrote:
[...]
>> >> >>> You can't minimise a golf course function. (That's one with a
>> >> >>> flat area and a tiny
>> >> >>> minimum).
[...]
>> >> > The meaning is defined by the natural language of the words.
[...]
>> > It wouldn't be an unusual use of natural language.
>> >
>> > I said "a golf course function". Add a dimension.
[...]
> It's a case of understanding how linguistically competent adult
> speakers communicate with each other.
Malcolm, if other people repeatedly fail to understand what I'm talking
about, I usually consider the possibility that it's because I'm being
unclear.
--
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 09:13 -0700 |
| Message-ID | <ee0a8a6a-5815-45e6-9cc0-5ad7aa42d056@googlegroups.com> |
| In reply to | #60083 |
On Wednesday, April 15, 2015 at 4:17:33 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Malcolm, if other people repeatedly fail to understand what I'm talking > about, I usually consider the possibility that it's because I'm being > unclear. > But I'm not being unclear. These are fairly simple ideas. Data means something. Values tend to cluster towards the low end of the possible range. If we want to find a value, we need to bias our search to the low range, but not by so much that we'll take too long to find a high value. The Fibonnacci sequence goes 0, 1, 1, 2, 3, 5, 8, 13 ... Ignoring for a moment the theoretical difficulty of the two ones, you can see that it starts out linear, then becomes exponential. Or, if we approximate it as Phi^x, we can see that Phi is roughly intermediate between 1 and e. So if you don't know if you're probing something which is linear or exponential, it's a compromise. Replace the second 1 with 1 plus epsilon, and you have quite a nice strategy for probing something you know next to nothing about.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-04-15 18:33 +0200 |
| Message-ID | <mgm3t5$oig$1@news.albasani.net> |
| In reply to | #60087 |
On 15.04.2015 18:13, Malcolm McLean wrote: > On Wednesday, April 15, 2015 at 4:17:33 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Malcolm, if other people repeatedly fail to understand what I'm talking >> about, I usually consider the possibility that it's because I'm being >> unclear. >> > But I'm not being unclear. No you're being flat out *wrong* and instead of doing what (linguistically competent) adults would do, you try to cover up your mistakes and weasel of of responsibility. Instead of simply saying "yeah, sorry, wrong about this". > The Fibonnacci sequence goes 0, 1, 1, 2, 3, 5, 8, 13 ... Ignoring for a moment the theoretical > difficulty of the two ones, you can see that it starts out linear, then becomes exponential. So the Fibonnaci sequence "starts out linear"? That is like saying that the sinus function is a linear function because for x close to 0 it's a reasonable approximation. But it's still wrong. The Fibonnaci sequence is a exponential sequence, there's no question about it. You claiming it "starts out linear" is as wrong as me saying that it "starts out constant" until it "turns quadratic" to finally "become exponential". It's nonsense. > Or, if we approximate it as Phi^x, we can see that Phi is roughly intermediate between 1 > and e. So if you don't know if you're probing something which is linear or exponential, it's > a compromise. Replace the second 1 with 1 plus epsilon, and you have quite a nice > strategy for probing something you know next to nothing about. Very poor argument for choosing phi as the exponential base for probing. Essentially all your evidence is that it's somewhere halfway between 1 and e. Cool beans, but why would that be impressive? Why don't you choose a number that is halfway between 0 and Pi and take that? How come the midpoint of 1 and e is - according to you - especially well suited to probe something unknown? It isn't. And you can't back your claims up, not even with empirical data. It's just nonsense that you pile on top of other nonsense. Anyone who points it out is just "linguistically incompetent" according to your implication. That's pretty pathetic scientific standards, let me tell you. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-15 10:02 -0700 |
| Message-ID | <54ff1990-9ee7-42d7-8a13-cd680cd8b0ab@googlegroups.com> |
| In reply to | #60090 |
On Wednesday, April 15, 2015 at 5:33:49 PM UTC+1, Johannes Bauer wrote: > On 15.04.2015 18:13, Malcolm McLean wrote: > > On Wednesday, April 15, 2015 at 4:17:33 PM UTC+1, Keith Thompson wrote: > > > The Fibonnacci sequence goes 0, 1, 1, 2, 3, 5, 8, 13 ... Ignoring for a moment the theoretical > > difficulty of the two ones, you can see that it starts out linear, then becomes exponential. > > So the Fibonnaci sequence "starts out linear"? That is like saying that > the sinus function is a linear function because for x close to 0 it's a > reasonable approximation. > Ignore the two ones. 0, 1, 2, 3 ... a step of one, a step of one, a step of one, that's linear. it then converges on an exponential function at the higher end. > > Very poor argument for choosing phi as the exponential base for probing. > Essentially all your evidence is that it's somewhere halfway between 1 > and e. Cool beans, but why would that be impressive? > Choosing e gives us a nice curve. Choosing one gives us a flat line. So we want something midway between the two. It would be nice if we applied a golden section search to the interval 1, e we got Phi, but we don't. We do get something fairly close. We're on the right lines with 1.6 or so. > > Why don't you choose a number that is halfway between 0 and Pi and take > that? How come the midpoint of 1 and e is - according to you - > especially well suited to probe something unknown? > exponentials and e like each other. You can of course raise PI to a power, but it's not especially interesting if you do that. > > It isn't. And you can't back your claims up, not even with empirical > data. It's just nonsense that you pile on top of other nonsense. Anyone > who points it out is just "linguistically incompetent" according to your > implication. > We hear claims that it's nonsense. I said "you can't minimise a golf course function" in response to Bart's objection. That's "nonsense" according to some people. That's linguistic incompetence. Kenny regularly makes the same point. > > That's pretty pathetic scientific standards, let me tell you. > No, it's an explanation of how to characterise things you don't know much about. If you're not a scientist, or not the right kind of scientist, it's not something you'll ever have to do. If you're a mathematician, you'll probably regard what I say as absurdly simplistic and irrelevant to real mathematics. But if you've got data points and you want to understand where to sample to understand the underlying processes which generate them, you'll see the sense.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-04-15 20:55 +0200 |
| Message-ID | <mgmc7s$885$1@news.albasani.net> |
| In reply to | #60092 |
On 15.04.2015 19:02, Malcolm McLean wrote: > Ignore the two ones. > 0, 1, 2, 3 ... a step of one, a step of one, a step of one, that's linear. > it then converges on an exponential function at the higher end. Yes, if you cherrypick X-values of any sequence you can draw conclusions. Just like exp(0.000) = 1 exp(0.693) \approx 2 exp(1.099) \approx 3 exp(1.386) \approx 4 You can clearly see the exp() function is linear at first but it then becomes a exponential function at the higher end. Does it sound ridiculous yet? I surely hope so. >> Very poor argument for choosing phi as the exponential base for probing. >> Essentially all your evidence is that it's somewhere halfway between 1 >> and e. Cool beans, but why would that be impressive? >> > Choosing e gives us a nice curve. > Choosing one gives us a flat line. Choosing Pi gives us a nice curve. Choosing one gives us a flat line. Thus the conclusion is, use Pi/2 as the base. > exponentials and e like each other. You can of course raise PI to a power, > but it's not especially interesting if you do that. Sure, magically (without explanation) your choice is superior to mine, the only evidence being that "e gives a nice curve". Seriously? > We hear claims that it's nonsense. I said "you can't minimise a golf > course function" in response to Bart's objection. That's "nonsense" according to > some people. That's linguistic incompetence. Kenny regularly makes the > same point. You not only heared claims it's nonsense, I even outright did prove you wrong in that I presented a way to minimize the gold-course function that YOU provided. I therefore provided EVIDENCE that it's nonsense. Then you claimed that the function you provided wasn't a golf-course function after all. >> That's pretty pathetic scientific standards, let me tell you. >> > No, it's an explanation of how to characterise things you don't know much about. > If you're not a scientist, or not the right kind of scientist, it's not something > you'll ever have to do. Funny that you would say that because it just so happens that I *am* a scientist. And that kind of "hear what I mean, not what I say" kind of attitude is what makes me go up a wall precisely *because* I am a scientist. When taking about stuff in a scientific manner I expect people to be precise and sharp in their expressions. I do work in the field of applied cryptography. Regularly people will say things like "we need to encrypt a certificate" or the likes. And later claim that - well OF COURSE they didn't mean the certificate but rather the private key that corresponds to the public key embedded in the certificate. Then just say so, please. > But if you've > got data points and you want to understand where to sample to understand > the underlying processes which generate them, you'll see the sense. The only thing I see is sloppiness and weak excuses for said sloppiness. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-04-15 19:27 -0500 |
| Message-ID | <bd0uiap9lknq668o22oh73hn4vmv1cvr41@4ax.com> |
| In reply to | #60092 |
On Wed, 15 Apr 2015 10:02:18 -0700 (PDT), Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Wednesday, April 15, 2015 at 5:33:49 PM UTC+1, Johannes Bauer wrote: >> On 15.04.2015 18:13, Malcolm McLean wrote: >> > On Wednesday, April 15, 2015 at 4:17:33 PM UTC+1, Keith Thompson wrote: >> >> > The Fibonnacci sequence goes 0, 1, 1, 2, 3, 5, 8, 13 ... Ignoring for a moment the theoretical >> > difficulty of the two ones, you can see that it starts out linear, then becomes exponential. >> >> So the Fibonnaci sequence "starts out linear"? That is like saying that >> the sinus function is a linear function because for x close to 0 it's a >> reasonable approximation. >> >Ignore the two ones. >0, 1, 2, 3 ... a step of one, a step of one, a step of one, that's linear. >it then converges on an exponential function at the higher end. That's an interesting claim, and I'd say based on cherry picked data points. Consider, instead Binet's formula, which clearly shows the Fibonacci series to be exponential.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2015-04-20 11:53 +0300 |
| Message-ID | <87pp6ztc36.fsf@bazspaz.fatphil.org> |
| In reply to | #60090 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> Very poor argument for choosing phi as the exponential base for probing.
I think I know where it comes from. Malcolm's clearly had some experience
of the field in which he's currently drowning. There are algorithms in
the field of searching for values of functions which do split regions of
interest based on the ratio phi, mostly such that given a set of values
S_n of coordinates <x, f(x)> at step n of the algorithm, and a decision
function, the difference between S_{n+1} and S_n is only one point, no
matter what the decision function decides. This is optimal, as you only
need to calculate one new point each step.
Name such an algorithm, or what it's used for - not a chance, that was
decades back (but at least I have the grace to admit I don't remember
such things). However, I can kinda remember[*] the mechanics:
Let's say S_n is the set of points with ordinates {A,B,C,D}, ordered
and with distances:
A -(phi)- B -(one)- C -(phi)- D
Let's say that we want to reduce the range to either A..C or B..D, depending
on the decision function. The new set[**] we are interested in is either AXBC
or BCYD:
A -(phi)- B -(one)- C -(phi)- D
A -(one)- X --- B -(one)- C
B -(one)- C --- Y -(one)- D
Doing the maths, you can see that |X-B| = |C-Y| = phi-1 = 1/phi, and therefore
that the phi:1:phi ratios are preserved, and only one new point needed to be
calculated. The bounds have decreased from 2phi+1 to phi+1, which is a ratio
of phi, so this is exponentially homing in on whatever it is looking for.
It's searching. It was probably in some way considered optimal (which is why it
was taught). And therefore I think that's what he's thinking of.
Phil
[* actually I had to work most of it out from the requirements, my memory's shit]
[** language and notation pertaining to sets is very informal]
--
A well regulated militia, being necessary to the security of a free state,
the right of the people to keep and bear arms, shall be well regulated.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-16 14:51 +1200 |
| Message-ID | <cp8md7Ffnp3U1@mid.individual.net> |
| In reply to | #60087 |
Malcolm McLean wrote: > On Wednesday, April 15, 2015 at 4:17:33 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Malcolm, if other people repeatedly fail to understand what I'm talking >> about, I usually consider the possibility that it's because I'm being >> unclear. >> > But I'm not being unclear. But you do have a knack for talking bollocks with great clarity.. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-17 02:13 -0700 |
| Message-ID | <kfn618vyv6d.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60087 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, April 15, 2015 at 4:17:33 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Malcolm, if other people repeatedly fail to understand what I'm talking >> about, I usually consider the possibility that it's because I'm being >> unclear. > > But I'm not being unclear. Considering the reactions of numerous responders, you might want to reconsider that opinion. Just a suggestion.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-04-15 08:14 +0200 |
| Message-ID | <mgkvjg$nl8$1@news.albasani.net> |
| In reply to | #60056 |
On 14.04.2015 22:16, Malcolm McLean wrote: >>>>> You can't minimise a golf course function. (That's one with a flat area and a tiny >>>>> minimum). > >> That would be a very peculiar natural language meaning of the word >> "can't" because for something that I "can't" do I sure as hell just did. >> > It wouldn't be an unusual use of natural language. So what you're saying is that it's natural in language that "can't" may mean "can", yes? Just to confirm, does your "wouldn't" in your sentence maybe also mean "would" or am I reading too much into it? > I said "a golf course function". Add a dimension. You do realize that YOU provided the original function, right? And you do also realize that adding a dimension changes nothing about the problem, right? You're doing *exactly* the weaseling about words which Ben predicted you would instead of admitting that your original wording was -- at best -- imprecise. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-14 21:02 +0100 |
| Message-ID | <mgjrma$89s$1@dont-email.me> |
| In reply to | #60051 |
On 14/04/15 20:43, Malcolm McLean wrote: > On Tuesday, April 14, 2015 at 6:48:57 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> <snip> >> >> >> > You can't minimise a golf course function. (That's one with a flat area and a tiny >> > minimum). >> >> Clearly one can. However, as in so many of your threads, your words are >> no doubt to be interpreted with all the extra words added in to make >> what you are saying something correct. We may never know the full set >> of constraints you are assuming for f which make your claims (which are >> flat-out wrong on the face of it) right in your mind. >> > The meaning is defined by the natural language of the words. The principal function of a golf course is to determine how few strokes can be used to sink the ball into every one of eighteen holes. Therefore, the minimum for a golf course function is 18. So "the natural language of the words" doesn't actually define the meaning you intended. -- 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-14 08:33 -0700 |
| Message-ID | <87egnmu3lj.fsf@kst-u.example.com> |
| In reply to | #60031 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, April 14, 2015 at 1:54:52 PM UTC+1, David Brown wrote:
>> And I assume you agree that you were completely wrong about Fibonacci
>> numbers being anything other than exponential growth. It would be nice
>> if you didn't keep snipping your mistakes - admitting that you are wrong
>> (or providing justification for why you are not) is common courtesy.
>>
> The base exponential function is e^x. The base arithmetical function
> is of course x + 1. The series phi^-1, 1, phi, phi^2 is a kind of
> midpoint between the two series.
The series x, x+2, x+4, x+6, x+8, ... is also a kind of "midpoint"
between the two series.
> Say we want to find x for which f(x) is zero. We know that x is N
> steps away from unity, and we know than N is less than, say, 100. But
> we don't know if the function is x - N or ln(x) - N. We can't plot it,
> all we can do is call f(x) and see if it is positive or negative. So
> what's our optimal strategy?
So we know that f(x) is a function, that f(x) == 0 for some x in the
range -99 .. +99, and we want to find such an x. Since you way we
"can't plot it", I presume that either the parameter is real rather than
integer or that calling the function is quite expensive; otherwise I'd
just call the function up to 199 times and be done with it.
You're asking about an "optimal strategy" over the set of all functions.
You've given no other information about how this function behaves, so
knowing the values of f(40) and f(42) tells us nothing about the value
of f(41). With the given information, there is no strategy better than
an exhaustive search.
Provide some more information about any restrictions on the function and
*maybe* we can reasonably discuss an optimal strategy.
> (I'm sure sure it's a golden section search, I think it is on the
> basis of reading, but I haven't actually tried to prove it from first
> principles).
Citation?
[...]
--
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-14 08:54 -0700 |
| Message-ID | <0ce60a7d-2fc9-47b0-9897-9bbe5f6857c6@googlegroups.com> |
| In reply to | #60041 |
On Tuesday, April 14, 2015 at 4:33:41 PM UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> So we know that f(x) is a function, that f(x) == 0 for some x in the
> range -99 .. +99, and we want to find such an x. Since you way we
> "can't plot it", I presume that either the parameter is real rather than
> integer or that calling the function is quite expensive; otherwise I'd
> just call the function up to 199 times and be done with it.
>
Exactly.
F(x) is either
int f(double x)
{
return sign( x - n );
}
or
int f(double x)
{
return sign(ln(x) - n);
}
We know that n isn't huge, in fact I'll tell you that it's between zero and 100.
So the task is to devise a search strategy that homes in on x (to machine
precision), with the fewest possible calls to f(), to make f return 0.
>
> Provide some more information about any restrictions on the function and
> *maybe* we can reasonably discuss an optimal strategy.
>
I think I've set it up right.
I've called it n rather than k because n will represent the number of "steps"
in some physical process. That's basically what we're after. However it's a real.
There might be a hole in it that means a trivial test will tell us which function
we're dealing with.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-14 11:43 -0700 |
| Message-ID | <87a8yatusw.fsf@kst-u.example.com> |
| In reply to | #60044 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, April 14, 2015 at 4:33:41 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> So we know that f(x) is a function, that f(x) == 0 for some x in the
>> range -99 .. +99, and we want to find such an x. Since you way we
>> "can't plot it", I presume that either the parameter is real rather than
>> integer or that calling the function is quite expensive; otherwise I'd
>> just call the function up to 199 times and be done with it.
>>
> Exactly.
> F(x) is either
>
>
> int f(double x)
> {
> return sign( x - n );
> }
>
> or
> int f(double x)
> {
> return sign(ln(x) - n);
> }
>
> We know that n isn't huge, in fact I'll tell you that it's between zero and 100.
The "optimal strategy" for determining the argument value for which a
function returns 0 (or perhaps "close enough" to 0) depends critically
on what information we have about the function. Is it continuous
(subject to the fact that floating-point representations are discrete)?
Is it monotone? Is its first derivative continuous?
> So the task is to devise a search strategy that homes in on x (to machine
> precision), with the fewest possible calls to f(), to make f return 0.
>>
>> Provide some more information about any restrictions on the function and
>> *maybe* we can reasonably discuss an optimal strategy.
>>
> I think I've set it up right.
> I've called it n rather than k because n will represent the number of "steps"
> in some physical process. That's basically what we're after. However it's a real.
>
> There might be a hole in it that means a trivial test will tell us which function
> we're dealing with.
I don't think so. Both functions return -1 for x < foo, 0 for x == foo,
1 for x > foo (assuming that's what you mean by "sign()"), where "foo"
is either n or exp(n). Applying sign() destroys the information we
could have used to distinguish between the two versions.
The big problem is that ln(x) is undefined for x <= 0.0. A secondary
problem is that there might not a value of x such that ln(x) - n == 0
(mathematically there is, but floating-point is not so well behaved).
Ignoring those problems (assuming a similar function that's actually
defined over -99..+99), and given information about the probability
distribution of the value of n and of the choice of which of the two
functions is being used, I have little doubt that an optimal strategy
could be devised, probably some kind of biased binary search. I'm
skeptical that it would be worth the effort over a simple unbiased
binary search, but perhaps in some applications it would be.
--
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-14 12:41 -0700 |
| Message-ID | <36e7f907-f6bb-4213-bbe6-7e44f7b48cb0@googlegroups.com> |
| In reply to | #60047 |
On Tuesday, April 14, 2015 at 7:43:38 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >The "optimal strategy" for determining the argument value for which a >function returns 0 (or perhaps "close enough" to 0) depends critically >on what information we have about the function. Is it continuous >(subject to the fact that floating-point representations are discrete)? >Is it monotone? Is its first derivative continuous? > The real issues that that you don't know much about the function, you're probing it. If it's pathological, such as a golf course function, then there's nothing you can do. But you know that it represents a physical process, so that's unlikely - not impossible, but there probably isn't a demon setting things up so you can't work out what is going on. It's not continuous, it consists of three sections, one which returns -1, one which returns 1, and a very small one (limited by machine precision) which returns 0. You know the machine precision, so if it so happens that one value returns 1 and the next representable value returns -1, then you've bracketed zero. That's a bit unrealistic. The idea that you can't take derivatives isn't unrealistic at all. > > I don't think so. Both functions return -1 for x < foo, 0 for x == foo, > 1 for x > foo (assuming that's what you mean by "sign()"), where "foo" > is either n or exp(n). Applying sign() destroys the information we > could have used to distinguish between the two versions. > Exactly, that's the problem. You know whether you're under or over, but you don't know the gradient. > > The big problem is that ln(x) is undefined for x <= 0.0. A secondary > problem is that there might not a value of x such that ln(x) - n == 0 > (mathematically there is, but floating-point is not so well behaved). > That's not a big problem, since I've told you that n is under 100 and all runs have produced values over 1, and n represents the number of steps in a physical process, with a bit of fuzziness to make the problem continuous. Clearly we can't pass x < 0.0. We've got one limit, but not the other one. > > Ignoring those problems (assuming a similar function that's actually > defined over -99..+99), and given information about the probability > distribution of the value of n and of the choice of which of the two > functions is being used, I have little doubt that an optimal strategy > could be devised, probably some kind of biased binary search. I'm > skeptical that it would be worth the effort over a simple unbiased > binary search, but perhaps in some applications it would be. > It is, yes. Obviously for the problem as I have defined it you can get the result in under just noticeable time on a modern machine, so it wouldn't really be worth the effort. But in reality f(x) might represent a physical measurement and be quite costly. Another common situation is that you spend several days of processor time minimising a function that takes several parameters.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-14 13:08 -0700 |
| Message-ID | <871tjmtqur.fsf@kst-u.example.com> |
| In reply to | #60050 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, April 14, 2015 at 7:43:38 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>The "optimal strategy" for determining the argument value for which a
>>function returns 0 (or perhaps "close enough" to 0) depends critically
>>on what information we have about the function. Is it continuous
>>(subject to the fact that floating-point representations are discrete)?
>>Is it monotone? Is its first derivative continuous?
>>
> The real issues that that you don't know much about the function,
> you're probing it. If it's pathological, such as a golf course function,
> then there's nothing you can do. But you know that it represents a physical
> process, so that's unlikely - not impossible, but there probably
> isn't a demon setting things up so you can't work out what is
> going on.
> It's not continuous, it consists of three sections, one which returns
> -1, one which returns 1, and a very small one (limited by machine precision)
> which returns 0. You know the machine precision, so if it so happens
> that one value returns 1 and the next representable value returns -1,
> then you've bracketed zero.
> That's a bit unrealistic. The idea that you can't take derivatives isn't
> unrealistic at all.
Ok, so the fact that the function is monotonic increasing is enough to
let us search for the argument value for which it returns 0, or at least
where it transitions from negative to positive. A binary search would
work. A biased binary search might be preferable, but we can't
implement it without more specific information about how we *expect* the
function to behave. (I'm making a general point, not asking for more
details about this particular function.)
[...]
>> The big problem is that ln(x) is undefined for x <= 0.0. A secondary
>> problem is that there might not a value of x such that ln(x) - n == 0
>> (mathematically there is, but floating-point is not so well behaved).
>>
> That's not a big problem, since I've told you that n is under 100
> and all runs have produced values over 1, and n represents the
> number of steps in a physical process, with a bit of fuzziness to
> make the problem continuous.
> Clearly we can't pass x < 0.0. We've got one limit, but not the other
> one.
The second version of your function computes ln(x), which is undefined
for x <= 0.0. In your original description, you said the function is
defined over the range -99 .. +99. If you were computing ln(n) and we
know that n >= 1, that would be ok -- but you're computing ln(x).
Your description is inconsistent.
This probably isn't relevant to the general problem, except that we
can't work with the function unless we have a consistent description of
its behavior.
>> Ignoring those problems (assuming a similar function that's actually
>> defined over -99..+99), and given information about the probability
>> distribution of the value of n and of the choice of which of the two
>> functions is being used, I have little doubt that an optimal strategy
>> could be devised, probably some kind of biased binary search. I'm
>> skeptical that it would be worth the effort over a simple unbiased
>> binary search, but perhaps in some applications it would be.
>>
> It is, yes. Obviously for the problem as I have defined it you can
> get the result in under just noticeable time on a modern machine,
> so it wouldn't really be worth the effort. But in reality f(x)
> might represent a physical measurement and be quite costly.
> Another common situation is that you spend several days of processor
> time minimising a function that takes several parameters.
Sure, all that seems plausible.
Your original claim was something about a "golden section search".
Perhaps later I'll read up on that. But I think we've gone rather far
afield from that claim.
--
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-14 14:02 -0700 |
| Message-ID | <85cda790-9929-4f48-aec6-b0caacbfccc1@googlegroups.com> |
| In reply to | #60055 |
On Tuesday, April 14, 2015 at 9:08:54 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Ok, so the fact that the function is monotonic increasing is enough to > let us search for the argument value for which it returns 0, or at least > where it transitions from negative to positive. A binary search would > work. A biased binary search might be preferable, but we can't > implement it without more specific information about how we *expect* the > function to behave. (I'm making a general point, not asking for more > details about this particular function.) > That's exactly the point. If you literally know nothing about the function, then of course there's no strategy other than trying numbers at random. > > The second version of your function computes ln(x), which is undefined > for x <= 0.0. In your original description, you said the function is > defined over the range -99 .. +99. If you were computing ln(n) and we > know that n >= 1, that would be ok -- but you're computing ln(x). > > Your description is inconsistent. > It's hard to say what the computer will do if you pass x < 0, but it's quite common to have a constraint that the argument shall be positive. > > This probably isn't relevant to the general problem, except that we > can't work with the function unless we have a consistent description of > its behavior. > The point is you don't know what you're dealing with. You probe it to characterise it. If you literally know nothing, then probing isn't going to help, but you've been told that n represents the number of steps in a physical process. > > Your original claim was something about a "golden section search". > Perhaps later I'll read up on that. But I think we've gone rather far > afield from that claim. > You want to work out how much memory you have. You can call malloc(), which will return a pointer if the amount is under the amount requested, or null if it is over. It's the same problem. Or a slightly different variant, you have a stream of text data coming in. You can allocate a small buffer with certainty, but you don't want to gobble a large buffer. However reallocations are also expensive. So given that our input is at least N bytes, what's our best estimate of its likely size? The point is that text is produced by a physical process. We can't characterise it exactly - there might be fashion for short and snappy tweets, followed by a later fashion for voluminous emails, followed by another one for messages of exactly 100 words. But on the other hand, we can't say absolutely nothing about it either.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-14 15:29 -0700 |
| Message-ID | <87wq1es5sg.fsf@kst-u.example.com> |
| In reply to | #60061 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Tuesday, April 14, 2015 at 9:08:54 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> Ok, so the fact that the function is monotonic increasing is enough to
>> let us search for the argument value for which it returns 0, or at least
>> where it transitions from negative to positive. A binary search would
>> work. A biased binary search might be preferable, but we can't
>> implement it without more specific information about how we *expect* the
>> function to behave. (I'm making a general point, not asking for more
>> details about this particular function.)
>>
> That's exactly the point. If you literally know nothing about the
> function, then of course there's no strategy other than trying numbers
> at random.
Right. And when I jumped into this thread, I knew almost literally
nothing about the function. You added some qualifications that might or
might not, for all I know, imply that a search using the golden ratio
would be optimal. The details, are unlikely to be related to C, so I
think I'll bow out of this.
>> The second version of your function computes ln(x), which is undefined
>> for x <= 0.0. In your original description, you said the function is
>> defined over the range -99 .. +99. If you were computing ln(n) and we
>> know that n >= 1, that would be ok -- but you're computing ln(x).
>>
>> Your description is inconsistent.
>>
> It's hard to say what the computer will do if you pass x < 0, but
> it's quite common to have a constraint that the argument shall be
> positive.
I think I misunderstood your description. Upthread, you wrote:
Say we want to find x for which f(x) is zero. We know that x
is N steps away from unity, and we know than N is less than,
say, 100. But we don't know if the function is x - N or ln(x)
- N. We can't plot it, all we can do is call f(x) and see if
it is positive or negative.
I think I confused x and N, and thought that you were saying the
function is defined for argument values from -99 to +99.
So the use of ln(x) implicitly constrains x to be positive. I should
have picked up on that, but it's something that would have been good to
mention explicitly.
[...]
--
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-15 10:03 +0200 |
| Message-ID | <mgl5vi$179$2@dont-email.me> |
| In reply to | #60050 |
On 14/04/15 21:41, Malcolm McLean wrote: > On Tuesday, April 14, 2015 at 7:43:38 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> The "optimal strategy" for determining the argument value for which a >> function returns 0 (or perhaps "close enough" to 0) depends critically >> on what information we have about the function. Is it continuous >> (subject to the fact that floating-point representations are discrete)? >> Is it monotone? Is its first derivative continuous? >> > The real issues that that you don't know much about the function, > you're probing it. Please make up your mind. In half your posts, you are telling us a great deal of information about the function is (it is either sign(ln(x) - n) or sign(x - n)), and in the other half you are telling us that we know little or nothing about the function.
[toc] | [prev] | [next] | [standalone]
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web