Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #117472 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-05-04 21:23 -0500 |
| Last post | 2025-05-06 22:07 -0400 |
| Articles | 20 on this page of 628 — 16 participants |
Back to article view | Back to comp.theory
Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-04 21:23 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-05 10:01 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 10:47 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 10:33 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 16:05 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 12:30 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 18:19 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 13:44 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 18:52 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 14:22 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 19:34 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 14:52 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-05 20:12 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 16:03 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-06 08:30 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-06 09:43 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 21:57 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable joes <noreply@example.org> - 2025-05-06 10:04 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-06 12:14 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 22:01 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-07 10:52 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-05 07:04 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-05 14:46 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-05 16:51 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-05 16:10 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-05 17:59 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-05 21:08 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 10:31 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-05 21:11 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 21:26 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 07:16 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-05 23:27 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-06 08:17 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-06 09:36 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Alan Mackenzie <acm@muc.de> - 2025-05-06 15:38 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-06 17:16 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Ben Bacarisse <ben@bsb.me.uk> - 2025-05-07 17:01 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 17:22 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-07 17:11 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 18:51 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 18:59 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Ben Bacarisse <ben@bsb.me.uk> - 2025-05-09 01:58 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 05:43 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 12:55 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 19:14 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-07 18:17 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 19:32 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-07 19:11 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 22:23 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 13:31 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 14:32 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 19:59 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 14:35 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 22:30 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 16:46 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 17:47 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 16:56 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 18:05 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:05 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 19:10 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:16 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 19:18 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:26 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 19:31 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:39 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 20:14 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:40 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 20:15 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 19:19 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 20:44 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 20:20 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 21:30 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 20:48 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 21:59 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 05:09 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-08 00:22 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 06:33 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-08 17:14 +0100
Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 12:00 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-08 21:04 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 14:42 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 21:01 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-08 21:35 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 23:12 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 15:26 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 15:31 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 17:47 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 16:45 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 18:53 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 17:00 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 19:14 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:07 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 20:33 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:11 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 18:54 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 05:50 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 00:01 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 06:23 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 06:52 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 10:41 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:39 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 12:50 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 09:39 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:02 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 19:23 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 21:28 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 21:18 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <news.x.richarddamon@xoxy.net> - 2025-05-08 23:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 21:22 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 23:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:00 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 06:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:16 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 12:52 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 09:52 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 12:57 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 09:59 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 10:47 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 13:00 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 14:46 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 21:07 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 15:15 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 17:35 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 22:40 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 17:18 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-09 18:31 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 19:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 01:26 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-09 20:14 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-09 19:40 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 11:13 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 22:24 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 11:43 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:18 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 12:32 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:44 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 12:51 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 00:06 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 13:13 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 00:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 13:27 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 00:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 14:00 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 01:06 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 14:19 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 09:51 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 11:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 17:14 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 23:14 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 10:43 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 00:00 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 11:15 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 12:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 00:21 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 11:44 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 12:55 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 17:34 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 18:05 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 17:07 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:30 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 08:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 08:37 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 08:36 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:16 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 08:54 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 08:53 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:53 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 00:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:25 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 08:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:22 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:31 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:21 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:34 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 09:42 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 09:09 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 22:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:45 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:18 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 11:24 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 17:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:05 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 11:18 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <news.x.richarddamon@xoxy.net> - 2025-05-09 13:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-10 01:23 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 19:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:20 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 03:59 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:06 -0400
Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] Alan Mackenzie <acm@muc.de> - 2025-05-10 10:21 +0000
Re: Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] olcott <polcott333@gmail.com> - 2025-05-10 09:30 -0500
Re: Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] dbush <dbush.mobile@gmail.com> - 2025-05-10 10:57 -0400
Re: Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 16:57 +0200
Re: Repetitive posting [ Was: Incorrect requirements --- Computing the mapping from the input to HHH(DD)] Richard Damon <richard@damon-family.org> - 2025-05-10 15:21 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:38 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-09 20:12 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 22:17 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:29 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:27 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:44 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 09:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:23 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:42 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 05:35 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 22:18 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 06:41 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 10:39 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:33 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-09 15:42 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:53 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:06 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 13:58 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:46 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:08 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 17:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 00:30 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 18:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 00:46 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 16:54 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 19:05 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:13 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 20:35 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 19:14 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-09 06:10 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 22:37 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:13 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:03 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 11:02 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:09 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:49 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 19:02 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 21:22 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:30 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-10 14:37 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 09:33 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 16:54 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-10 23:28 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 10:45 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 00:06 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 11:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 12:21 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 00:29 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 11:47 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 01:01 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 12:17 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 13:19 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 02:09 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 13:17 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 14:24 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 02:37 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 13:47 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 03:02 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 14:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 05:44 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 17:03 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 18:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-10 22:55 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 19:03 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-10 23:35 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 18:57 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 09:17 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 20:26 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 02:43 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 09:44 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 20:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 10:09 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 21:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 07:03 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-11 22:34 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 10:38 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 00:28 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 12:00 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 01:21 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 12:40 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 13:44 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 02:38 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 15:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 16:21 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 04:23 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 15:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 15:53 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 17:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 05:48 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 17:00 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 17:05 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 06:11 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 17:30 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 06:50 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 18:08 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) wij <wyniijj5@gmail.com> - 2025-05-12 08:33 +0800
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 19:51 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 21:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 20:51 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 21:56 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:30 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-16 15:38 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-16 10:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-16 12:04 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mikko <mikko.levanto@iki.fi> - 2025-05-17 11:09 +0300
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 19:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOS detector olcott <polcott333@gmail.com> - 2025-05-11 19:57 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOS detector dbush <dbush.mobile@gmail.com> - 2025-05-11 21:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOS detector joes <noreply@example.org> - 2025-05-12 09:22 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOS detector olcott <polcott333@gmail.com> - 2025-05-12 10:58 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 19:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 17:06 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mikko <mikko.levanto@iki.fi> - 2025-05-12 11:03 +0300
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 10:04 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 11:06 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 11:19 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 12:41 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 11:54 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 13:07 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 12:16 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 13:30 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 12:58 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 14:19 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:23 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mikko <mikko.levanto@iki.fi> - 2025-05-13 13:19 +0300
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-12 21:29 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <Richard@Damon-Family.org> - 2025-05-12 23:10 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 16:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Ben Bacarisse <ben@bsb.me.uk> - 2025-05-12 17:46 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 12:23 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:38 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <Richard@Damon-Family.org> - 2025-05-12 23:11 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 22:12 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 21:54 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-11 11:07 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 11:37 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 16:36 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 16:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 19:36 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:20 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 18:52 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:32 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-10 18:48 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 13:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 15:03 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:33 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-10 18:58 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-10 20:07 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-10 20:17 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 15:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 18:58 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-11 10:34 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 11:48 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 12:57 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 12:09 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 13:12 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 12:17 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 13:36 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 12:41 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 14:58 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 10:44 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:49 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 16:50 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 10:14 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:27 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 15:26 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-10 20:45 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 15:58 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 17:01 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 19:23 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 19:04 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 21:27 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-10 20:22 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-10 15:42 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-10 16:50 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 19:27 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-11 11:13 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 11:44 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 12:52 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 12:35 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 13:43 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:10 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 18:11 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-12 01:38 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 19:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 20:58 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 20:05 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 21:07 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 21:40 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:11 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 21:27 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 20:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 21:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:14 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:28 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:36 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:38 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:46 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:49 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:56 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:57 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 22:00 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 23:03 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 22:36 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 23:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 22:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 23:54 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 23:11 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 07:46 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 11:32 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-12 12:45 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-12 21:27 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:01 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:05 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:44 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:42 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 02:25 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Ben Bacarisse <ben@bsb.me.uk> - 2025-05-12 18:03 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Ben Bacarisse <ben@bsb.me.uk> - 2025-05-12 18:05 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 19:13 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Ben Bacarisse <ben@bsb.me.uk> - 2025-05-13 01:18 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-13 03:38 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 19:06 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-13 03:17 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-12 21:32 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:59 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 12:58 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-13 03:41 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-13 09:01 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-13 18:46 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-13 16:04 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-13 18:45 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-13 20:58 -0400
How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 20:07 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 21:19 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 20:40 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 21:45 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 20:55 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 21:58 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 21:43 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 22:44 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-13 22:18 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-13 23:35 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met joes <noreply@example.org> - 2025-05-14 08:17 +0000
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 10:06 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met joes <noreply@example.org> - 2025-05-14 18:37 +0000
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 13:42 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 19:56 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 14:02 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 20:17 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 14:21 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 20:49 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 15:00 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 21:18 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 15:25 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 21:26 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met joes <noreply@example.org> - 2025-05-14 20:28 +0000
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 15:40 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 21:54 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Heathfield <rjh@cpax.org.uk> - 2025-05-14 21:51 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met Ben Bacarisse <ben@bsb.me.uk> - 2025-05-14 20:20 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 14:46 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met dbush <dbush.mobile@gmail.com> - 2025-05-14 17:18 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Damon <richard@damon-family.org> - 2025-05-14 21:51 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-15 00:02 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 18:17 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 18:27 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Ben Bacarisse <ben@bsb.me.uk> - 2025-05-15 01:02 +0100
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 19:09 -0500
Re: How the requirements that Professor Sipser agreed to are exactly met Richard Damon <richard@damon-family.org> - 2025-05-14 07:46 -0400
Re: How the requirements that Professor Sipser agreed to are exactly met olcott <polcott333@gmail.com> - 2025-05-14 10:23 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-11 19:54 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 17:02 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 16:15 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 19:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 19:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-11 21:31 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 21:03 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 22:05 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-12 22:49 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 12:46 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 12:48 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-13 13:16 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-11 12:26 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 12:34 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Alan Mackenzie <acm@muc.de> - 2025-05-11 14:38 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-11 10:26 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:38 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) dbush <dbush.mobile@gmail.com> - 2025-05-11 11:58 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 15:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 09:45 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:13 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:00 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:59 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 10:52 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 16:49 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 18:59 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 20:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 18:30 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 21:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:35 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-09 04:14 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 22:34 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-09 09:48 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:08 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) joes <noreply@example.org> - 2025-05-09 15:47 +0000
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:57 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:22 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:12 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 21:11 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 23:49 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 22:31 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 00:49 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 23:17 -0700
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:03 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:24 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:21 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:15 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 18:02 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 19:36 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 18:43 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 20:37 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 15:28 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 01:29 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 20:38 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 01:48 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 19:54 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:43 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:08 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 19:51 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 02:15 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 20:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 02:32 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 20:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 20:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 03:15 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:20 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:39 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:47 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:12 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 23:46 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 11:03 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 14:57 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-10 09:17 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:10 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 14:59 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 20:50 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-10 03:19 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:27 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:17 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOUBLE DOG DARE YOU olcott <polcott333@gmail.com> - 2025-05-09 22:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOUBLE DOG DARE YOU Richard Damon <richard@damon-family.org> - 2025-05-09 23:50 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOUBLE DOG DARE YOU olcott <polcott333@gmail.com> - 2025-05-09 23:05 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) --- DOUBLE DOG DARE YOU Richard Damon <richard@damon-family.org> - 2025-05-10 09:20 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 14:55 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:32 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 22:30 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 21:45 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 23:22 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:14 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 11:04 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 16:41 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 23:13 +0100
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 17:20 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 07:25 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:55 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:29 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 10:33 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 10:29 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:32 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 09:37 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 19:35 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 18:48 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 21:18 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-08 20:55 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-08 22:26 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:28 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 11:13 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:33 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-09 11:25 +0200
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) olcott <polcott333@gmail.com> - 2025-05-09 11:11 -0500
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Richard Damon <richard@damon-family.org> - 2025-05-09 14:34 -0400
Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2025-05-10 09:53 +0200
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 18:45 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-08 07:21 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:41 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 22:52 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 16:59 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 23:16 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-07 22:26 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 23:29 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 18:09 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 03:24 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 21:41 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 05:12 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-07 21:33 -0700
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 23:54 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-08 06:02 +0100
Re: faithful simulations [was: Formal systems that cannot possibly be incomplete except for unknowns and unknowable] joes <noreply@example.org> - 2025-05-08 11:07 +0000
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 14:18 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 13:35 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 14:38 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 15:03 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 16:07 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 15:39 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 16:53 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 15:58 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 17:03 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 16:24 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable dbush <dbush.mobile@gmail.com> - 2025-05-07 17:29 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-07 13:03 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-08 11:38 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable olcott <polcott333@gmail.com> - 2025-05-06 12:06 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-07 11:02 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 09:19 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 22:04 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Mikko <mikko.levanto@iki.fi> - 2025-05-07 10:57 +0300
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Heathfield <rjh@cpax.org.uk> - 2025-05-07 09:05 +0100
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable Richard Damon <richard@damon-family.org> - 2025-05-06 07:20 -0400
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable ---ELABORATED olcott <polcott333@gmail.com> - 2025-05-06 12:46 -0500
Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable ---ELABORATED Richard Damon <richard@damon-family.org> - 2025-05-06 22:07 -0400
Page 6 of 32 — ← Prev page 1 … 4 5 [6] 7 8 … 32 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:39 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl7jf$2rl0l$8@dont-email.me> |
| In reply to | #118120 |
On 5/9/2025 3:41 AM, Fred. Zwarts wrote:
> Op 09.mei.2025 om 02:14 schreef olcott:
>> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>>>> [...]
>>>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>>>> of mathematics.
>>>>>>>
>>>>>>
>>>>>> If Halt7.c is not compiled with the Microsoft
>>>>>> compiler then it will not produce the required
>>>>>> object file type.
>>>>>>
>>>>>> The rest of the system has compiled under
>>>>>> Linux. I haven't tried this in a few years.
>>>>> [...]
>>>>> So you normally compile your code using the 2017 version of
>>>>> Microsoft
>>>>> Visual Studio.
>>>>> I have no particular problem with that, but your failure to correct
>>>>> a number of C errors in your code is odd.
>>>>
>>>> As I already proved Microsoft reported no such errors.
>>>
>>> Microsoft's compiler did not report certain errors that any conforming C
>>> compiler is required by the standard to report.
>>>
>>> Microsoft's compiler *can* be invoked in a way that causes it to
>>> diagnose such errors, though it may or may not become fully conforming.
>>> I haven't used it lately, but a web search should tell you how to do
>>> that.
>>>
>>>>> I've pointed out several
>>>>> syntax errors and constraint violations; at least the syntax errors
>>>>> would be trivial to fix (even if your compiler is lax enough to
>>>>> fail to diagnose them). Richard Heathfield has pointed out code
>>>>> that dereferences a null pointer.
>>>>>
>>>>
>>>> Mike corrected Richard on this.
>>>> Those are stub functions intercepted
>>>> by x86utm the operating system.
>>>>
>>>>> You are using C, a language in which you appear to have little
>>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>>> that, if true, would overturn ideas that have been generally accepted
>>>>> for decades. Can you understand why I might decide that analyzing
>>>>> your claims is not worth my time?
>>>>>
>>>>
>>>> I learned C back when K & R was the standard.
>>>
>>> So did I. I've kept up with the language as it has changed.
>>>
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return;
>>>> }
>>>>
>>>> We don't need to look at any of my code for me
>>>> to totally prove my point.
>>>
>>> Great. Then why do you keep posting code? Or is the above DDD()
>>> function not included in "any of my code")?
>>>
>>>> For example when
>>>> the above DDD is correctly simulated by HHH
>>>> this simulated DDD cannot possibly reach its own
>>>> "return" instruction.
>>>
>>> That's too vague for me to comment.
>>>
>>
>> Do you know what a C language interpreter is?
>> I actually do this at the x86 machine code level
>> yet most people don't have a clue about that.
>>
>> _DDD()
>> [00002172] 55 push ebp ; housekeeping
>> [00002173] 8bec mov ebp,esp ; housekeeping
>> [00002175] 6872210000 push 00002172 ; push DDD
>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>> [0000217f] 83c404 add esp,+04
>> [00002182] 5d pop ebp
>> [00002183] c3 ret
>> Size in bytes:(0018) [00002183]
>>
>> The above hypothetical HHH emulates the first four
>> instructions of DDD. This sequence repeats until a
>> OOM error.
>>
>
>
> Only in your dream, because HHH has code to abort and after that abort
> the program halts without OOM error.
> Every competent C programmer will understand that.
The above set of hypothetical HHH instances correctly
simulates 1 or more instructions of DDD including
its call to HHH(DDD). This does include HHH emulating
itself emulating DDD.
If you think it is impossible for HHH to emulate itself
emulating DDD then you don't have a clue about cooperative
multi-tasking and differing process contexts.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 12:50 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <1f6405ae4a520ceaf530dc9d4ba896f5d732cbbb@i2pn2.org> |
| In reply to | #118144 |
On 5/9/25 11:39 AM, olcott wrote:
> On 5/9/2025 3:41 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 02:14 schreef olcott:
>>> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>>>>> [...]
>>>>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>>>>> of mathematics.
>>>>>>>>
>>>>>>>
>>>>>>> If Halt7.c is not compiled with the Microsoft
>>>>>>> compiler then it will not produce the required
>>>>>>> object file type.
>>>>>>>
>>>>>>> The rest of the system has compiled under
>>>>>>> Linux. I haven't tried this in a few years.
>>>>>> [...]
>>>>>> So you normally compile your code using the 2017 version of
>>>>>> Microsoft
>>>>>> Visual Studio.
>>>>>> I have no particular problem with that, but your failure to correct
>>>>>> a number of C errors in your code is odd.
>>>>>
>>>>> As I already proved Microsoft reported no such errors.
>>>>
>>>> Microsoft's compiler did not report certain errors that any
>>>> conforming C
>>>> compiler is required by the standard to report.
>>>>
>>>> Microsoft's compiler *can* be invoked in a way that causes it to
>>>> diagnose such errors, though it may or may not become fully conforming.
>>>> I haven't used it lately, but a web search should tell you how to do
>>>> that.
>>>>
>>>>>> I've pointed out several
>>>>>> syntax errors and constraint violations; at least the syntax errors
>>>>>> would be trivial to fix (even if your compiler is lax enough to
>>>>>> fail to diagnose them). Richard Heathfield has pointed out code
>>>>>> that dereferences a null pointer.
>>>>>>
>>>>>
>>>>> Mike corrected Richard on this.
>>>>> Those are stub functions intercepted
>>>>> by x86utm the operating system.
>>>>>
>>>>>> You are using C, a language in which you appear to have little
>>>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>>>> that, if true, would overturn ideas that have been generally accepted
>>>>>> for decades. Can you understand why I might decide that analyzing
>>>>>> your claims is not worth my time?
>>>>>>
>>>>>
>>>>> I learned C back when K & R was the standard.
>>>>
>>>> So did I. I've kept up with the language as it has changed.
>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point.
>>>>
>>>> Great. Then why do you keep posting code? Or is the above DDD()
>>>> function not included in "any of my code")?
>>>>
>>>>> For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> That's too vague for me to comment.
>>>>
>>>
>>> Do you know what a C language interpreter is?
>>> I actually do this at the x86 machine code level
>>> yet most people don't have a clue about that.
>>>
>>> _DDD()
>>> [00002172] 55 push ebp ; housekeeping
>>> [00002173] 8bec mov ebp,esp ; housekeeping
>>> [00002175] 6872210000 push 00002172 ; push DDD
>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>> [0000217f] 83c404 add esp,+04
>>> [00002182] 5d pop ebp
>>> [00002183] c3 ret
>>> Size in bytes:(0018) [00002183]
>>>
>>> The above hypothetical HHH emulates the first four
>>> instructions of DDD. This sequence repeats until a
>>> OOM error.
>>>
>>
>>
>> Only in your dream, because HHH has code to abort and after that abort
>> the program halts without OOM error.
>> Every competent C programmer will understand that.
>
> The above set of hypothetical HHH instances correctly
> simulates 1 or more instructions of DDD including
> its call to HHH(DDD). This does include HHH emulating
> itself emulating DDD.
>
> If you think it is impossible for HHH to emulate itself
> emulating DDD then you don't have a clue about cooperative
> multi-tasking and differing process contexts.
>
No they don't, not past the call instruction, as that is IMPOSSIBLE for
the required pure function emulator to do when it hasn't been given them.
You are just showing that you think it is ok to just make up lies and
keep repeating them.
Your failure to show the error in this statement show you KNOW you are
just a liar, but don't care, as you know you have no answer for it, so
you will just keep repeating the error in hopes that someone will
believe you.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 09:39 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmvrm$3d8ic$4@dont-email.me> |
| In reply to | #118144 |
Op 09.mei.2025 om 17:39 schreef olcott:
> On 5/9/2025 3:41 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 02:14 schreef olcott:
>>> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>>>>> [...]
>>>>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>>>>> of mathematics.
>>>>>>>>
>>>>>>>
>>>>>>> If Halt7.c is not compiled with the Microsoft
>>>>>>> compiler then it will not produce the required
>>>>>>> object file type.
>>>>>>>
>>>>>>> The rest of the system has compiled under
>>>>>>> Linux. I haven't tried this in a few years.
>>>>>> [...]
>>>>>> So you normally compile your code using the 2017 version of
>>>>>> Microsoft
>>>>>> Visual Studio.
>>>>>> I have no particular problem with that, but your failure to correct
>>>>>> a number of C errors in your code is odd.
>>>>>
>>>>> As I already proved Microsoft reported no such errors.
>>>>
>>>> Microsoft's compiler did not report certain errors that any
>>>> conforming C
>>>> compiler is required by the standard to report.
>>>>
>>>> Microsoft's compiler *can* be invoked in a way that causes it to
>>>> diagnose such errors, though it may or may not become fully conforming.
>>>> I haven't used it lately, but a web search should tell you how to do
>>>> that.
>>>>
>>>>>> I've pointed out several
>>>>>> syntax errors and constraint violations; at least the syntax errors
>>>>>> would be trivial to fix (even if your compiler is lax enough to
>>>>>> fail to diagnose them). Richard Heathfield has pointed out code
>>>>>> that dereferences a null pointer.
>>>>>>
>>>>>
>>>>> Mike corrected Richard on this.
>>>>> Those are stub functions intercepted
>>>>> by x86utm the operating system.
>>>>>
>>>>>> You are using C, a language in which you appear to have little
>>>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>>>> that, if true, would overturn ideas that have been generally accepted
>>>>>> for decades. Can you understand why I might decide that analyzing
>>>>>> your claims is not worth my time?
>>>>>>
>>>>>
>>>>> I learned C back when K & R was the standard.
>>>>
>>>> So did I. I've kept up with the language as it has changed.
>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point.
>>>>
>>>> Great. Then why do you keep posting code? Or is the above DDD()
>>>> function not included in "any of my code")?
>>>>
>>>>> For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> That's too vague for me to comment.
>>>>
>>>
>>> Do you know what a C language interpreter is?
>>> I actually do this at the x86 machine code level
>>> yet most people don't have a clue about that.
>>>
>>> _DDD()
>>> [00002172] 55 push ebp ; housekeeping
>>> [00002173] 8bec mov ebp,esp ; housekeeping
>>> [00002175] 6872210000 push 00002172 ; push DDD
>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>> [0000217f] 83c404 add esp,+04
>>> [00002182] 5d pop ebp
>>> [00002183] c3 ret
>>> Size in bytes:(0018) [00002183]
>>>
>>> The above hypothetical HHH emulates the first four
>>> instructions of DDD. This sequence repeats until a
>>> OOM error.
>>>
>>
>>
>> Only in your dream, because HHH has code to abort and after that abort
>> the program halts without OOM error.
>> Every competent C programmer will understand that.
>
> The above set of hypothetical HHH instances correctly
> simulates 1 or more instructions of DDD including
> its call to HHH(DDD). This does include HHH emulating
> itself emulating DDD.
>
> If you think it is impossible for HHH to emulate itself
> emulating DDD then you don't have a clue about cooperative
> multi-tasking and differing process contexts.
>
Even a beginner can see that HHH cannot possibly simulate itself
correctly. So, your ad hominem attack misses the target.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-08 21:02 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <d577d485d0f5dfab26315f54f91eb84f25eecc40@i2pn2.org> |
| In reply to | #118067 |
On 5/8/25 7:53 PM, olcott wrote:
> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>> [...]
>>>> I am more nearly an expert on C than on the Halting Problem.
>>>> Watching olcott base his arguments on C *and getting C so badly
>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>> reactions of actual experts to his mathematical arguments leads me
>>>> to the same conclusion about his knowledge of the relevant fields
>>>> of mathematics.
>>>>
>>>
>>> If Halt7.c is not compiled with the Microsoft
>>> compiler then it will not produce the required
>>> object file type.
>>>
>>> The rest of the system has compiled under
>>> Linux. I haven't tried this in a few years.
>>
>> [...]
>>
>> So you normally compile your code using the 2017 version of Microsoft
>> Visual Studio.
>>
>> I have no particular problem with that, but your failure to correct
>> a number of C errors in your code is odd.
>
> As I already proved Microsoft reported no such errors.
>
>> I've pointed out several
>> syntax errors and constraint violations; at least the syntax errors
>> would be trivial to fix (even if your compiler is lax enough to
>> fail to diagnose them). Richard Heathfield has pointed out code
>> that dereferences a null pointer.
>>
>
> Mike corrected Richard on this.
> Those are stub functions intercepted
> by x86utm the operating system.
>
>> You are using C, a language in which you appear to have little
>> apparent expertise or willingness to learn, to demonstrate claims
>> that, if true, would overturn ideas that have been generally accepted
>> for decades. Can you understand why I might decide that analyzing
>> your claims is not worth my time?
>>
>
> I learned C back when K & R was the standard.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> We don't need to look at any of my code for me
> to totally prove my point. For example when
> the above DDD is correctly simulated by HHH
> this simulated DDD cannot possibly reach its own
> "return" instruction.
>
>
And thus not correctly simulatd.
Sorry, there is no "OS Exemption" to correct simulaiton;.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 19:23 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87bjs2cyj6.fsf@nosuchdomain.example.com> |
| In reply to | #118074 |
Richard Damon <richard@damon-family.org> writes:
> On 5/8/25 7:53 PM, olcott wrote:
[...]
>> void DDD()
>> {
>> HHH(DDD);
>> return;
>> }
>> We don't need to look at any of my code for me
>> to totally prove my point. For example when
>> the above DDD is correctly simulated by HHH
>> this simulated DDD cannot possibly reach its own
>> "return" instruction.
>
> And thus not correctly simulatd.
>
> Sorry, there is no "OS Exemption" to correct simulaiton;.
Perhaps I've missed something. I don't see anything in the above that
implies that HHH does not correctly simulate DDD. Richard, you've read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code is
equivalent to:
void DDD()
{
DDD();
return;
}
which is a trivial case of infinite recursion. As far as I can tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement. Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience. (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 21:28 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjp7j$28g5i$13@dont-email.me> |
| In reply to | #118089 |
On 5/8/2025 9:23 PM, Keith Thompson wrote:
> Richard Damon <richard@damon-family.org> writes:
>> On 5/8/25 7:53 PM, olcott wrote:
> [...]
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>> We don't need to look at any of my code for me
>>> to totally prove my point. For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>>
>> And thus not correctly simulatd.
>>
>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>
> Perhaps I've missed something. I don't see anything in the above that
> implies that HHH does not correctly simulate DDD. Richard, you've read
> far more of olcott's posts than I have, so perhaps you can clarify.
>
> If we assume that HHH correctly simulates DDD, then the above code is
> equivalent to:
>
> void DDD()
> {
> DDD();
> return;
> }
>
> which is a trivial case of infinite recursion. As far as I can tell,
> assuming that DDD() is actually called at some point, neither the
> outer execution of DDD nor the nested (simulated) execution of DDD
> can reach the return statement. Infinite recursion might either
> cause a stack overflow and a probable program crash, or an unending
> loop if the compiler implements tail call optimization.
>
> I see no contradiction, just an uninteresting case of infinite
> recursion, something that's well understood by anyone with a
> reasonable level of programming experience. (And it has nothing to
> do with the halting problem as far as I can tell, though of course
> olcott has discussed the halting problem elsewhere.)
>
> Richard, what am I missing?
>
Now you are seeing what I was talking about.
Now you are seeing why I needed to cross post
to comp.lang.c
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 21:18 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87selebeo1.fsf@nosuchdomain.example.com> |
| In reply to | #118094 |
olcott <polcott333@gmail.com> writes:
[...]
> Now you are seeing what I was talking about.
No, I am not.
> Now you are seeing why I needed to cross post
> to comp.lang.c
No. I don't even see anything you post to comp.lang.c, including any
cross-posts. I would ask you to stop if I thought you'd listen.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2025-05-08 23:01 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjr60$2gfbv$1@dont-email.me> |
| In reply to | #118089 |
On 5/8/25 10:23 PM, Keith Thompson wrote:
> Richard Damon <richard@damon-family.org> writes:
>> On 5/8/25 7:53 PM, olcott wrote:
> [...]
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>> We don't need to look at any of my code for me
>>> to totally prove my point. For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>>
>> And thus not correctly simulatd.
>>
>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>
> Perhaps I've missed something. I don't see anything in the above that
> implies that HHH does not correctly simulate DDD. Richard, you've read
> far more of olcott's posts than I have, so perhaps you can clarify.
>
> If we assume that HHH correctly simulates DDD, then the above code is
> equivalent to:
>
> void DDD()
> {
> DDD();
> return;
> }
>
> which is a trivial case of infinite recursion. As far as I can tell,
> assuming that DDD() is actually called at some point, neither the
> outer execution of DDD nor the nested (simulated) execution of DDD
> can reach the return statement. Infinite recursion might either
> cause a stack overflow and a probable program crash, or an unending
> loop if the compiler implements tail call optimization.
>
> I see no contradiction, just an uninteresting case of infinite
> recursion, something that's well understood by anyone with a
> reasonable level of programming experience. (And it has nothing to
> do with the halting problem as far as I can tell, though of course
> olcott has discussed the halting problem elsewhere.)
>
> Richard, what am I missing?
>
You are missing the equivocation he is using on what is "DDD()"
First, he tries to define it as just the code of the function, and not
including any of the code that it calls. He does this so all the various
HHH that he talks about are given the "same" input.
Then he tries to also say that when those functions look at DDD, they
can follow the memory chain to the functions that it calls, that weren't
actually part of the input.
This means the "behavior" of his input isn't actually defined by the input.
He has also, to get around other objections about what he is doing,
stipulated that his functions must be pure functions, and thus only
dependent on their direct input, other wise we can add the following
code to the beginning of HHH to make his statement false:
int HHH(void (*p)()) {
static int flag = 0;
if (flag) return 0;
flag = 1;
/* then the rest of the code that he uses to simulate the input */
Such an HHH obviously can "correctly simulate" a call to itself in the
same memory space to the return of DDD.
But, since HHH has been stipulated to be a pure function, it can't
access memory that wasn't part of its input, and thus his first
definition can't be used, and when we use the second definiton, it is
clear that each of his HHH's get different input, so is ploy to show
that the HHH that does correctly emulate the input which show that "the"
DDD is non-halting also shows that the HHH that does abort, and was
given the "same" input can also conclude that.
Of course, different inputs can behavie differently and thus he is just
using his projection that HHH(DDD) is just like the sum(2,3) that
returned 7 as the sum of 2 + 5 since it "changed" the input to something
it wasn't.
His goal is to ge this "fact" agreed to in the abstract case, so he can
claim it must also be true when HHH is now defined to be that HHH that
aborts by his equivocation.
The HHH that correctly emulates its input can only do its job when the
input includes all the code it is to emulate as a valid part of its input.
If you look at some of his other posts, what he really is trying to do
is say that HHH can "correctly" emulate the call to HHH(DDD) as actually
starting a new level of emulation within the actual emulator instead of
actually emulating the emulator emulating the input, as that "gets too
long" and thus hidding that the emulation WILL be aborted by his actual
HHH and not create the claimed infinite recursion, which only exists in
his "hypothectical" HHH that isn't what he will actually define it to be.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 21:22 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87o6w2begg.fsf@nosuchdomain.example.com> |
| In reply to | #118097 |
Richard Damon <news.x.richarddamon@xoxy.net> writes:
> On 5/8/25 10:23 PM, Keith Thompson wrote:
>> Richard Damon <richard@damon-family.org> writes:
>>> On 5/8/25 7:53 PM, olcott wrote:
>> [...]
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return;
>>>> }
>>>> We don't need to look at any of my code for me
>>>> to totally prove my point. For example when
>>>> the above DDD is correctly simulated by HHH
>>>> this simulated DDD cannot possibly reach its own
>>>> "return" instruction.
>>>
>>> And thus not correctly simulatd.
>>>
>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>> Perhaps I've missed something. I don't see anything in the above
>> that
>> implies that HHH does not correctly simulate DDD. Richard, you've read
>> far more of olcott's posts than I have, so perhaps you can clarify.
>> If we assume that HHH correctly simulates DDD, then the above code
>> is
>> equivalent to:
>> void DDD()
>> {
>> DDD();
>> return;
>> }
>> which is a trivial case of infinite recursion. As far as I can
>> tell,
>> assuming that DDD() is actually called at some point, neither the
>> outer execution of DDD nor the nested (simulated) execution of DDD
>> can reach the return statement. Infinite recursion might either
>> cause a stack overflow and a probable program crash, or an unending
>> loop if the compiler implements tail call optimization.
>> I see no contradiction, just an uninteresting case of infinite
>> recursion, something that's well understood by anyone with a
>> reasonable level of programming experience. (And it has nothing to
>> do with the halting problem as far as I can tell, though of course
>> olcott has discussed the halting problem elsewhere.)
>> Richard, what am I missing?
>>
>
> You are missing the equivocation he is using on what is "DDD()"
>
> First, he tries to define it as just the code of the function, and not
> including any of the code that it calls. He does this so all the
> various HHH that he talks about are given the "same" input.
>
> Then he tries to also say that when those functions look at DDD, they
> can follow the memory chain to the functions that it calls, that
> weren't actually part of the input.
>
> This means the "behavior" of his input isn't actually defined by the input.
I haven't seen any of that in the posts to which I've recently replied
(and I absolutely do not have the patience to read everything he's
posted here).
What I've seen in the articles to which I've recently replied has been
just a strangely little C function and some claims about simulation.
Viewed in isolation, I don't think any of that (again, ignoring the vast
majority of what he's posted in this newsgroup) seems contradictory so far.
> He has also, to get around other objections about what he is doing,
> stipulated that his functions must be pure functions, and thus only
> dependent on their direct input, other wise we can add the following
> code to the beginning of HHH to make his statement false:
I've seen no mention of pure functions in the posts to which I've
recently replied.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 23:56 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvk1ul$2ibbd$2@dont-email.me> |
| In reply to | #118102 |
On 5/8/2025 11:22 PM, Keith Thompson wrote:
> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>> On 5/8/25 10:23 PM, Keith Thompson wrote:
>>> Richard Damon <richard@damon-family.org> writes:
>>>> On 5/8/25 7:53 PM, olcott wrote:
>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point. For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> And thus not correctly simulatd.
>>>>
>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>> Perhaps I've missed something. I don't see anything in the above
>>> that
>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>> If we assume that HHH correctly simulates DDD, then the above code
>>> is
>>> equivalent to:
>>> void DDD()
>>> {
>>> DDD();
>>> return;
>>> }
>>> which is a trivial case of infinite recursion. As far as I can
>>> tell,
>>> assuming that DDD() is actually called at some point, neither the
>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>> can reach the return statement. Infinite recursion might either
>>> cause a stack overflow and a probable program crash, or an unending
>>> loop if the compiler implements tail call optimization.
>>> I see no contradiction, just an uninteresting case of infinite
>>> recursion, something that's well understood by anyone with a
>>> reasonable level of programming experience. (And it has nothing to
>>> do with the halting problem as far as I can tell, though of course
>>> olcott has discussed the halting problem elsewhere.)
>>> Richard, what am I missing?
>>>
>>
>> You are missing the equivocation he is using on what is "DDD()"
>>
>> First, he tries to define it as just the code of the function, and not
>> including any of the code that it calls. He does this so all the
>> various HHH that he talks about are given the "same" input.
>>
>> Then he tries to also say that when those functions look at DDD, they
>> can follow the memory chain to the functions that it calls, that
>> weren't actually part of the input.
>>
>> This means the "behavior" of his input isn't actually defined by the input.
>
> I haven't seen any of that in the posts to which I've recently replied
> (and I absolutely do not have the patience to read everything he's
> posted here).
>
> What I've seen in the articles to which I've recently replied has been
> just a strangely little C function and some claims about simulation.
> Viewed in isolation, I don't think any of that (again, ignoring the vast
> majority of what he's posted in this newsgroup) seems contradictory so far.
>
>> He has also, to get around other objections about what he is doing,
>> stipulated that his functions must be pure functions, and thus only
>> dependent on their direct input, other wise we can add the following
>> code to the beginning of HHH to make his statement false:
>
> I've seen no mention of pure functions in the posts to which I've
> recently replied.
>
> [...]
>
You are seeing some of the same misdirection that I have been seeing.
Most people here change the subject when they come across difficult
and crucial material.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 07:00 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <05ab96dce116c352f92897c5bb5559194b830f6f@i2pn2.org> |
| In reply to | #118107 |
On 5/9/25 12:56 AM, olcott wrote:
> On 5/8/2025 11:22 PM, Keith Thompson wrote:
>> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>>> On 5/8/25 10:23 PM, Keith Thompson wrote:
>>>> Richard Damon <richard@damon-family.org> writes:
>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>> We don't need to look at any of my code for me
>>>>>> to totally prove my point. For example when
>>>>>> the above DDD is correctly simulated by HHH
>>>>>> this simulated DDD cannot possibly reach its own
>>>>>> "return" instruction.
>>>>>
>>>>> And thus not correctly simulatd.
>>>>>
>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>> Perhaps I've missed something. I don't see anything in the above
>>>> that
>>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>> is
>>>> equivalent to:
>>>> void DDD()
>>>> {
>>>> DDD();
>>>> return;
>>>> }
>>>> which is a trivial case of infinite recursion. As far as I can
>>>> tell,
>>>> assuming that DDD() is actually called at some point, neither the
>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>> can reach the return statement. Infinite recursion might either
>>>> cause a stack overflow and a probable program crash, or an unending
>>>> loop if the compiler implements tail call optimization.
>>>> I see no contradiction, just an uninteresting case of infinite
>>>> recursion, something that's well understood by anyone with a
>>>> reasonable level of programming experience. (And it has nothing to
>>>> do with the halting problem as far as I can tell, though of course
>>>> olcott has discussed the halting problem elsewhere.)
>>>> Richard, what am I missing?
>>>>
>>>
>>> You are missing the equivocation he is using on what is "DDD()"
>>>
>>> First, he tries to define it as just the code of the function, and not
>>> including any of the code that it calls. He does this so all the
>>> various HHH that he talks about are given the "same" input.
>>>
>>> Then he tries to also say that when those functions look at DDD, they
>>> can follow the memory chain to the functions that it calls, that
>>> weren't actually part of the input.
>>>
>>> This means the "behavior" of his input isn't actually defined by the
>>> input.
>>
>> I haven't seen any of that in the posts to which I've recently replied
>> (and I absolutely do not have the patience to read everything he's
>> posted here).
>>
>> What I've seen in the articles to which I've recently replied has been
>> just a strangely little C function and some claims about simulation.
>> Viewed in isolation, I don't think any of that (again, ignoring the vast
>> majority of what he's posted in this newsgroup) seems contradictory so
>> far.
>>
>>> He has also, to get around other objections about what he is doing,
>>> stipulated that his functions must be pure functions, and thus only
>>> dependent on their direct input, other wise we can add the following
>>> code to the beginning of HHH to make his statement false:
>>
>> I've seen no mention of pure functions in the posts to which I've
>> recently replied.
>>
>> [...]
>>
> You are seeing some of the same misdirection that I have been seeing.
> Most people here change the subject when they come across difficult
> and crucial material.
>
So, are you no removing that pure function requirement?
In that case, why is my version of H not a correct refutation of your
claim that no H can reach that return?
Sorry, your logic is just based on lies and equivocations.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 06:59 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <28aa41aee538a585d6a4d47af5100c3fbdfff2b5@i2pn2.org> |
| In reply to | #118102 |
On 5/9/25 12:22 AM, Keith Thompson wrote:
> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>> On 5/8/25 10:23 PM, Keith Thompson wrote:
>>> Richard Damon <richard@damon-family.org> writes:
>>>> On 5/8/25 7:53 PM, olcott wrote:
>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point. For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> And thus not correctly simulatd.
>>>>
>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>> Perhaps I've missed something. I don't see anything in the above
>>> that
>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>> If we assume that HHH correctly simulates DDD, then the above code
>>> is
>>> equivalent to:
>>> void DDD()
>>> {
>>> DDD();
>>> return;
>>> }
>>> which is a trivial case of infinite recursion. As far as I can
>>> tell,
>>> assuming that DDD() is actually called at some point, neither the
>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>> can reach the return statement. Infinite recursion might either
>>> cause a stack overflow and a probable program crash, or an unending
>>> loop if the compiler implements tail call optimization.
>>> I see no contradiction, just an uninteresting case of infinite
>>> recursion, something that's well understood by anyone with a
>>> reasonable level of programming experience. (And it has nothing to
>>> do with the halting problem as far as I can tell, though of course
>>> olcott has discussed the halting problem elsewhere.)
>>> Richard, what am I missing?
>>>
>>
>> You are missing the equivocation he is using on what is "DDD()"
>>
>> First, he tries to define it as just the code of the function, and not
>> including any of the code that it calls. He does this so all the
>> various HHH that he talks about are given the "same" input.
>>
>> Then he tries to also say that when those functions look at DDD, they
>> can follow the memory chain to the functions that it calls, that
>> weren't actually part of the input.
>>
>> This means the "behavior" of his input isn't actually defined by the input.
>
> I haven't seen any of that in the posts to which I've recently replied
> (and I absolutely do not have the patience to read everything he's
> posted here).
>
> What I've seen in the articles to which I've recently replied has been
> just a strangely little C function and some claims about simulation.
> Viewed in isolation, I don't think any of that (again, ignoring the vast
> majority of what he's posted in this newsgroup) seems contradictory so far.
The problem is the subtile one that he needs all "versions" of the input
"DDD" to be the "same input" no matter what decider he uses, which means
he can't include the code for the decider called as part of the input.
But also, as I explained, he needs to define the decider to be a pure
function to outlaw the trivial solution of the decider short-cutting
itself when it is called by the input with a static variable, which
means it can't do the job without it being part of the input.
>
>> He has also, to get around other objections about what he is doing,
>> stipulated that his functions must be pure functions, and thus only
>> dependent on their direct input, other wise we can add the following
>> code to the beginning of HHH to make his statement false:
>
> I've seen no mention of pure functions in the posts to which I've
> recently replied.
Again, that is because that side of the equivocation hasn't been argued
recently. Perhaps when he starts to argue that the decider is allowed to
look at the "non-input" code, we will get back to that.
>
> [...]
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:16 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl68h$2rl0l$5@dont-email.me> |
| In reply to | #118130 |
On 5/9/2025 5:59 AM, Richard Damon wrote:
> On 5/9/25 12:22 AM, Keith Thompson wrote:
>> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>>> On 5/8/25 10:23 PM, Keith Thompson wrote:
>>>> Richard Damon <richard@damon-family.org> writes:
>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>> We don't need to look at any of my code for me
>>>>>> to totally prove my point. For example when
>>>>>> the above DDD is correctly simulated by HHH
>>>>>> this simulated DDD cannot possibly reach its own
>>>>>> "return" instruction.
>>>>>
>>>>> And thus not correctly simulatd.
>>>>>
>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>> Perhaps I've missed something. I don't see anything in the above
>>>> that
>>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>> is
>>>> equivalent to:
>>>> void DDD()
>>>> {
>>>> DDD();
>>>> return;
>>>> }
>>>> which is a trivial case of infinite recursion. As far as I can
>>>> tell,
>>>> assuming that DDD() is actually called at some point, neither the
>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>> can reach the return statement. Infinite recursion might either
>>>> cause a stack overflow and a probable program crash, or an unending
>>>> loop if the compiler implements tail call optimization.
>>>> I see no contradiction, just an uninteresting case of infinite
>>>> recursion, something that's well understood by anyone with a
>>>> reasonable level of programming experience. (And it has nothing to
>>>> do with the halting problem as far as I can tell, though of course
>>>> olcott has discussed the halting problem elsewhere.)
>>>> Richard, what am I missing?
>>>>
>>>
>>> You are missing the equivocation he is using on what is "DDD()"
>>>
>>> First, he tries to define it as just the code of the function, and not
>>> including any of the code that it calls. He does this so all the
>>> various HHH that he talks about are given the "same" input.
>>>
>>> Then he tries to also say that when those functions look at DDD, they
>>> can follow the memory chain to the functions that it calls, that
>>> weren't actually part of the input.
>>>
>>> This means the "behavior" of his input isn't actually defined by the
>>> input.
>>
>> I haven't seen any of that in the posts to which I've recently replied
>> (and I absolutely do not have the patience to read everything he's
>> posted here).
>>
>> What I've seen in the articles to which I've recently replied has been
>> just a strangely little C function and some claims about simulation.
>> Viewed in isolation, I don't think any of that (again, ignoring the vast
>> majority of what he's posted in this newsgroup) seems contradictory so
>> far.
>
> The problem is the subtile one that he needs all "versions" of the input
> "DDD" to be the "same input" no matter what decider he uses, which means
> he can't include the code for the decider called as part of the input.
>
> But also, as I explained, he needs to define the decider to be a pure
> function to outlaw the trivial solution of the decider short-cutting
> itself when it is called by the input with a static variable, which
> means it can't do the job without it being part of the input.
>
>>
>>> He has also, to get around other objections about what he is doing,
>>> stipulated that his functions must be pure functions, and thus only
>>> dependent on their direct input, other wise we can add the following
>>> code to the beginning of HHH to make his statement false:
>>
>> I've seen no mention of pure functions in the posts to which I've
>> recently replied.
>
> Again, that is because that side of the equivocation hasn't been argued
> recently. Perhaps when he starts to argue that the decider is allowed to
> look at the "non-input" code, we will get back to that.
>
void DDD()
{
HHH(DDD);
return;
}
*Subtle strawman deception change away from this exact subject*
DDD correctly simulated by HHH cannot possibly
reach its own "return" instruction.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 12:52 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <e335c630571eeaac796de650705508fae4ef2814@i2pn2.org> |
| In reply to | #118141 |
On 5/9/25 11:16 AM, olcott wrote:
> On 5/9/2025 5:59 AM, Richard Damon wrote:
>> On 5/9/25 12:22 AM, Keith Thompson wrote:
>>> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>>>> On 5/8/25 10:23 PM, Keith Thompson wrote:
>>>>> Richard Damon <richard@damon-family.org> writes:
>>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>>> [...]
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>> We don't need to look at any of my code for me
>>>>>>> to totally prove my point. For example when
>>>>>>> the above DDD is correctly simulated by HHH
>>>>>>> this simulated DDD cannot possibly reach its own
>>>>>>> "return" instruction.
>>>>>>
>>>>>> And thus not correctly simulatd.
>>>>>>
>>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>>> Perhaps I've missed something. I don't see anything in the above
>>>>> that
>>>>> implies that HHH does not correctly simulate DDD. Richard, you've
>>>>> read
>>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>>> is
>>>>> equivalent to:
>>>>> void DDD()
>>>>> {
>>>>> DDD();
>>>>> return;
>>>>> }
>>>>> which is a trivial case of infinite recursion. As far as I can
>>>>> tell,
>>>>> assuming that DDD() is actually called at some point, neither the
>>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>>> can reach the return statement. Infinite recursion might either
>>>>> cause a stack overflow and a probable program crash, or an unending
>>>>> loop if the compiler implements tail call optimization.
>>>>> I see no contradiction, just an uninteresting case of infinite
>>>>> recursion, something that's well understood by anyone with a
>>>>> reasonable level of programming experience. (And it has nothing to
>>>>> do with the halting problem as far as I can tell, though of course
>>>>> olcott has discussed the halting problem elsewhere.)
>>>>> Richard, what am I missing?
>>>>>
>>>>
>>>> You are missing the equivocation he is using on what is "DDD()"
>>>>
>>>> First, he tries to define it as just the code of the function, and not
>>>> including any of the code that it calls. He does this so all the
>>>> various HHH that he talks about are given the "same" input.
>>>>
>>>> Then he tries to also say that when those functions look at DDD, they
>>>> can follow the memory chain to the functions that it calls, that
>>>> weren't actually part of the input.
>>>>
>>>> This means the "behavior" of his input isn't actually defined by the
>>>> input.
>>>
>>> I haven't seen any of that in the posts to which I've recently replied
>>> (and I absolutely do not have the patience to read everything he's
>>> posted here).
>>>
>>> What I've seen in the articles to which I've recently replied has been
>>> just a strangely little C function and some claims about simulation.
>>> Viewed in isolation, I don't think any of that (again, ignoring the vast
>>> majority of what he's posted in this newsgroup) seems contradictory
>>> so far.
>>
>> The problem is the subtile one that he needs all "versions" of the
>> input "DDD" to be the "same input" no matter what decider he uses,
>> which means he can't include the code for the decider called as part
>> of the input.
>>
>> But also, as I explained, he needs to define the decider to be a pure
>> function to outlaw the trivial solution of the decider short-cutting
>> itself when it is called by the input with a static variable, which
>> means it can't do the job without it being part of the input.
>>
>>>
>>>> He has also, to get around other objections about what he is doing,
>>>> stipulated that his functions must be pure functions, and thus only
>>>> dependent on their direct input, other wise we can add the following
>>>> code to the beginning of HHH to make his statement false:
>>>
>>> I've seen no mention of pure functions in the posts to which I've
>>> recently replied.
>>
>> Again, that is because that side of the equivocation hasn't been
>> argued recently. Perhaps when he starts to argue that the decider is
>> allowed to look at the "non-input" code, we will get back to that.
>>
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> *Subtle strawman deception change away from this exact subject*
> DDD correctly simulated by HHH cannot possibly
> reach its own "return" instruction.
>
HHH can not correct emulate that input, so your statment is just
nonsense, and you prove that your concept of "logic" is likewise just
full of error.
The input doesn't contain the code for HHH, and thus HHH can not be the
required pure function required, as it hasn't been given the code to
emulate.
Sorry, You are just proving how must of a pathological liar you are.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 09:52 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl4ru$2rl0l$2@dont-email.me> |
| In reply to | #118102 |
On 5/8/2025 11:22 PM, Keith Thompson wrote:
> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>> On 5/8/25 10:23 PM, Keith Thompson wrote:
>>> Richard Damon <richard@damon-family.org> writes:
>>>> On 5/8/25 7:53 PM, olcott wrote:
>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point. For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> And thus not correctly simulatd.
>>>>
>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>> Perhaps I've missed something. I don't see anything in the above
>>> that
>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>> If we assume that HHH correctly simulates DDD, then the above code
>>> is
>>> equivalent to:
>>> void DDD()
>>> {
>>> DDD();
>>> return;
>>> }
>>> which is a trivial case of infinite recursion. As far as I can
>>> tell,
>>> assuming that DDD() is actually called at some point, neither the
>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>> can reach the return statement. Infinite recursion might either
>>> cause a stack overflow and a probable program crash, or an unending
>>> loop if the compiler implements tail call optimization.
>>> I see no contradiction, just an uninteresting case of infinite
>>> recursion, something that's well understood by anyone with a
>>> reasonable level of programming experience. (And it has nothing to
>>> do with the halting problem as far as I can tell, though of course
>>> olcott has discussed the halting problem elsewhere.)
>>> Richard, what am I missing?
>>>
>>
>> You are missing the equivocation he is using on what is "DDD()"
>>
>> First, he tries to define it as just the code of the function, and not
>> including any of the code that it calls. He does this so all the
>> various HHH that he talks about are given the "same" input.
>>
>> Then he tries to also say that when those functions look at DDD, they
>> can follow the memory chain to the functions that it calls, that
>> weren't actually part of the input.
>>
>> This means the "behavior" of his input isn't actually defined by the input.
>
> I haven't seen any of that in the posts to which I've recently replied
> (and I absolutely do not have the patience to read everything he's
> posted here).
>
> What I've seen in the articles to which I've recently replied has been
> just a strangely little C function and some claims about simulation.
> Viewed in isolation, I don't think any of that (again, ignoring the vast
> majority of what he's posted in this newsgroup) seems contradictory so far.
>
When viewed in isolation (as intended) there is no basis
for rebuttal. Richard refers to extraneous irrelevant
points in an attempt to deflect the conversation away
from the simple truth:
void DDD()
{
HHH(DDD);
return;
}
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction."
>> He has also, to get around other objections about what he is doing,
>> stipulated that his functions must be pure functions, and thus only
>> dependent on their direct input, other wise we can add the following
>> code to the beginning of HHH to make his statement false:
>
> I've seen no mention of pure functions in the posts to which I've
> recently replied.
>
> [...]
>
Dodging and weaving is Richard's style.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 12:57 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <fb2a56d7a42eb523ae94209ccd1b55f1017df421@i2pn2.org> |
| In reply to | #118138 |
On 5/9/25 10:52 AM, olcott wrote:
> On 5/8/2025 11:22 PM, Keith Thompson wrote:
>> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>>> On 5/8/25 10:23 PM, Keith Thompson wrote:
>>>> Richard Damon <richard@damon-family.org> writes:
>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>> We don't need to look at any of my code for me
>>>>>> to totally prove my point. For example when
>>>>>> the above DDD is correctly simulated by HHH
>>>>>> this simulated DDD cannot possibly reach its own
>>>>>> "return" instruction.
>>>>>
>>>>> And thus not correctly simulatd.
>>>>>
>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>> Perhaps I've missed something. I don't see anything in the above
>>>> that
>>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>> is
>>>> equivalent to:
>>>> void DDD()
>>>> {
>>>> DDD();
>>>> return;
>>>> }
>>>> which is a trivial case of infinite recursion. As far as I can
>>>> tell,
>>>> assuming that DDD() is actually called at some point, neither the
>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>> can reach the return statement. Infinite recursion might either
>>>> cause a stack overflow and a probable program crash, or an unending
>>>> loop if the compiler implements tail call optimization.
>>>> I see no contradiction, just an uninteresting case of infinite
>>>> recursion, something that's well understood by anyone with a
>>>> reasonable level of programming experience. (And it has nothing to
>>>> do with the halting problem as far as I can tell, though of course
>>>> olcott has discussed the halting problem elsewhere.)
>>>> Richard, what am I missing?
>>>>
>>>
>>> You are missing the equivocation he is using on what is "DDD()"
>>>
>>> First, he tries to define it as just the code of the function, and not
>>> including any of the code that it calls. He does this so all the
>>> various HHH that he talks about are given the "same" input.
>>>
>>> Then he tries to also say that when those functions look at DDD, they
>>> can follow the memory chain to the functions that it calls, that
>>> weren't actually part of the input.
>>>
>>> This means the "behavior" of his input isn't actually defined by the
>>> input.
>>
>> I haven't seen any of that in the posts to which I've recently replied
>> (and I absolutely do not have the patience to read everything he's
>> posted here).
>>
>> What I've seen in the articles to which I've recently replied has been
>> just a strangely little C function and some claims about simulation.
>> Viewed in isolation, I don't think any of that (again, ignoring the vast
>> majority of what he's posted in this newsgroup) seems contradictory so
>> far.
>>
>
> When viewed in isolation (as intended) there is no basis
> for rebuttal. Richard refers to extraneous irrelevant
> points in an attempt to deflect the conversation away
> from the simple truth:
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> "..DDD correctly simulated by HHH cannot
> possibly REACH its own "return" instruction."
So, which of my points are you refuting?
The input show does NOT contain the code for HHH, so if HHH is a pure
function, it can not emulate the input correctly.
If HHH doesn't need to be a pure function, then the HHH that begins:
int HHH(ptr D) {
static bool flag = 0;
if (flag) return 0;
flag = 1;
/* continue on with a correct emulation of the input, following the call
instruction it meets */
Will in fact, emulate its input DDD to the final return instruction.
>
>>> He has also, to get around other objections about what he is doing,
>>> stipulated that his functions must be pure functions, and thus only
>>> dependent on their direct input, other wise we can add the following
>>> code to the beginning of HHH to make his statement false:
>>
>> I've seen no mention of pure functions in the posts to which I've
>> recently replied.
>>
>> [...]
>>
>
> Dodging and weaving is Richard's style.
>
Nope, that is just you projecting. I have hit you so many times with
FACTUAL rebuttals that you are just staggering to avoid trying to
counter things you can not counter.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 09:59 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn117$3dv8d$2@dont-email.me> |
| In reply to | #118138 |
Op 09.mei.2025 om 16:52 schreef olcott:
> On 5/8/2025 11:22 PM, Keith Thompson wrote:
>> Richard Damon <news.x.richarddamon@xoxy.net> writes:
>>> On 5/8/25 10:23 PM, Keith Thompson wrote:
>>>> Richard Damon <richard@damon-family.org> writes:
>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>> We don't need to look at any of my code for me
>>>>>> to totally prove my point. For example when
>>>>>> the above DDD is correctly simulated by HHH
>>>>>> this simulated DDD cannot possibly reach its own
>>>>>> "return" instruction.
>>>>>
>>>>> And thus not correctly simulatd.
>>>>>
>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>> Perhaps I've missed something. I don't see anything in the above
>>>> that
>>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>> is
>>>> equivalent to:
>>>> void DDD()
>>>> {
>>>> DDD();
>>>> return;
>>>> }
>>>> which is a trivial case of infinite recursion. As far as I can
>>>> tell,
>>>> assuming that DDD() is actually called at some point, neither the
>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>> can reach the return statement. Infinite recursion might either
>>>> cause a stack overflow and a probable program crash, or an unending
>>>> loop if the compiler implements tail call optimization.
>>>> I see no contradiction, just an uninteresting case of infinite
>>>> recursion, something that's well understood by anyone with a
>>>> reasonable level of programming experience. (And it has nothing to
>>>> do with the halting problem as far as I can tell, though of course
>>>> olcott has discussed the halting problem elsewhere.)
>>>> Richard, what am I missing?
>>>>
>>>
>>> You are missing the equivocation he is using on what is "DDD()"
>>>
>>> First, he tries to define it as just the code of the function, and not
>>> including any of the code that it calls. He does this so all the
>>> various HHH that he talks about are given the "same" input.
>>>
>>> Then he tries to also say that when those functions look at DDD, they
>>> can follow the memory chain to the functions that it calls, that
>>> weren't actually part of the input.
>>>
>>> This means the "behavior" of his input isn't actually defined by the
>>> input.
>>
>> I haven't seen any of that in the posts to which I've recently replied
>> (and I absolutely do not have the patience to read everything he's
>> posted here).
>>
>> What I've seen in the articles to which I've recently replied has been
>> just a strangely little C function and some claims about simulation.
>> Viewed in isolation, I don't think any of that (again, ignoring the vast
>> majority of what he's posted in this newsgroup) seems contradictory so
>> far.
>>
>
> When viewed in isolation (as intended) there is no basis
> for rebuttal. Richard refers to extraneous irrelevant
> points in an attempt to deflect the conversation away
> from the simple truth:
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> "..DDD correctly simulated by HHH cannot
> possibly REACH its own "return" instruction."
>
Self contradicting sentence. A correct simulation will return to DDD
after which DDD reaches its 'return'. Only if HHH is incorrect and does
not reach its own 'return', the return of DDD will not be reached.
So, a correct simulation does not exist and this becomes a vacuous
statement.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-09 10:47 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvkffn$2m36t$4@dont-email.me> |
| In reply to | #118089 |
Op 09.mei.2025 om 04:23 schreef Keith Thompson:
> Richard Damon <richard@damon-family.org> writes:
>> On 5/8/25 7:53 PM, olcott wrote:
> [...]
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>> We don't need to look at any of my code for me
>>> to totally prove my point. For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>>
>> And thus not correctly simulatd.
>>
>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>
> Perhaps I've missed something. I don't see anything in the above that
> implies that HHH does not correctly simulate DDD. Richard, you've read
> far more of olcott's posts than I have, so perhaps you can clarify.
>
> If we assume that HHH correctly simulates DDD, then the above code is
> equivalent to:
>
> void DDD()
> {
> DDD();
> return;
> }
>
> which is a trivial case of infinite recursion. As far as I can tell,
> assuming that DDD() is actually called at some point, neither the
> outer execution of DDD nor the nested (simulated) execution of DDD
> can reach the return statement. Infinite recursion might either
> cause a stack overflow and a probable program crash, or an unending
> loop if the compiler implements tail call optimization.
>
> I see no contradiction, just an uninteresting case of infinite
> recursion, something that's well understood by anyone with a
> reasonable level of programming experience. (And it has nothing to
> do with the halting problem as far as I can tell, though of course
> olcott has discussed the halting problem elsewhere.)
>
> Richard, what am I missing?
>
What you are missing is that the next step of olcott is to say that when
he uses the 'exact same HHH, with only some extra code to abort the
simulation', it is still an infinite recursion. He does not understand
that adding the abort code makes the behaviour fundamentally different.
It is difficult for him to understand, because he refuses to use
different names for the different versions of HHH, because he dreams
that they are al exactly the same (except for small changes).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:48 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl84g$2rl0l$10@dont-email.me> |
| In reply to | #118121 |
On 5/9/2025 3:47 AM, Fred. Zwarts wrote:
> Op 09.mei.2025 om 04:23 schreef Keith Thompson:
>> Richard Damon <richard@damon-family.org> writes:
>>> On 5/8/25 7:53 PM, olcott wrote:
>> [...]
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return;
>>>> }
>>>> We don't need to look at any of my code for me
>>>> to totally prove my point. For example when
>>>> the above DDD is correctly simulated by HHH
>>>> this simulated DDD cannot possibly reach its own
>>>> "return" instruction.
>>>
>>> And thus not correctly simulatd.
>>>
>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>
>> Perhaps I've missed something. I don't see anything in the above that
>> implies that HHH does not correctly simulate DDD. Richard, you've read
>> far more of olcott's posts than I have, so perhaps you can clarify.
>>
>> If we assume that HHH correctly simulates DDD, then the above code is
>> equivalent to:
>>
>> void DDD()
>> {
>> DDD();
>> return;
>> }
>>
>> which is a trivial case of infinite recursion. As far as I can tell,
>> assuming that DDD() is actually called at some point, neither the
>> outer execution of DDD nor the nested (simulated) execution of DDD
>> can reach the return statement. Infinite recursion might either
>> cause a stack overflow and a probable program crash, or an unending
>> loop if the compiler implements tail call optimization.
>>
>> I see no contradiction, just an uninteresting case of infinite
>> recursion, something that's well understood by anyone with a
>> reasonable level of programming experience. (And it has nothing to
>> do with the halting problem as far as I can tell, though of course
>> olcott has discussed the halting problem elsewhere.)
>>
>> Richard, what am I missing?
>>
>
> What you are missing is that the next step of olcott is to say that when
> he uses the 'exact same HHH, with only some extra code to abort the
> simulation', it is still an infinite recursion. He does not understand
> that adding the abort code makes the behaviour fundamentally different.
When 1 or more statements of DDD are correctly simulated
by HHH this correctly simulated DDD cannot possibly reach
its own "return statement" final halt state.
Reaching the final halt state is the only correct
measure of halting. Thus the finite string input
to HHH(DDD) specifies a non-halting sequence of
configurations.
> It is difficult for him to understand, because he refuses to use
> different names for the different versions of HHH, because he dreams
> that they are al exactly the same (except for small changes).
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 13:00 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <c0b0db5de5c7f7ccb24b06d44108deb41fbde8dc@i2pn2.org> |
| In reply to | #118148 |
On 5/9/25 11:48 AM, olcott wrote:
> On 5/9/2025 3:47 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 04:23 schreef Keith Thompson:
>>> Richard Damon <richard@damon-family.org> writes:
>>>> On 5/8/25 7:53 PM, olcott wrote:
>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point. For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> And thus not correctly simulatd.
>>>>
>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>
>>> Perhaps I've missed something. I don't see anything in the above that
>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>
>>> If we assume that HHH correctly simulates DDD, then the above code is
>>> equivalent to:
>>>
>>> void DDD()
>>> {
>>> DDD();
>>> return;
>>> }
>>>
>>> which is a trivial case of infinite recursion. As far as I can tell,
>>> assuming that DDD() is actually called at some point, neither the
>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>> can reach the return statement. Infinite recursion might either
>>> cause a stack overflow and a probable program crash, or an unending
>>> loop if the compiler implements tail call optimization.
>>>
>>> I see no contradiction, just an uninteresting case of infinite
>>> recursion, something that's well understood by anyone with a
>>> reasonable level of programming experience. (And it has nothing to
>>> do with the halting problem as far as I can tell, though of course
>>> olcott has discussed the halting problem elsewhere.)
>>>
>>> Richard, what am I missing?
>>>
>>
>> What you are missing is that the next step of olcott is to say that
>> when he uses the 'exact same HHH, with only some extra code to abort
>> the simulation', it is still an infinite recursion. He does not
>> understand that adding the abort code makes the behaviour
>> fundamentally different.
>
> When 1 or more statements of DDD are correctly simulated
> by HHH this correctly simulated DDD cannot possibly reach
> its own "return statement" final halt state.
But HHH can not correctly emulate this input (the code of just DDD) past
the call instruction and remain a pure function, as it hasn't been given
that code.
If HHH doesn't need to be a pure function, then I have shown an HHH that
does what you say can't be done.
>
> Reaching the final halt state is the only correct
> measure of halting. Thus the finite string input
> to HHH(DDD) specifies a non-halting sequence of
> configurations.
Right, but that needs a full program as the input so it HAS behavior,
and non-halting is only implied if an actual correct emulation (that
doesn't abort) will never reach such a statement even after processing
an unbounded number of steps.
Stopping before then just shows "Not Yet Halted".
>
>> It is difficult for him to understand, because he refuses to use
>> different names for the different versions of HHH, because he dreams
>> that they are al exactly the same (except for small changes).
>
>
[toc] | [prev] | [next] | [standalone]
Page 6 of 32 — ← Prev page 1 … 4 5 [6] 7 8 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web