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 26 of 32 — ← Prev page 1 … 24 25 [26] 27 28 … 32 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-08 22:18 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <f4952d04fe70d0ffa87d6fc0792f31571be53adc@i2pn2.org> |
| In reply to | #118082 |
On 5/8/25 9:41 PM, olcott wrote:
> On 5/8/2025 8:15 PM, Richard Damon wrote:
>> On 5/8/25 7:59 PM, olcott wrote:
>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> If you are a competent C programmer then you
>>>>> know that DDD correctly simulated by HHH cannot
>>>>> possibly each its own "return" instruction.
>>>>
>>>> "cannot possibly each"?
>>>>
>>>> I am a competent C programmer (and I don't believe you can make
>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>> me nothing about what it's supposed to do. Without knowing what
>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>
>>>
>>> For the purpose of this discussion HHH is exactly
>>> what I said it is. It correctly simulates DDD.
>>
>> So you retract your stipulations?
>>
>>>
>>> We need not know anything else about HHH to
>>> know that DDD correctly simulated by HHH cannot
>>> possibly REACH its own "return" instruction.
>>
>> Excpet that then you can't change HHH to make it the decider, as that
>> changes the code of the program to be decided.
>>
>
> *We can't get to that step until after this step is complete*
> So you agree with my above paragraph:
>
> We need not know anything else about HHH to
> know that DDD correctly simulated by HHH cannot
> possibly REACH its own "return" instruction.
>
>
Excpet that as pointed out, your DDD is impossible to correctly
simulate, as it doesn't include the code for the HHH that it calls, and
thus any simulator that tries to simulate it finds undefined behavior,
as it needs to access that which it isn't allowed to access and meet the
requriment to be a pure funciton.
All you are doing is proving you don't understand the basic terms you
are using.
If fact, you have admitted to enough details of what you are doing to
totally disquiarlify all your work, as you admit that you consider
neither HHH or DD to be programs, just C functions, which are not
categories that the field talks about.
Sorry, you are just proving you are too stupid to understand the
elementary basics of the field you claim to be making great discoveries
in, when in fact you prove that you are just lying about everything.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 18:30 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87seled0zy.fsf@nosuchdomain.example.com> |
| In reply to | #118069 |
olcott <polcott333@gmail.com> writes:
> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>> [...]
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> If you are a competent C programmer then you
>>> know that DDD correctly simulated by HHH cannot
>>> possibly each its own "return" instruction.
>> "cannot possibly each"?
>> I am a competent C programmer (and I don't believe you can make
>> the same claim). I don't know what HHH is. The name "HHH" tells
>> me nothing about what it's supposed to do. Without knowing what
>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>
>
> For the purpose of this discussion HHH is exactly
> what I said it is. It correctly simulates DDD.
Does HHH correctly simulate DDD *and do nothing else*?
Does HHH correctly simulate *every* function whose address is passed
to it? Must the passed function be one that takes no arguments
and does not return a value?
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
> We need not know anything else about HHH to
> know that DDD correctly simulated by HHH cannot
> possibly REACH its own "return" instruction.
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
void DDD(void) {
DDD();
return;
}
Then the return statement (which is unnecessary anyway) will never be
reached. In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
This conclusion relies on my understanding of what you've said about
your code, which I consider to be unreliable.
No doubt you believe that there is some significance to the
apparent fact that the return statement will never be reached,
assuming that's a correct and relevant conclusion. I don't know
what that significance might be.
>> The return statement is harmless but unnecessary.
>> "void DDD()" should be "void DDD(void)" (unless you're using C23,
>> but
>> we've established that your not). Why did you choose to use empty
>> parentheses? (If you answer nothing else, please answer that.)
>
> I am using Microsoft Visual Studio 2017.
> It compiled cleanly.
Microsoft Visual Studio 2017 is not a conforming C compiler. It has
options that cause it to attempt to be one. You are feeding it
incorrect code, and it's failing to diagnose it. Your code would
also compile cleanly if you fixed the errors. *Correct* C code
might be part of a more valid argument for your claims than the
one you're making. *Incorrect* C code hurts your credibility,
something I thought you cared about. (Using C at all is an odd
choice, but I won't get into that.)
If there were a refutation of the proof of the insolubility of the
Halting Problem, I do not believe it would really depend on the
vagaries of the 2017 version of Microsoft Visual Studio.
Oh, and I'm very likely to tire of this discussion very soon, so
think carefully if you want to make a point that you'd like me to
pay attention to. Among other things, your repeated insults against
people who dare to disagree with you do not motivate me to engage
with you. I probably shouldn't have jumped into this discussion,
but the noise level here is already so high I don't feel very bad
about it.
--
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:13 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjobj$28g5i$11@dont-email.me> |
| In reply to | #118079 |
On 5/8/2025 8:30 PM, Keith Thompson wrote:
> olcott <polcott333@gmail.com> writes:
>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>> [...]
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return;
>>>> }
>>>>
>>>> If you are a competent C programmer then you
>>>> know that DDD correctly simulated by HHH cannot
>>>> possibly each its own "return" instruction.
>>> "cannot possibly each"?
>>> I am a competent C programmer (and I don't believe you can make
>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>> me nothing about what it's supposed to do. Without knowing what
>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>
>>
>> For the purpose of this discussion HHH is exactly
>> what I said it is. It correctly simulates DDD.
>
> Does HHH correctly simulate DDD *and do nothing else*?
>
> Does HHH correctly simulate *every* function whose address is passed
> to it? Must the passed function be one that takes no arguments
> and does not return a value?
>
> Can HHH just *call* the function whose address is passed to it?
> If it's a correct simulation, there should be no difference between
> calling the function and "correctly simulating" it.
>
> My knowledge of C tells me nothing about *how* HHH might simulate
> DDD.
>
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
>> We need not know anything else about HHH to
>> know that DDD correctly simulated by HHH cannot
>> possibly REACH its own "return" instruction.
>
> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
> does nothing else, your code would be equivalent to this:
>
> void DDD(void) {
> DDD();
> return;
> }
>
Exactly. None of these people on comp.theory could
get that even after three years.
> Then the return statement (which is unnecessary anyway) will never be
> reached.
It is only there to mark a final halt state.
> In practice, the program will likely crash due to a stack
> overflow, unless the compiler implements tail-call optimization, in
> which case the program might just run forever -- which also means the
> unnecessary return statement will never be reached.
>
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.
> This conclusion relies on my understanding of what you've said about
> your code, which I consider to be unreliable.
>
I am not even talking about my code. I am
talking about the purely hypothetical code
that you just agreed to.
> No doubt you believe that there is some significance to the
> apparent fact that the return statement will never be reached,
> assuming that's a correct and relevant conclusion. I don't know
> what that significance might be.
>
I will tell you that later after you understand
some prerequisite ideas first.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The same thing that applied to DDD equally
applies to the more complicated DD.
When 1 or more instructions of DD are correctly
simulated by HHH the correctly simulated DD
cannot possibly get past its call to HHH(DD).
Thus DD also never reaches its "return" instruction.
>>> The return statement is harmless but unnecessary.
>>> "void DDD()" should be "void DDD(void)" (unless you're using C23,
>>> but
>>> we've established that your not). Why did you choose to use empty
>>> parentheses? (If you answer nothing else, please answer that.)
>>
>> I am using Microsoft Visual Studio 2017.
>> It compiled cleanly.
>
> Microsoft Visual Studio 2017 is not a conforming C compiler. It has
> options that cause it to attempt to be one. You are feeding it
> incorrect code, and it's failing to diagnose it. Your code would
> also compile cleanly if you fixed the errors.
> *Correct* C code
> might be part of a more valid argument for your claims than the
> one you're making. *Incorrect* C code hurts your credibility,
> something I thought you cared about. (Using C at all is an odd
> choice, but I won't get into that.)
>
> If there were a refutation of the proof of the insolubility of the
> Halting Problem, I do not believe it would really depend on the
> vagaries of the 2017 version of Microsoft Visual Studio.
>
> Oh, and I'm very likely to tire of this discussion very soon, so
> think carefully if you want to make a point that you'd like me to
> pay attention to. Among other things, your repeated insults against
> people who dare to disagree with you do not motivate me to engage
> with you. I probably shouldn't have jumped into this discussion,
> but the noise level here is already so high I don't feel very bad
> about it.
>
--
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-08 22:35 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <242c1dc85f5b5f24b435bd2aa9ef9c07f24b1455@i2pn2.org> |
| In reply to | #118086 |
On 5/8/25 10:13 PM, olcott wrote:
> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> If you are a competent C programmer then you
>>>>> know that DDD correctly simulated by HHH cannot
>>>>> possibly each its own "return" instruction.
>>>> "cannot possibly each"?
>>>> I am a competent C programmer (and I don't believe you can make
>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>> me nothing about what it's supposed to do. Without knowing what
>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>
>>>
>>> For the purpose of this discussion HHH is exactly
>>> what I said it is. It correctly simulates DDD.
>>
>> Does HHH correctly simulate DDD *and do nothing else*?
>>
>> Does HHH correctly simulate *every* function whose address is passed
>> to it? Must the passed function be one that takes no arguments
>> and does not return a value?
>>
>> Can HHH just *call* the function whose address is passed to it?
>> If it's a correct simulation, there should be no difference between
>> calling the function and "correctly simulating" it.
>>
>> My knowledge of C tells me nothing about *how* HHH might simulate
>> DDD.
>>
>
> HHH can only simulate a function that take no arguments
> and has no return value. HHH also simulates the entire
> chain of functions that this function calls. These can
> take arguments or not and have return values or not.
>
> Thus HHH ends up simulating itself (and everything
> that HHH calls) simulating DDD in an infinite
> sequence of recursive emulation until OOM error.
>
>>> We need not know anything else about HHH to
>>> know that DDD correctly simulated by HHH cannot
>>> possibly REACH its own "return" instruction.
>>
>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>> does nothing else, your code would be equivalent to this:
>>
>> void DDD(void) {
>> DDD();
>> return;
>> }
>>
>
> Exactly. None of these people on comp.theory could
> get that even after three years.
>
>> Then the return statement (which is unnecessary anyway) will never be
>> reached.
>
> It is only there to mark a final halt state.
>
>> In practice, the program will likely crash due to a stack
>> overflow, unless the compiler implements tail-call optimization, in
>> which case the program might just run forever -- which also means the
>> unnecessary return statement will never be reached.
>>
>
> Yes you totally have this correctly.
> None of the dozens of comp.theory people could
> ever achieve that level of understanding even
> after three years. That is why I needed to post
> on comp.lang.c.
And thus fails to be the pure function you agreed it needed to be.
>
>> This conclusion relies on my understanding of what you've said about
>> your code, which I consider to be unreliable.
>>
>
> I am not even talking about my code. I am
> talking about the purely hypothetical code
> that you just agreed to.
Based on assuming the code violates the rules you say it must follow.
That is a self-contradiction.
>
>> No doubt you believe that there is some significance to the
>> apparent fact that the return statement will never be reached,
>> assuming that's a correct and relevant conclusion. I don't know
>> what that significance might be.
>>
>
> I will tell you that later after you understand
> some prerequisite ideas first.
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> The same thing that applied to DDD equally
> applies to the more complicated DD.
>
> When 1 or more instructions of DD are correctly
> simulated by HHH the correctly simulated DD
> cannot possibly get past its call to HHH(DD).
> Thus DD also never reaches its "return" instruction.
But we can't correctly emulate the call insturciton of DD or DDD as the
target is not part of the input, and thus any emulator that looks there
has violate the requirements of being a pure function that you agreed to.
So, if x is a square circle then x is correct. Sorry, that isn't valid
logic.
All you are doing is proving you don't understand what you are talking
abour.
Until you explain why this isn't a violation of your stipulations, we
can't move past this point.
Your input is just INVALID by your own rules, as it CAN'T be correctly
emulated, as it is incomplete.
>
>>>> The return statement is harmless but unnecessary.
>>>> "void DDD()" should be "void DDD(void)" (unless you're using C23,
>>>> but
>>>> we've established that your not). Why did you choose to use empty
>>>> parentheses? (If you answer nothing else, please answer that.)
>>>
>>> I am using Microsoft Visual Studio 2017.
>>> It compiled cleanly.
>>
>> Microsoft Visual Studio 2017 is not a conforming C compiler. It has
>> options that cause it to attempt to be one. You are feeding it
>> incorrect code, and it's failing to diagnose it. Your code would
>> also compile cleanly if you fixed the errors. *Correct* C code
>> might be part of a more valid argument for your claims than the
>> one you're making. *Incorrect* C code hurts your credibility,
>> something I thought you cared about. (Using C at all is an odd
>> choice, but I won't get into that.)
>>
>> If there were a refutation of the proof of the insolubility of the
>> Halting Problem, I do not believe it would really depend on the
>> vagaries of the 2017 version of Microsoft Visual Studio.
>>
>> Oh, and I'm very likely to tire of this discussion very soon, so
>> think carefully if you want to make a point that you'd like me to
>> pay attention to. Among other things, your repeated insults against
>> people who dare to disagree with you do not motivate me to engage
>> with you. I probably shouldn't have jumped into this discussion,
>> but the noise level here is already so high I don't feel very bad
>> about it.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-05-09 04:14 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjrv2$2gnq4$1@dont-email.me> |
| In reply to | #118086 |
On 09/05/2025 03:13, olcott wrote:
> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> If you are a competent C programmer then you
>>>>> know that DDD correctly simulated by HHH cannot
>>>>> possibly each its own "return" instruction.
>>>> "cannot possibly each"?
>>>> I am a competent C programmer (and I don't believe you can make
>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>> me nothing about what it's supposed to do. Without knowing what
>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>
>>>
>>> For the purpose of this discussion HHH is exactly
>>> what I said it is. It correctly simulates DDD.
>>
>> Does HHH correctly simulate DDD *and do nothing else*?
>>
>> Does HHH correctly simulate *every* function whose address is passed
>> to it? Must the passed function be one that takes no arguments
>> and does not return a value?
>>
>> Can HHH just *call* the function whose address is passed to it?
>> If it's a correct simulation, there should be no difference between
>> calling the function and "correctly simulating" it.
>>
>> My knowledge of C tells me nothing about *how* HHH might simulate
>> DDD.
>>
>
> HHH can only simulate a function that take no arguments
> and has no return value. HHH also simulates the entire
> chain of functions that this function calls. These can
> take arguments or not and have return values or not.
>
> Thus HHH ends up simulating itself (and everything
> that HHH calls) simulating DDD in an infinite
> sequence of recursive emulation until OOM error.
>
>>> We need not know anything else about HHH to
>>> know that DDD correctly simulated by HHH cannot
>>> possibly REACH its own "return" instruction.
>>
>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>> does nothing else, your code would be equivalent to this:
>>
>> void DDD(void) {
>> DDD();
>> return;
>> }
>>
>
> Exactly. None of these people on comp.theory could
> get that even after three years.
>
PO is being quite deceptive here.
His simulation is in fact a single-stepped x86 instruction simulation, where the stepping of each
x86 instruction is under the HHH's control. HHH can continue stepping the simulation until its
target returns, in which case the situation is logically just like direct call, as you have
described. Or HHH could step just 3 x86 instructions (say) and then decide to return (aka "abort"
its simulation). Let's call that /partial/ simulation in contrast with /full/ simulation which
you've been supposing.
Oh, did he forget to mention that? Anyhow, in the general case with /partial/ simulation there is
more to think about as it is obvioudly /not/ logically equivalent to direct execution.
Oh, and obviously everybody in comp.theory gets all this. The problem is with PO and his inability
to communicate his ideas properly and his inability to understand what other people understand or
disagree with. He goes on for months/years claiming people don't understand things they agree with,
but it's down to his duffer wording...
>> Then the return statement (which is unnecessary anyway) will never be
>> reached.
>
> It is only there to mark a final halt state.
>
>> In practice, the program will likely crash due to a stack
>> overflow, unless the compiler implements tail-call optimization, in
>> which case the program might just run forever -- which also means the
>> unnecessary return statement will never be reached.
>>
>
> Yes you totally have this correctly.
> None of the dozens of comp.theory people could
> ever achieve that level of understanding even
> after three years. That is why I needed to post
> on comp.lang.c.
Everybody on comp.theory understands this much. PO's plan is that when he goes elsewhere he can
start with noobies and trick them into agreeing with certain "wordings" by not explaining relevent
context for his questions. Then he goes back to comp.theory and triumphantly claims support from
elsewhere, proving to himself that comp.theory posters are all idiots. :)
So beware!
>
>> This conclusion relies on my understanding of what you've said about
>> your code, which I consider to be unreliable.
Hmm, did PO make it clear that when he says
"..DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction."
he is not talking about whether "DDD halts"? [I.e. halts when run directly from main() outside of a
simulator.] No, what he is talking about is whether the /step-by-step partial simuation/ of DDD
performed by HHH proceeds as far as DDD returning. Don't forget - HHH is allowed to simply stop
simulating and return whenever it likes! Maybe it only wants to simulate 48 x86 instructions, or
just 1, or maybe it's in for the long haul and simulates until DDD returns [if it ever does].
So you need to re-analyse everything you've said with this new information that PO forgot to make
clear.
Regards,
Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 22:34 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjt4b$2go7p$1@dont-email.me> |
| In reply to | #118098 |
On 5/8/2025 10:14 PM, Mike Terry wrote:
> On 09/05/2025 03:13, olcott wrote:
>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> If you are a competent C programmer then you
>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>> possibly each its own "return" instruction.
>>>>> "cannot possibly each"?
>>>>> I am a competent C programmer (and I don't believe you can make
>>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>>> me nothing about what it's supposed to do. Without knowing what
>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>
>>>>
>>>> For the purpose of this discussion HHH is exactly
>>>> what I said it is. It correctly simulates DDD.
>>>
>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>
>>> Does HHH correctly simulate *every* function whose address is passed
>>> to it? Must the passed function be one that takes no arguments
>>> and does not return a value?
>>>
>>> Can HHH just *call* the function whose address is passed to it?
>>> If it's a correct simulation, there should be no difference between
>>> calling the function and "correctly simulating" it.
>>>
>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>> DDD.
>>>
>>
>> HHH can only simulate a function that take no arguments
>> and has no return value. HHH also simulates the entire
>> chain of functions that this function calls. These can
>> take arguments or not and have return values or not.
>>
>> Thus HHH ends up simulating itself (and everything
>> that HHH calls) simulating DDD in an infinite
>> sequence of recursive emulation until OOM error.
>>
>>>> We need not know anything else about HHH to
>>>> know that DDD correctly simulated by HHH cannot
>>>> possibly REACH its own "return" instruction.
>>>
>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>> does nothing else, your code would be equivalent to this:
>>>
>>> void DDD(void) {
>>> DDD();
>>> return;
>>> }
>>>
>>
>> Exactly. None of these people on comp.theory could
>> get that even after three years.
>>
>
> PO is being quite deceptive here.
>
I am only referring to the above hypothetical HHH/DDD pair.
Everyone here has consistently denied that when DDD is
correctly simulated by HHH that this DDD cannot possibly
reach its "return" instruction (final halt state).
> His simulation is in fact a single-stepped x86 instruction simulation,
> where the stepping of each x86 instruction is under the HHH's control.
> HHH can continue stepping the simulation until its target returns, in
> which case the situation is logically just like direct call, as you have
> described. Or HHH could step just 3 x86 instructions (say) and then
> decide to return (aka "abort" its simulation). Let's call that /
> partial/ simulation in contrast with /full/ simulation which you've been
> supposing.
>
A full simulation of infinite recursion?
I am only doing one tiny idea at a time here.
> Oh, did he forget to mention that? Anyhow, in the general case with /
> partial/ simulation there is more to think about as it is obvioudly /
> not/ logically equivalent to direct execution.
>
That is changing the subject away from
DDD correctly simulated by HHH.
>
> Oh, and obviously everybody in comp.theory gets all this. The problem
> is with PO and his inability to communicate his ideas properly and his
> inability to understand what other people understand or disagree with.
> He goes on for months/years claiming people don't understand things they
> agree with, but it's down to his duffer wording...
>
>>> Then the return statement (which is unnecessary anyway) will never be
>>> reached.
>>
>> It is only there to mark a final halt state.
>>
>>> In practice, the program will likely crash due to a stack
>>> overflow, unless the compiler implements tail-call optimization, in
>>> which case the program might just run forever -- which also means the
>>> unnecessary return statement will never be reached.
>>>
>>
>> Yes you totally have this correctly.
>> None of the dozens of comp.theory people could
>> ever achieve that level of understanding even
>> after three years. That is why I needed to post
>> on comp.lang.c.
>
> Everybody on comp.theory understands this much.
No one here ever agreed that when 1 or more
instructions of DDD are correctly simulated
by HHH that DDD cannot possibly reach its
own "return" instruction.
Everyone has found one excuse or another to
deny this.
> PO's plan is that when
> he goes elsewhere he can start with noobies and trick them into agreeing
> with certain "wordings" by not explaining relevent context for his
> questions. Then he goes back to comp.theory and triumphantly claims
> support from elsewhere, proving to himself that comp.theory posters are
> all idiots. :)
>
> So beware!
>
>>
>>> This conclusion relies on my understanding of what you've said about
>>> your code, which I consider to be unreliable.
>
> Hmm, did PO make it clear that when he says
>
> "..DDD correctly simulated by HHH cannot
> possibly REACH its own "return" instruction."
>
Unless we go one tiny step at a time everyone
permanently leaps to a false conclusion and stays
there.
> he is not talking about whether "DDD halts"? [I.e. halts when run
> directly from main() outside of a simulator.] No, what he is talking
> about is whether the /step-by-step partial simuation/ of DDD performed
> by HHH proceeds as far as DDD returning.
When 1 or more steps of DDD are correctly simulated
by HHH the simulated DDD cannot possibly reach its
"return" instruction (final halt state).
No one here has agreed to that. Not in several
years of coaxing and elaboration.
> Don't forget - HHH is allowed
> to simply stop simulating and return whenever it likes! Maybe it only
> wants to simulate 48 x86 instructions, or just 1, or maybe it's in for
> the long haul and simulates until DDD returns [if it ever does].
>
When 1 or more steps of DDD are correctly simulated
by HHH the simulated DDD cannot possibly reach its
"return" instruction (final halt state).
remains a verified fact.
> So you need to re-analyse everything you've said with this new
> information that PO forgot to make clear.
>
>
> Regards,
> Mike.
>
--
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 | joes <noreply@example.org> |
|---|---|
| Date | 2025-05-09 09:48 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <2b99f70ab35ec939ead52ef88135a2f39e141ad2@i2pn2.org> |
| In reply to | #118099 |
Am Thu, 08 May 2025 22:34:35 -0500 schrieb olcott: > On 5/8/2025 10:14 PM, Mike Terry wrote: >> On 09/05/2025 03:13, olcott wrote: >>> On 5/8/2025 8:30 PM, Keith Thompson wrote: >>>> olcott <polcott333@gmail.com> writes: >>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote: >>>>>> olcott <polcott333@gmail.com> writes: >> His simulation is in fact a single-stepped x86 instruction simulation, >> where the stepping of each x86 instruction is under the HHH's control. >> HHH can continue stepping the simulation until its target returns, in >> which case the situation is logically just like direct call, as you >> have described. Or HHH could step just 3 x86 instructions (say) and >> then decide to return (aka "abort" its simulation). Let's call that / >> partial/ simulation in contrast with /full/ simulation which you've >> been supposing. > A full simulation of infinite recursion? > I am only doing one tiny idea at a time here. Yeah, so not a full simulation. >>>> In practice, the program will likely crash due to a stack overflow, >>>> unless the compiler implements tail-call optimization, in which case >>>> the program might just run forever -- which also means the >>>> unnecessary return statement will never be reached. >>> Yes you totally have this correctly. >>> None of the dozens of comp.theory people could ever achieve that level >>> of understanding even after three years. That is why I needed to post >>> on comp.lang.c. >> Everybody on comp.theory understands this much. > No one here ever agreed that when 1 or more instructions of DDD are > correctly simulated by HHH that DDD cannot possibly reach its own > "return" instruction. That's wrong as written. HHH cannot simulate DDD returning in a finite number of instructions, it takes infinitely many. >>>> This conclusion relies on my understanding of what you've said about >>>> your code, which I consider to be unreliable. >> >> Hmm, did PO make it clear that when he says >> "..DDD correctly simulated by HHH cannot >> possibly REACH its own "return" instruction." >> he is not talking about whether "DDD halts"? [I.e. halts when run >> directly from main() outside of a simulator.] No, what he is talking >> about is whether the /step-by-step partial simuation/ of DDD performed >> by HHH proceeds as far as DDD returning. > > When 1 or more steps of DDD are correctly simulated by HHH the simulated > DDD cannot possibly reach its "return" instruction (final halt state). > No one here has agreed to that. Not in several years of coaxing and > elaboration. It's true for a finite number. Aborting is not correct simulation, even if HHH did return that DDD halts. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:08 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl5pp$2rl0l$4@dont-email.me> |
| In reply to | #118127 |
On 5/9/2025 4:48 AM, joes wrote: > Am Thu, 08 May 2025 22:34:35 -0500 schrieb olcott: >> On 5/8/2025 10:14 PM, Mike Terry wrote: >>> On 09/05/2025 03:13, olcott wrote: >>>> On 5/8/2025 8:30 PM, Keith Thompson wrote: >>>>> olcott <polcott333@gmail.com> writes: >>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote: >>>>>>> olcott <polcott333@gmail.com> writes: > >>> His simulation is in fact a single-stepped x86 instruction simulation, >>> where the stepping of each x86 instruction is under the HHH's control. >>> HHH can continue stepping the simulation until its target returns, in >>> which case the situation is logically just like direct call, as you >>> have described. Or HHH could step just 3 x86 instructions (say) and >>> then decide to return (aka "abort" its simulation). Let's call that / >>> partial/ simulation in contrast with /full/ simulation which you've >>> been supposing. >> A full simulation of infinite recursion? >> I am only doing one tiny idea at a time here. > Yeah, so not a full simulation. > Didn't you know this? It is incorrect for a simulating termination analyzer to do a full simulation of a non-halting input. >>>>> In practice, the program will likely crash due to a stack overflow, >>>>> unless the compiler implements tail-call optimization, in which case >>>>> the program might just run forever -- which also means the >>>>> unnecessary return statement will never be reached. >>>> Yes you totally have this correctly. >>>> None of the dozens of comp.theory people could ever achieve that level >>>> of understanding even after three years. That is why I needed to post >>>> on comp.lang.c. >>> Everybody on comp.theory understands this much. >> No one here ever agreed that when 1 or more instructions of DDD are >> correctly simulated by HHH that DDD cannot possibly reach its own >> "return" instruction. > That's wrong as written. HHH cannot simulate DDD returning in a > finite number of instructions, it takes infinitely many. > HHH can simulate 1 or more instructions of DDD, this is not actually logically impossible. When HHH does correctly simulate 1 or more instructions of DDD then DDD never reaches its "return statement" final halt state. >>>>> This conclusion relies on my understanding of what you've said about >>>>> your code, which I consider to be unreliable. >>> >>> Hmm, did PO make it clear that when he says >>> "..DDD correctly simulated by HHH cannot >>> possibly REACH its own "return" instruction." >>> he is not talking about whether "DDD halts"? [I.e. halts when run >>> directly from main() outside of a simulator.] No, what he is talking >>> about is whether the /step-by-step partial simuation/ of DDD performed >>> by HHH proceeds as far as DDD returning. >> >> When 1 or more steps of DDD are correctly simulated by HHH the simulated >> DDD cannot possibly reach its "return" instruction (final halt state). >> No one here has agreed to that. Not in several years of coaxing and >> elaboration. > It's true for a finite number. Aborting is not correct simulation, even > if HHH did return that DDD halts. > Didn't you know this? It is incorrect for a simulating termination analyzer to do a full simulation of a non-halting input. -- 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 | joes <noreply@example.org> |
|---|---|
| Date | 2025-05-09 15:47 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <e489448191eedf4b7ada69d2d59af088a4dc6711@i2pn2.org> |
| In reply to | #118140 |
Am Fri, 09 May 2025 10:08:40 -0500 schrieb olcott: > On 5/9/2025 4:48 AM, joes wrote: >> Am Thu, 08 May 2025 22:34:35 -0500 schrieb olcott: >>> On 5/8/2025 10:14 PM, Mike Terry wrote: >>>> On 09/05/2025 03:13, olcott wrote: >>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote: >>>>>> olcott <polcott333@gmail.com> writes: >>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote: >>>>>>>> olcott <polcott333@gmail.com> writes: >> >>>> His simulation is in fact a single-stepped x86 instruction >>>> simulation, where the stepping of each x86 instruction is under the >>>> HHH's control. HHH can continue stepping the simulation until its >>>> target returns, in which case the situation is logically just like >>>> direct call, as you have described. Or HHH could step just 3 x86 >>>> instructions (say) and then decide to return (aka "abort" its >>>> simulation). Let's call that / >>>> partial/ simulation in contrast with /full/ simulation which you've >>>> been supposing. >>> A full simulation of infinite recursion? >>> I am only doing one tiny idea at a time here. >> Yeah, so not a full simulation. > Didn't you know this? > It is incorrect for a simulating termination analyzer to do a full > simulation of a non-halting input. > >>>>>> In practice, the program will likely crash due to a stack overflow, >>>>>> unless the compiler implements tail-call optimization, in which >>>>>> case the program might just run forever -- which also means the >>>>>> unnecessary return statement will never be reached. >>>>> Yes you totally have this correctly. >>>>> None of the dozens of comp.theory people could ever achieve that >>>>> level of understanding even after three years. That is why I needed >>>>> to post on comp.lang.c. >>>> Everybody on comp.theory understands this much. >>> No one here ever agreed that when 1 or more instructions of DDD are >>> correctly simulated by HHH that DDD cannot possibly reach its own >>> "return" instruction. >> That's wrong as written. HHH cannot simulate DDD returning in a finite >> number of instructions, it takes infinitely many. > HHH can simulate 1 or more instructions of DDD, > this is not actually logically impossible. > When HHH does correctly simulate 1 or more instructions of DDD then DDD > never reaches its "return statement" final halt state. HHH simulates DDD returning only in an infinite number of steps. >>>>>> This conclusion relies on my understanding of what you've said >>>>>> about your code, which I consider to be unreliable. >>>> >>>> Hmm, did PO make it clear that when he says >>>> "..DDD correctly simulated by HHH cannot >>>> possibly REACH its own "return" instruction." >>>> he is not talking about whether "DDD halts"? [I.e. halts when run >>>> directly from main() outside of a simulator.] No, what he is talking >>>> about is whether the /step-by-step partial simuation/ of DDD >>>> performed by HHH proceeds as far as DDD returning. >>> >>> When 1 or more steps of DDD are correctly simulated by HHH the >>> simulated DDD cannot possibly reach its "return" instruction (final >>> halt state). No one here has agreed to that. Not in several years of >>> coaxing and elaboration. > >> It's true for a finite number. Aborting is not correct simulation, even >> if HHH did return that DDD halts. > It is incorrect for a simulating termination analyzer to do a full > simulation of a non-halting input. Yes, that is why HHH cannot both be a decider and simulate correctly. And then it goes further and guesses wrongly. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:57 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl8kc$2rl0l$13@dont-email.me> |
| In reply to | #118147 |
On 5/9/2025 10:47 AM, joes wrote:
> Am Fri, 09 May 2025 10:08:40 -0500 schrieb olcott:
>> On 5/9/2025 4:48 AM, joes wrote:
>>> Am Thu, 08 May 2025 22:34:35 -0500 schrieb olcott:
>>>> On 5/8/2025 10:14 PM, Mike Terry wrote:
>>>>> On 09/05/2025 03:13, olcott wrote:
>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>>>>> olcott <polcott333@gmail.com> writes:
>>>
>>>>> His simulation is in fact a single-stepped x86 instruction
>>>>> simulation, where the stepping of each x86 instruction is under the
>>>>> HHH's control. HHH can continue stepping the simulation until its
>>>>> target returns, in which case the situation is logically just like
>>>>> direct call, as you have described. Or HHH could step just 3 x86
>>>>> instructions (say) and then decide to return (aka "abort" its
>>>>> simulation). Let's call that /
>>>>> partial/ simulation in contrast with /full/ simulation which you've
>>>>> been supposing.
>>>> A full simulation of infinite recursion?
>>>> I am only doing one tiny idea at a time here.
>>> Yeah, so not a full simulation.
>> Didn't you know this?
>> It is incorrect for a simulating termination analyzer to do a full
>> simulation of a non-halting input.
>>
>>>>>>> In practice, the program will likely crash due to a stack overflow,
>>>>>>> unless the compiler implements tail-call optimization, in which
>>>>>>> case the program might just run forever -- which also means the
>>>>>>> unnecessary return statement will never be reached.
>>>>>> Yes you totally have this correctly.
>>>>>> None of the dozens of comp.theory people could ever achieve that
>>>>>> level of understanding even after three years. That is why I needed
>>>>>> to post on comp.lang.c.
>>>>> Everybody on comp.theory understands this much.
>>>> No one here ever agreed that when 1 or more instructions of DDD are
>>>> correctly simulated by HHH that DDD cannot possibly reach its own
>>>> "return" instruction.
>>> That's wrong as written. HHH cannot simulate DDD returning in a finite
>>> number of instructions, it takes infinitely many.
>> HHH can simulate 1 or more instructions of DDD,
>> this is not actually logically impossible.
>> When HHH does correctly simulate 1 or more instructions of DDD then DDD
>> never reaches its "return statement" final halt state.
> HHH simulates DDD returning only in an infinite number of steps.
>
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
--
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 14:22 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <71c01e4f0d1f5bc97bfa14ef290f774afee1cca8@i2pn2.org> |
| In reply to | #118140 |
On 5/9/25 11:08 AM, olcott wrote: > On 5/9/2025 4:48 AM, joes wrote: >> Am Thu, 08 May 2025 22:34:35 -0500 schrieb olcott: >>> On 5/8/2025 10:14 PM, Mike Terry wrote: >>>> On 09/05/2025 03:13, olcott wrote: >>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote: >>>>>> olcott <polcott333@gmail.com> writes: >>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote: >>>>>>>> olcott <polcott333@gmail.com> writes: >> >>>> His simulation is in fact a single-stepped x86 instruction simulation, >>>> where the stepping of each x86 instruction is under the HHH's control. >>>> HHH can continue stepping the simulation until its target returns, in >>>> which case the situation is logically just like direct call, as you >>>> have described. Or HHH could step just 3 x86 instructions (say) and >>>> then decide to return (aka "abort" its simulation). Let's call that / >>>> partial/ simulation in contrast with /full/ simulation which you've >>>> been supposing. >>> A full simulation of infinite recursion? >>> I am only doing one tiny idea at a time here. >> Yeah, so not a full simulation. >> > > Didn't you know this? > It is incorrect for a simulating termination analyzer > to do a full simulation of a non-halting input. > >>>>>> In practice, the program will likely crash due to a stack overflow, >>>>>> unless the compiler implements tail-call optimization, in which case >>>>>> the program might just run forever -- which also means the >>>>>> unnecessary return statement will never be reached. >>>>> Yes you totally have this correctly. >>>>> None of the dozens of comp.theory people could ever achieve that level >>>>> of understanding even after three years. That is why I needed to post >>>>> on comp.lang.c. >>>> Everybody on comp.theory understands this much. >>> No one here ever agreed that when 1 or more instructions of DDD are >>> correctly simulated by HHH that DDD cannot possibly reach its own >>> "return" instruction. >> That's wrong as written. HHH cannot simulate DDD returning in a >> finite number of instructions, it takes infinitely many. >> > > HHH can simulate 1 or more instructions of DDD, > this is not actually logically impossible. But it can't emulate past the call HHH instruction and remain a pure function as you have defined that code to not be in the input. > > When HHH does correctly simulate 1 or more > instructions of DDD then DDD never reaches its > "return statement" final halt state. WHich it can't do as your input definition makes it impossible to do. You have been told this many times, and haven't fixed it or clairified you change of definition and showing what you are actually meaning by your "input" All you are doing is insisting that you rule-breaking funciton is following the rules, thus making you just a pathetic liar. > >>>>>> This conclusion relies on my understanding of what you've said about >>>>>> your code, which I consider to be unreliable. >>>> >>>> Hmm, did PO make it clear that when he says >>>> "..DDD correctly simulated by HHH cannot >>>> possibly REACH its own "return" instruction." >>>> he is not talking about whether "DDD halts"? [I.e. halts when run >>>> directly from main() outside of a simulator.] No, what he is talking >>>> about is whether the /step-by-step partial simuation/ of DDD performed >>>> by HHH proceeds as far as DDD returning. >>> >>> When 1 or more steps of DDD are correctly simulated by HHH the simulated >>> DDD cannot possibly reach its "return" instruction (final halt state). >>> No one here has agreed to that. Not in several years of coaxing and >>> elaboration. > >> It's true for a finite number. Aborting is not correct simulation, even >> if HHH did return that DDD halts. >> > > Didn't you know this? > It is incorrect for a simulating termination analyzer > to do a full simulation of a non-halting input. > So? it is also incorrect for a correct simulator to stop before it gets to the end. This is what makes it LOGICALLY IMPOSSIBLE to have a program that is both. Sorry, you are just showing that you "logic" is based on the assumption of the Truth Fairy that allows you to assume the impossible happens, and thus that you are nothing but a pathological liar.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 07:12 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <4dc0b21c6d9bb8b5ef5bff864d8f371a1eb5b1bd@i2pn2.org> |
| In reply to | #118099 |
On 5/8/25 11:34 PM, olcott wrote:
> On 5/8/2025 10:14 PM, Mike Terry wrote:
>> On 09/05/2025 03:13, olcott wrote:
>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> [...]
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> If you are a competent C programmer then you
>>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>>> possibly each its own "return" instruction.
>>>>>> "cannot possibly each"?
>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>>>> me nothing about what it's supposed to do. Without knowing what
>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>>
>>>>>
>>>>> For the purpose of this discussion HHH is exactly
>>>>> what I said it is. It correctly simulates DDD.
>>>>
>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>
>>>> Does HHH correctly simulate *every* function whose address is passed
>>>> to it? Must the passed function be one that takes no arguments
>>>> and does not return a value?
>>>>
>>>> Can HHH just *call* the function whose address is passed to it?
>>>> If it's a correct simulation, there should be no difference between
>>>> calling the function and "correctly simulating" it.
>>>>
>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>> DDD.
>>>>
>>>
>>> HHH can only simulate a function that take no arguments
>>> and has no return value. HHH also simulates the entire
>>> chain of functions that this function calls. These can
>>> take arguments or not and have return values or not.
>>>
>>> Thus HHH ends up simulating itself (and everything
>>> that HHH calls) simulating DDD in an infinite
>>> sequence of recursive emulation until OOM error.
>>>
>>>>> We need not know anything else about HHH to
>>>>> know that DDD correctly simulated by HHH cannot
>>>>> possibly REACH its own "return" instruction.
>>>>
>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>> does nothing else, your code would be equivalent to this:
>>>>
>>>> void DDD(void) {
>>>> DDD();
>>>> return;
>>>> }
>>>>
>>>
>>> Exactly. None of these people on comp.theory could
>>> get that even after three years.
>>>
>>
>> PO is being quite deceptive here.
>>
>
> I am only referring to the above hypothetical HHH/DDD pair.
> Everyone here has consistently denied that when DDD is
> correctly simulated by HHH that this DDD cannot possibly
> reach its "return" instruction (final halt state).
But that HHH isn't the required pure function that correctly emulate the
input, as the input has been clearly defined to be JUST the code of the
function DDD, and thus the call instruction can't be emulated as the
instruction it references isn't in the input.
When you include the input, then DDD become a DDD/HHH pair, and thus the
input for this hypotherical HHH is processing a different input than the
input you are going to give to your actual HHH, and thus says nothing
about it.
If you fix your statements so that it is clear that "the input" includes
all of that memroy, we might be able to deal with THIS statement, but
then you can't get to your next one.
And, if you remove the pure requirement, my version of HHH that uses the
static flag proves your claim is just incorrect in the relaxed case.
>
>> His simulation is in fact a single-stepped x86 instruction simulation,
>> where the stepping of each x86 instruction is under the HHH's control.
>> HHH can continue stepping the simulation until its target returns, in
>> which case the situation is logically just like direct call, as you
>> have described. Or HHH could step just 3 x86 instructions (say) and
>> then decide to return (aka "abort" its simulation). Let's call that /
>> partial/ simulation in contrast with /full/ simulation which you've
>> been supposing.
>>
>
> A full simulation of infinite recursion?
> I am only doing one tiny idea at a time here.
Sure, if that is what is there.
The fact that you HHH can't get by the call instruction and still meet
the defintions, since you have been excluding that code as "part of the
input" and just "in the system".
>
>> Oh, did he forget to mention that? Anyhow, in the general case with /
>> partial/ simulation there is more to think about as it is obvioudly /
>> not/ logically equivalent to direct execution.
>>
>
> That is changing the subject away from
> DDD correctly simulated by HHH.
Which doesn't happen within your definitions.
>
>>
>> Oh, and obviously everybody in comp.theory gets all this. The problem
>> is with PO and his inability to communicate his ideas properly and his
>> inability to understand what other people understand or disagree with.
>> He goes on for months/years claiming people don't understand things
>> they agree with, but it's down to his duffer wording...
>>
>>>> Then the return statement (which is unnecessary anyway) will never be
>>>> reached.
>>>
>>> It is only there to mark a final halt state.
>>>
>>>> In practice, the program will likely crash due to a stack
>>>> overflow, unless the compiler implements tail-call optimization, in
>>>> which case the program might just run forever -- which also means the
>>>> unnecessary return statement will never be reached.
>>>>
>>>
>>> Yes you totally have this correctly.
>>> None of the dozens of comp.theory people could
>>> ever achieve that level of understanding even
>>> after three years. That is why I needed to post
>>> on comp.lang.c.
>>
>> Everybody on comp.theory understands this much.
>
> No one here ever agreed that when 1 or more
> instructions of DDD are correctly simulated
> by HHH that DDD cannot possibly reach its
> own "return" instruction.
Because that is just a false phrase. Your HHH can not correctly emulate
past the call HHH instruction (and still be the requried pure function)
as the code there isn't part of what you have defined as the input.
>
> Everyone has found one excuse or another to
> deny this.
Only by pointing out your errors.
>
>> PO's plan is that when he goes elsewhere he can start with noobies and
>> trick them into agreeing with certain "wordings" by not explaining
>> relevent context for his questions. Then he goes back to comp.theory
>> and triumphantly claims support from elsewhere, proving to himself
>> that comp.theory posters are all idiots. :)
>>
>> So beware!
>>
>>>
>>>> This conclusion relies on my understanding of what you've said about
>>>> your code, which I consider to be unreliable.
>>
>> Hmm, did PO make it clear that when he says
>>
>> "..DDD correctly simulated by HHH cannot
>> possibly REACH its own "return" instruction."
>>
>
> Unless we go one tiny step at a time everyone
> permanently leaps to a false conclusion and stays
> there.
The problem is you are trying to hide your errors in the ambiquity of
equivocation,
>
>> he is not talking about whether "DDD halts"? [I.e. halts when run
>> directly from main() outside of a simulator.] No, what he is talking
>> about is whether the /step-by-step partial simuation/ of DDD performed
>> by HHH proceeds as far as DDD returning.
>
> When 1 or more steps of DDD are correctly simulated
> by HHH the simulated DDD cannot possibly reach its
> "return" instruction (final halt state).
And HHH can't correctly emulate its input past the call instruction, as
the code past there isn't part of the input.
Are you really that dense?
>
> No one here has agreed to that. Not in several
> years of coaxing and elaboration.
Because it isn't true under your stipulations.
>
>> Don't forget - HHH is allowed to simply stop simulating and return
>> whenever it likes! Maybe it only wants to simulate 48 x86
>> instructions, or just 1, or maybe it's in for the long haul and
>> simulates until DDD returns [if it ever does].
>>
>
> When 1 or more steps of DDD are correctly simulated
> by HHH the simulated DDD cannot possibly reach its
> "return" instruction (final halt state).
> remains a verified fact.
No, it remains a verified LIE by category error.
>
>> So you need to re-analyse everything you've said with this new
>> information that PO forgot to make clear.
>>
>>
>> Regards,
>> Mike.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 21:11 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87zffmbeyt.fsf@nosuchdomain.example.com> |
| In reply to | #118086 |
olcott <polcott333@gmail.com> writes:
> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> If you are a competent C programmer then you
>>>>> know that DDD correctly simulated by HHH cannot
>>>>> possibly each its own "return" instruction.
>>>> "cannot possibly each"?
>>>> I am a competent C programmer (and I don't believe you can make
>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>> me nothing about what it's supposed to do. Without knowing what
>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>
>>>
>>> For the purpose of this discussion HHH is exactly
>>> what I said it is. It correctly simulates DDD.
>> Does HHH correctly simulate DDD *and do nothing else*?
>> Does HHH correctly simulate *every* function whose address is passed
>> to it? Must the passed function be one that takes no arguments
>> and does not return a value?
>> Can HHH just *call* the function whose address is passed to it?
>> If it's a correct simulation, there should be no difference between
>> calling the function and "correctly simulating" it.
>> My knowledge of C tells me nothing about *how* HHH might simulate
>> DDD.
>
> HHH can only simulate a function that take no arguments
> and has no return value. HHH also simulates the entire
> chain of functions that this function calls. These can
> take arguments or not and have return values or not.
>
> Thus HHH ends up simulating itself (and everything
> that HHH calls) simulating DDD in an infinite
> sequence of recursive emulation until OOM error.
>
>>> We need not know anything else about HHH to
>>> know that DDD correctly simulated by HHH cannot
>>> possibly REACH its own "return" instruction.
>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>> does nothing else, your code would be equivalent to this:
>> void DDD(void) {
>> DDD();
>> return;
>> }
>
> Exactly. None of these people on comp.theory could
> get that even after three years.
I find that difficult to believe.
>> Then the return statement (which is unnecessary anyway) will never be
>> reached.
>
> It is only there to mark a final halt state.
The closing "}" does that equally well.
>> In practice, the program will likely crash due to a stack
>> overflow, unless the compiler implements tail-call optimization, in
>> which case the program might just run forever -- which also means the
>> unnecessary return statement will never be reached.
>>
>
> Yes you totally have this correctly.
> None of the dozens of comp.theory people could
> ever achieve that level of understanding even
> after three years. That is why I needed to post
> on comp.lang.c.
I'll note that I've posted in comp.theory, not in comp.lang.c.
I never see anything you post in comp.lang.c.
>> This conclusion relies on my understanding of what you've said about
>> your code, which I consider to be unreliable.
>
> I am not even talking about my code. I am
> talking about the purely hypothetical code
> that you just agreed to.
Do not overestimate what I've agreed to. I must still consider the
possibility that I've been led into a logical trap of some sort,
and that I've missed some subtle flaw.
>> No doubt you believe that there is some significance to the
>> apparent fact that the return statement will never be reached,
>> assuming that's a correct and relevant conclusion. I don't know
>> what that significance might be.
>
> I will tell you that later after you understand
> some prerequisite ideas first.
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
So now HHH returns an int result, and you store that result
in a variable named "Halt_Status". You haven't said here what
the meaning of that result might be, and I decline to make any
assumptions based on what you've called it. You could rename
"Halt_Status" to "Foo" and have effectively identical code.
Previously DDD would "correctly simulate" the function whose address is
passed to it. Now it does that and returns an int result.
If you want to say anything about the meaning of the result returned
by HHH, feel free to say it.
> The same thing that applied to DDD equally
> applies to the more complicated DD.
>
> When 1 or more instructions of DD are correctly
> simulated by HHH the correctly simulated DD
> cannot possibly get past its call to HHH(DD).
> Thus DD also never reaches its "return" instruction.
Now you're talking about simulating "1 or more instructions"
of DD. I thought that HHH was supposed to "accurately simulate"
the function whose argument is passed to it. Emulating just "1 or
more instructions" is not accurate simulation.
If HHH *fully* simulates the execution of DD, then your code above
exhibits endless recursion, which is not particularly interesting,
and it never reaches the "if (Halt_Status)". (DD calls HHH, which
simulates DD; HHH, in simulating DD, must do the equivalent of
calling HHH, and so on.)
You've introduced the idea of simulating only some finite number
of instructions of the simulated functions, but you haven't really
said how that happens (except perhaps in some x86 code that I
don't understand). You've implied that a sufficient knowledge of C
would let someone understand your arguments, but part of what you're
saying seems to depend on x86 assembly and/or machine code (which I'm
not going to learn for the sake of this discussion).
If I would need to understand x86 code to understand your claims, then
let's just stop here.
[SNIP]
--
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:49 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvk1ha$2ibbd$1@dont-email.me> |
| In reply to | #118100 |
On 5/8/2025 11:11 PM, Keith Thompson wrote:
> olcott <polcott333@gmail.com> writes:
>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> If you are a competent C programmer then you
>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>> possibly each its own "return" instruction.
>>>>> "cannot possibly each"?
>>>>> I am a competent C programmer (and I don't believe you can make
>>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>>> me nothing about what it's supposed to do. Without knowing what
>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>
>>>>
>>>> For the purpose of this discussion HHH is exactly
>>>> what I said it is. It correctly simulates DDD.
>>> Does HHH correctly simulate DDD *and do nothing else*?
>>> Does HHH correctly simulate *every* function whose address is passed
>>> to it? Must the passed function be one that takes no arguments
>>> and does not return a value?
>>> Can HHH just *call* the function whose address is passed to it?
>>> If it's a correct simulation, there should be no difference between
>>> calling the function and "correctly simulating" it.
>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>> DDD.
>>
>> HHH can only simulate a function that take no arguments
>> and has no return value. HHH also simulates the entire
>> chain of functions that this function calls. These can
>> take arguments or not and have return values or not.
>>
>> Thus HHH ends up simulating itself (and everything
>> that HHH calls) simulating DDD in an infinite
>> sequence of recursive emulation until OOM error.
>>
>>>> We need not know anything else about HHH to
>>>> know that DDD correctly simulated by HHH cannot
>>>> possibly REACH its own "return" instruction.
>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>> does nothing else, your code would be equivalent to this:
>>> void DDD(void) {
>>> DDD();
>>> return;
>>> }
>>
>> Exactly. None of these people on comp.theory could
>> get that even after three years.
>
> I find that difficult to believe.
>
>>> Then the return statement (which is unnecessary anyway) will never be
>>> reached.
>>
>> It is only there to mark a final halt state.
>
> The closing "}" does that equally well.
>
>>> In practice, the program will likely crash due to a stack
>>> overflow, unless the compiler implements tail-call optimization, in
>>> which case the program might just run forever -- which also means the
>>> unnecessary return statement will never be reached.
>>>
>>
>> Yes you totally have this correctly.
>> None of the dozens of comp.theory people could
>> ever achieve that level of understanding even
>> after three years. That is why I needed to post
>> on comp.lang.c.
>
> I'll note that I've posted in comp.theory, not in comp.lang.c.
> I never see anything you post in comp.lang.c.
>
>>> This conclusion relies on my understanding of what you've said about
>>> your code, which I consider to be unreliable.
>>
>> I am not even talking about my code. I am
>> talking about the purely hypothetical code
>> that you just agreed to.
>
> Do not overestimate what I've agreed to. I must still consider the
> possibility that I've been led into a logical trap of some sort,
> and that I've missed some subtle flaw.
>
>>> No doubt you believe that there is some significance to the
>>> apparent fact that the return statement will never be reached,
>>> assuming that's a correct and relevant conclusion. I don't know
>>> what that significance might be.
>>
>> I will tell you that later after you understand
>> some prerequisite ideas first.
>>
>> int DD()
>> {
>> int Halt_Status = HHH(DD);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>
> So now HHH returns an int result, and you store that result
> in a variable named "Halt_Status". You haven't said here what
> the meaning of that result might be, and I decline to make any
> assumptions based on what you've called it. You could rename
> "Halt_Status" to "Foo" and have effectively identical code.
>
> Previously DDD would "correctly simulate" the function whose address is
> passed to it. Now it does that and returns an int result.
>
> If you want to say anything about the meaning of the result returned
> by HHH, feel free to say it.
>
>> The same thing that applied to DDD equally
>> applies to the more complicated DD.
>>
>> When 1 or more instructions of DD are correctly
>> simulated by HHH the correctly simulated DD
>> cannot possibly get past its call to HHH(DD).
>> Thus DD also never reaches its "return" instruction.
>
> Now you're talking about simulating "1 or more instructions"
> of DD. I thought that HHH was supposed to "accurately simulate"
> the function whose argument is passed to it. Emulating just "1 or
> more instructions" is not accurate simulation.
>
> If HHH *fully* simulates the execution of DD, then your code above
> exhibits endless recursion,
In computer science "halting" is not merely stopping running.
"Halting" is reaching a final halt state such as the "return"
instruction.
> which is not particularly interesting,
> and it never reaches the "if (Halt_Status)". (DD calls HHH, which
> simulates DD; HHH, in simulating DD, must do the equivalent of
> calling HHH, and so on.)
>
It turns out to be very interesting you merely need
to grok a few details first.
> You've introduced the idea of simulating only some finite number
> of instructions of the simulated functions, but you haven't really
> said how that happens (except perhaps in some x86 code that I
> don't understand). You've implied that a sufficient knowledge of C
> would let someone understand your arguments, but part of what you're
> saying seems to depend on x86 assembly and/or machine code (which I'm
> not going to learn for the sake of this discussion).
>
> If I would need to understand x86 code to understand your claims, then
> let's just stop here.
>
> [SNIP]
>
--
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 22:31 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87frhebbae.fsf@nosuchdomain.example.com> |
| In reply to | #118105 |
olcott <polcott333@gmail.com> writes:
> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> [...]
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> If you are a competent C programmer then you
>>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>>> possibly each its own "return" instruction.
>>>>>> "cannot possibly each"?
>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>>>> me nothing about what it's supposed to do. Without knowing what
>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>>
>>>>>
>>>>> For the purpose of this discussion HHH is exactly
>>>>> what I said it is. It correctly simulates DDD.
>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>> Does HHH correctly simulate *every* function whose address is passed
>>>> to it? Must the passed function be one that takes no arguments
>>>> and does not return a value?
>>>> Can HHH just *call* the function whose address is passed to it?
>>>> If it's a correct simulation, there should be no difference between
>>>> calling the function and "correctly simulating" it.
>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>> DDD.
>>>
>>> HHH can only simulate a function that take no arguments
>>> and has no return value. HHH also simulates the entire
>>> chain of functions that this function calls. These can
>>> take arguments or not and have return values or not.
>>>
>>> Thus HHH ends up simulating itself (and everything
>>> that HHH calls) simulating DDD in an infinite
>>> sequence of recursive emulation until OOM error.
>>>
>>>>> We need not know anything else about HHH to
>>>>> know that DDD correctly simulated by HHH cannot
>>>>> possibly REACH its own "return" instruction.
>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>> does nothing else, your code would be equivalent to this:
>>>> void DDD(void) {
>>>> DDD();
>>>> return;
>>>> }
>>>
>>> Exactly. None of these people on comp.theory could
>>> get that even after three years.
>> I find that difficult to believe.
>>
>>>> Then the return statement (which is unnecessary anyway) will never be
>>>> reached.
>>>
>>> It is only there to mark a final halt state.
>> The closing "}" does that equally well.
>>
>>>> In practice, the program will likely crash due to a stack
>>>> overflow, unless the compiler implements tail-call optimization, in
>>>> which case the program might just run forever -- which also means the
>>>> unnecessary return statement will never be reached.
>>>>
>>>
>>> Yes you totally have this correctly.
>>> None of the dozens of comp.theory people could
>>> ever achieve that level of understanding even
>>> after three years. That is why I needed to post
>>> on comp.lang.c.
>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>> I never see anything you post in comp.lang.c.
>>
>>>> This conclusion relies on my understanding of what you've said about
>>>> your code, which I consider to be unreliable.
>>>
>>> I am not even talking about my code. I am
>>> talking about the purely hypothetical code
>>> that you just agreed to.
>> Do not overestimate what I've agreed to. I must still consider the
>> possibility that I've been led into a logical trap of some sort,
>> and that I've missed some subtle flaw.
>>
>>>> No doubt you believe that there is some significance to the
>>>> apparent fact that the return statement will never be reached,
>>>> assuming that's a correct and relevant conclusion. I don't know
>>>> what that significance might be.
>>>
>>> I will tell you that later after you understand
>>> some prerequisite ideas first.
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>> So now HHH returns an int result, and you store that result
>> in a variable named "Halt_Status". You haven't said here what
>> the meaning of that result might be, and I decline to make any
>> assumptions based on what you've called it. You could rename
>> "Halt_Status" to "Foo" and have effectively identical code.
>> Previously DDD would "correctly simulate" the function whose address
>> is
>> passed to it. Now it does that and returns an int result.
>> If you want to say anything about the meaning of the result returned
>> by HHH, feel free to say it.
>>
>>> The same thing that applied to DDD equally
>>> applies to the more complicated DD.
>>>
>>> When 1 or more instructions of DD are correctly
>>> simulated by HHH the correctly simulated DD
>>> cannot possibly get past its call to HHH(DD).
>>> Thus DD also never reaches its "return" instruction.
>> Now you're talking about simulating "1 or more instructions"
>> of DD. I thought that HHH was supposed to "accurately simulate"
>> the function whose argument is passed to it. Emulating just "1 or
>> more instructions" is not accurate simulation.
>> If HHH *fully* simulates the execution of DD, then your code above
>> exhibits endless recursion,
>
> In computer science "halting" is not merely stopping running.
> "Halting" is reaching a final halt state such as the "return"
> instruction.
I fail to see either the truth or the relevance of that statement.
We weren't even talking about halting. You did use the C identifier
"Halt_Status", but I already told you that the spelling of an
identifier implies nothing about its meaning. I said that you
hadn't said anything about the meaning of Halt_Status. You declined
to explain.
You continue to use the term "return instruction". There is no such
thing in C. There is a return *statement*. Do you have some reason to
insist on using incorrect terminology?
>> which is not particularly interesting,
>> and it never reaches the "if (Halt_Status)". (DD calls HHH, which
>> simulates DD; HHH, in simulating DD, must do the equivalent of
>> calling HHH, and so on.)
>
> It turns out to be very interesting you merely need
> to grok a few details first.
It's unlikely I'll continue paying attention long enough for it to get
interesting.
>> You've introduced the idea of simulating only some finite number
>> of instructions of the simulated functions, but you haven't really
>> said how that happens (except perhaps in some x86 code that I
>> don't understand). You've implied that a sufficient knowledge of C
>> would let someone understand your arguments, but part of what you're
>> saying seems to depend on x86 assembly and/or machine code (which I'm
>> not going to learn for the sake of this discussion).
>> If I would need to understand x86 code to understand your claims,
>> then
>> let's just stop here.
>> [SNIP]
You didn't respond to the above. I'll ask directly.
Would I need to understand x86 code to understand your claims? Yes or no.
--
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-09 00:49 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvk520$2j56g$1@dont-email.me> |
| In reply to | #118112 |
On 5/9/2025 12:31 AM, Keith Thompson wrote:
> olcott <polcott333@gmail.com> writes:
>
>> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>> [...]
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> If you are a competent C programmer then you
>>>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>>>> possibly each its own "return" instruction.
>>>>>>> "cannot possibly each"?
>>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>>>>> me nothing about what it's supposed to do. Without knowing what
>>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>>>
>>>>>>
>>>>>> For the purpose of this discussion HHH is exactly
>>>>>> what I said it is. It correctly simulates DDD.
>>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>> Does HHH correctly simulate *every* function whose address is passed
>>>>> to it? Must the passed function be one that takes no arguments
>>>>> and does not return a value?
>>>>> Can HHH just *call* the function whose address is passed to it?
>>>>> If it's a correct simulation, there should be no difference between
>>>>> calling the function and "correctly simulating" it.
>>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>>> DDD.
>>>>
>>>> HHH can only simulate a function that take no arguments
>>>> and has no return value. HHH also simulates the entire
>>>> chain of functions that this function calls. These can
>>>> take arguments or not and have return values or not.
>>>>
>>>> Thus HHH ends up simulating itself (and everything
>>>> that HHH calls) simulating DDD in an infinite
>>>> sequence of recursive emulation until OOM error.
>>>>
>>>>>> We need not know anything else about HHH to
>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>> possibly REACH its own "return" instruction.
>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>> does nothing else, your code would be equivalent to this:
>>>>> void DDD(void) {
>>>>> DDD();
>>>>> return;
>>>>> }
>>>>
>>>> Exactly. None of these people on comp.theory could
>>>> get that even after three years.
>>> I find that difficult to believe.
>>>
>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>> reached.
>>>>
>>>> It is only there to mark a final halt state.
>>> The closing "}" does that equally well.
>>>
>>>>> In practice, the program will likely crash due to a stack
>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>> which case the program might just run forever -- which also means the
>>>>> unnecessary return statement will never be reached.
>>>>>
>>>>
>>>> Yes you totally have this correctly.
>>>> None of the dozens of comp.theory people could
>>>> ever achieve that level of understanding even
>>>> after three years. That is why I needed to post
>>>> on comp.lang.c.
>>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>>> I never see anything you post in comp.lang.c.
>>>
>>>>> This conclusion relies on my understanding of what you've said about
>>>>> your code, which I consider to be unreliable.
>>>>
>>>> I am not even talking about my code. I am
>>>> talking about the purely hypothetical code
>>>> that you just agreed to.
>>> Do not overestimate what I've agreed to. I must still consider the
>>> possibility that I've been led into a logical trap of some sort,
>>> and that I've missed some subtle flaw.
>>>
>>>>> No doubt you believe that there is some significance to the
>>>>> apparent fact that the return statement will never be reached,
>>>>> assuming that's a correct and relevant conclusion. I don't know
>>>>> what that significance might be.
>>>>
>>>> I will tell you that later after you understand
>>>> some prerequisite ideas first.
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>> So now HHH returns an int result, and you store that result
>>> in a variable named "Halt_Status". You haven't said here what
>>> the meaning of that result might be, and I decline to make any
>>> assumptions based on what you've called it. You could rename
>>> "Halt_Status" to "Foo" and have effectively identical code.
>>> Previously DDD would "correctly simulate" the function whose address
>>> is
>>> passed to it. Now it does that and returns an int result.
>>> If you want to say anything about the meaning of the result returned
>>> by HHH, feel free to say it.
>>>
>>>> The same thing that applied to DDD equally
>>>> applies to the more complicated DD.
>>>>
>>>> When 1 or more instructions of DD are correctly
>>>> simulated by HHH the correctly simulated DD
>>>> cannot possibly get past its call to HHH(DD).
>>>> Thus DD also never reaches its "return" instruction.
>>> Now you're talking about simulating "1 or more instructions"
>>> of DD. I thought that HHH was supposed to "accurately simulate"
>>> the function whose argument is passed to it. Emulating just "1 or
>>> more instructions" is not accurate simulation.
>>> If HHH *fully* simulates the execution of DD, then your code above
>>> exhibits endless recursion,
>>
>> In computer science "halting" is not merely stopping running.
>> "Halting" is reaching a final halt state such as the "return"
>> instruction.
>
> I fail to see either the truth or the relevance of that statement.
The "return" instruction marks the final halt state.
The actual basis for halting: Reaching a Final Halt State
The halting problem proofs have very specific specific parameters.
>
> We weren't even talking about halting. You did use the C identifier
> "Halt_Status", but I already told you that the spelling of an
> identifier implies nothing about its meaning. I said that you
> hadn't said anything about the meaning of Halt_Status. You declined
> to explain.
>
> You continue to use the term "return instruction". There is no such
> thing in C. There is a return *statement*. Do you have some reason to
> insist on using incorrect terminology?
>
>>> which is not particularly interesting,
>>> and it never reaches the "if (Halt_Status)". (DD calls HHH, which
>>> simulates DD; HHH, in simulating DD, must do the equivalent of
>>> calling HHH, and so on.)
>>
>> It turns out to be very interesting you merely need
>> to grok a few details first.
>
> It's unlikely I'll continue paying attention long enough for it to get
> interesting.
>
>>> You've introduced the idea of simulating only some finite number
>>> of instructions of the simulated functions, but you haven't really
>>> said how that happens (except perhaps in some x86 code that I
>>> don't understand). You've implied that a sufficient knowledge of C
>>> would let someone understand your arguments, but part of what you're
>>> saying seems to depend on x86 assembly and/or machine code (which I'm
>>> not going to learn for the sake of this discussion).
>>> If I would need to understand x86 code to understand your claims,
>>> then
>>> let's just stop here.
>>> [SNIP]
>
> You didn't respond to the above. I'll ask directly.
>
> Would I need to understand x86 code to understand your claims? Yes or no.
>
It makes it much easier because the state transition graph
of the control flow at the x86 level is unequivocal.
--
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 23:17 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <871psyb94z.fsf@nosuchdomain.example.com> |
| In reply to | #118115 |
olcott <polcott333@gmail.com> writes:
> On 5/9/2025 12:31 AM, Keith Thompson wrote:
[...]
>> You didn't respond to the above. I'll ask directly.
>> Would I need to understand x86 code to understand your claims? Yes
>> or no.
>
> It makes it much easier because the state transition graph
> of the control flow at the x86 level is unequivocal.
What a pity you couldn't have made that clear much sooner.
As I said, I'm not very familiar with x86 code, and it's
absolutely not worth my time and effort to learn it for the sake
of understanding your claims.
Bye.
--
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-09 10:03 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl5fl$2rl0l$3@dont-email.me> |
| In reply to | #118116 |
On 5/9/2025 1:17 AM, Keith Thompson wrote: > olcott <polcott333@gmail.com> writes: >> On 5/9/2025 12:31 AM, Keith Thompson wrote: > [...] >>> You didn't respond to the above. I'll ask directly. >>> Would I need to understand x86 code to understand your claims? Yes >>> or no. >> >> It makes it much easier because the state transition graph >> of the control flow at the x86 level is unequivocal. > > What a pity you couldn't have made that clear much sooner. > Your help on the C part was very useful. The x86 part is only needed to understand the internals of the simulating termination analyzer. _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] You don't need to understand the first two instructions. The next two instructions simply call HHH(DDD) in recursive emulation. At the x86 machine code level HHH can see that the first four instructions of DDD repeats. It sees this after it emulates DDD and then emulates itself emulating DDD once. > As I said, I'm not very familiar with x86 code, and it's > absolutely not worth my time and effort to learn it for the sake > of understanding your claims. > > Bye. > -- 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 14:24 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <fdd76497f309d42f4d9fa60818dc4b4db0023953@i2pn2.org> |
| In reply to | #118139 |
On 5/9/25 11:03 AM, olcott wrote: > On 5/9/2025 1:17 AM, Keith Thompson wrote: >> olcott <polcott333@gmail.com> writes: >>> On 5/9/2025 12:31 AM, Keith Thompson wrote: >> [...] >>>> You didn't respond to the above. I'll ask directly. >>>> Would I need to understand x86 code to understand your claims? Yes >>>> or no. >>> >>> It makes it much easier because the state transition graph >>> of the control flow at the x86 level is unequivocal. >> >> What a pity you couldn't have made that clear much sooner. >> > > Your help on the C part was very useful. > The x86 part is only needed to understand > the internals of the simulating termination > analyzer. > > _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] > > You don't need to understand the first two instructions. > The next two instructions simply call HHH(DDD) in > recursive emulation. > > At the x86 machine code level HHH can see that the > first four instructions of DDD repeats. It sees this > after it emulates DDD and then emulates itself > emulating DDD once. > >> As I said, I'm not very familiar with x86 code, and it's >> absolutely not worth my time and effort to learn it for the sake >> of understanding your claims. >> >> Bye. >> > > And, since you say that is *ALL* of the input, it is CATEGORICALLY IMPOSSIBLE for a correct emulator to emulate the instruction, as it is missing the details. Sorry, but you are just showing that youy are so dense that you are unable to learn basic definitions in programing.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 07:21 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <1ffb883a3b414946707ff9cd9e09dcde21948764@i2pn2.org> |
| In reply to | #118115 |
On 5/9/25 1:49 AM, olcott wrote:
> On 5/9/2025 12:31 AM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>
>>> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>> [...]
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>> HHH(DDD);
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If you are a competent C programmer then you
>>>>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>>>>> possibly each its own "return" instruction.
>>>>>>>> "cannot possibly each"?
>>>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>>>>>> me nothing about what it's supposed to do. Without knowing what
>>>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>>>>
>>>>>>>
>>>>>>> For the purpose of this discussion HHH is exactly
>>>>>>> what I said it is. It correctly simulates DDD.
>>>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>>> Does HHH correctly simulate *every* function whose address is passed
>>>>>> to it? Must the passed function be one that takes no arguments
>>>>>> and does not return a value?
>>>>>> Can HHH just *call* the function whose address is passed to it?
>>>>>> If it's a correct simulation, there should be no difference between
>>>>>> calling the function and "correctly simulating" it.
>>>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>>>> DDD.
>>>>>
>>>>> HHH can only simulate a function that take no arguments
>>>>> and has no return value. HHH also simulates the entire
>>>>> chain of functions that this function calls. These can
>>>>> take arguments or not and have return values or not.
>>>>>
>>>>> Thus HHH ends up simulating itself (and everything
>>>>> that HHH calls) simulating DDD in an infinite
>>>>> sequence of recursive emulation until OOM error.
>>>>>
>>>>>>> We need not know anything else about HHH to
>>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>>> possibly REACH its own "return" instruction.
>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>> does nothing else, your code would be equivalent to this:
>>>>>> void DDD(void) {
>>>>>> DDD();
>>>>>> return;
>>>>>> }
>>>>>
>>>>> Exactly. None of these people on comp.theory could
>>>>> get that even after three years.
>>>> I find that difficult to believe.
>>>>
>>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>>> reached.
>>>>>
>>>>> It is only there to mark a final halt state.
>>>> The closing "}" does that equally well.
>>>>
>>>>>> In practice, the program will likely crash due to a stack
>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>> which case the program might just run forever -- which also means the
>>>>>> unnecessary return statement will never be reached.
>>>>>>
>>>>>
>>>>> Yes you totally have this correctly.
>>>>> None of the dozens of comp.theory people could
>>>>> ever achieve that level of understanding even
>>>>> after three years. That is why I needed to post
>>>>> on comp.lang.c.
>>>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>>>> I never see anything you post in comp.lang.c.
>>>>
>>>>>> This conclusion relies on my understanding of what you've said about
>>>>>> your code, which I consider to be unreliable.
>>>>>
>>>>> I am not even talking about my code. I am
>>>>> talking about the purely hypothetical code
>>>>> that you just agreed to.
>>>> Do not overestimate what I've agreed to. I must still consider the
>>>> possibility that I've been led into a logical trap of some sort,
>>>> and that I've missed some subtle flaw.
>>>>
>>>>>> No doubt you believe that there is some significance to the
>>>>>> apparent fact that the return statement will never be reached,
>>>>>> assuming that's a correct and relevant conclusion. I don't know
>>>>>> what that significance might be.
>>>>>
>>>>> I will tell you that later after you understand
>>>>> some prerequisite ideas first.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>> So now HHH returns an int result, and you store that result
>>>> in a variable named "Halt_Status". You haven't said here what
>>>> the meaning of that result might be, and I decline to make any
>>>> assumptions based on what you've called it. You could rename
>>>> "Halt_Status" to "Foo" and have effectively identical code.
>>>> Previously DDD would "correctly simulate" the function whose address
>>>> is
>>>> passed to it. Now it does that and returns an int result.
>>>> If you want to say anything about the meaning of the result returned
>>>> by HHH, feel free to say it.
>>>>
>>>>> The same thing that applied to DDD equally
>>>>> applies to the more complicated DD.
>>>>>
>>>>> When 1 or more instructions of DD are correctly
>>>>> simulated by HHH the correctly simulated DD
>>>>> cannot possibly get past its call to HHH(DD).
>>>>> Thus DD also never reaches its "return" instruction.
>>>> Now you're talking about simulating "1 or more instructions"
>>>> of DD. I thought that HHH was supposed to "accurately simulate"
>>>> the function whose argument is passed to it. Emulating just "1 or
>>>> more instructions" is not accurate simulation.
>>>> If HHH *fully* simulates the execution of DD, then your code above
>>>> exhibits endless recursion,
>>>
>>> In computer science "halting" is not merely stopping running.
>>> "Halting" is reaching a final halt state such as the "return"
>>> instruction.
>>
>> I fail to see either the truth or the relevance of that statement.
>
> The "return" instruction marks the final halt state.
Which just shows that you are not reading what he is saying.
> The actual basis for halting: Reaching a Final Halt State
> The halting problem proofs have very specific specific parameters.
Which points out that you are not talking about the C language, but are
just trying to abuse that connection.
>
>>
>> We weren't even talking about halting. You did use the C identifier
>> "Halt_Status", but I already told you that the spelling of an
>> identifier implies nothing about its meaning. I said that you
>> hadn't said anything about the meaning of Halt_Status. You declined
>> to explain.
>>
>
>
>> You continue to use the term "return instruction". There is no such
>> thing in C. There is a return *statement*. Do you have some reason to
>> insist on using incorrect terminology?
>>
>>>> which is not particularly interesting,
>>>> and it never reaches the "if (Halt_Status)". (DD calls HHH, which
>>>> simulates DD; HHH, in simulating DD, must do the equivalent of
>>>> calling HHH, and so on.)
>>>
>>> It turns out to be very interesting you merely need
>>> to grok a few details first.
>>
>> It's unlikely I'll continue paying attention long enough for it to get
>> interesting.
>>
>>>> You've introduced the idea of simulating only some finite number
>>>> of instructions of the simulated functions, but you haven't really
>>>> said how that happens (except perhaps in some x86 code that I
>>>> don't understand). You've implied that a sufficient knowledge of C
>>>> would let someone understand your arguments, but part of what you're
>>>> saying seems to depend on x86 assembly and/or machine code (which I'm
>>>> not going to learn for the sake of this discussion).
>>>> If I would need to understand x86 code to understand your claims,
>>>> then
>>>> let's just stop here.
>>>> [SNIP]
>>
>> You didn't respond to the above. I'll ask directly.
>>
>> Would I need to understand x86 code to understand your claims? Yes or
>> no.
>>
>
> It makes it much easier because the state transition graph
> of the control flow at the x86 level is unequivocal.
>
The same is true of C code that uses no undefined behavior.
Part of your problem is that you keep on violating the requirements you
stipulate to try to support your equivocation.
[toc] | [prev] | [next] | [standalone]
Page 26 of 32 — ← Prev page 1 … 24 25 [26] 27 28 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web