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 13 of 32 — ← Prev page 1 … 11 12 [13] 14 15 … 32 Next page →
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-10 23:28 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <5b14da4260c0b7e3235ce05f752c092fade4d70e.camel@gmail.com> |
| In reply to | #118326 |
On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
> On 5/10/2025 7:37 AM, Bonita Montero wrote:
> > Am 09.05.2025 um 04:22 schrieb olcott:
> >
> > > Look at their replies to this post.
> > > Not a one of them will agree that
> > >
> > > void DDD()
> > > {
> > > HHH(DDD);
> > > return; // final halt state
> > > }
> > >
> > > When 1 or more instructions of DDD are correctly
> > > simulated by HHH then the correctly simulated DDD cannot
> > > possibly reach its "return" instruction (final halt state).
> > >
> > > They have consistently disagreed with this
> > > simple point for three years.
> >
> > I guess that not even a professor of theoretical computer
> > science would spend years working on so few lines of code.
> >
>
> I created a whole x86utm operating system.
> It correctly determines that the halting problem's
> otherwise "impossible" input is actually non halting.
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> https://github.com/plolcott/x86utm
>
Nope.
From I know HHH(DD) decides whether the input DD is "impossible" input or not.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 10:45 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnsae$3in62$9@dont-email.me> |
| In reply to | #118338 |
On 5/10/2025 10:28 AM, wij wrote:
> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>
>>>> Look at their replies to this post.
>>>> Not a one of them will agree that
>>>>
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return; // final halt state
>>>> }
>>>>
>>>> When 1 or more instructions of DDD are correctly
>>>> simulated by HHH then the correctly simulated DDD cannot
>>>> possibly reach its "return" instruction (final halt state).
>>>>
>>>> They have consistently disagreed with this
>>>> simple point for three years.
>>>
>>> I guess that not even a professor of theoretical computer
>>> science would spend years working on so few lines of code.
>>>
>>
>> I created a whole x86utm operating system.
>> It correctly determines that the halting problem's
>> otherwise "impossible" input is actually non halting.
>>
>> int DD()
>> {
>> int Halt_Status = HHH(DD);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> https://github.com/plolcott/x86utm
>>
>
> Nope.
> From I know HHH(DD) decides whether the input DD is "impossible" input or not.
>
DD has the standard form of the "impossible" input.
HHH merely rejects it as non-halting.
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 00:06 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <11cc09876004107c47467b9481f614f45f450f2c.camel@gmail.com> |
| In reply to | #118343 |
On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
> On 5/10/2025 10:28 AM, wij wrote:
> > On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
> > > On 5/10/2025 7:37 AM, Bonita Montero wrote:
> > > > Am 09.05.2025 um 04:22 schrieb olcott:
> > > >
> > > > > Look at their replies to this post.
> > > > > Not a one of them will agree that
> > > > >
> > > > > void DDD()
> > > > > {
> > > > > HHH(DDD);
> > > > > return; // final halt state
> > > > > }
> > > > >
> > > > > When 1 or more instructions of DDD are correctly
> > > > > simulated by HHH then the correctly simulated DDD cannot
> > > > > possibly reach its "return" instruction (final halt state).
> > > > >
> > > > > They have consistently disagreed with this
> > > > > simple point for three years.
> > > >
> > > > I guess that not even a professor of theoretical computer
> > > > science would spend years working on so few lines of code.
> > > >
> > >
> > > I created a whole x86utm operating system.
> > > It correctly determines that the halting problem's
> > > otherwise "impossible" input is actually non halting.
> > >
> > > int DD()
> > > {
> > > int Halt_Status = HHH(DD);
> > > if (Halt_Status)
> > > HERE: goto HERE;
> > > return Halt_Status;
> > > }
> > >
> > > https://github.com/plolcott/x86utm
> > >
> >
> > Nope.
> > From I know HHH(DD) decides whether the input DD is "impossible" input or not.
> >
>
> DD has the standard form of the "impossible" input.
> HHH merely rejects it as non-halting.
>
You said 'merely' rejects it as non-halting.
So, POOH do not answer the input of any other function?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 11:19 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnu9k$3k258$2@dont-email.me> |
| In reply to | #118350 |
On 5/10/2025 11:06 AM, wij wrote:
> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>> On 5/10/2025 10:28 AM, wij wrote:
>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>
>>>>>> Look at their replies to this post.
>>>>>> Not a one of them will agree that
>>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return; // final halt state
>>>>>> }
>>>>>>
>>>>>> When 1 or more instructions of DDD are correctly
>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>
>>>>>> They have consistently disagreed with this
>>>>>> simple point for three years.
>>>>>
>>>>> I guess that not even a professor of theoretical computer
>>>>> science would spend years working on so few lines of code.
>>>>>
>>>>
>>>> I created a whole x86utm operating system.
>>>> It correctly determines that the halting problem's
>>>> otherwise "impossible" input is actually non halting.
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> https://github.com/plolcott/x86utm
>>>>
>>>
>>> Nope.
>>> From I know HHH(DD) decides whether the input DD is "impossible" input or not.
>>>
>>
>> DD has the standard form of the "impossible" input.
>> HHH merely rejects it as non-halting.
>>
>
> You said 'merely' rejects it as non-halting.
> So, POOH do not answer the input of any other function?
>
The input that has baffled computer scientists for 90
years is merely correctly determined to be non-halting
when the behavior of this input is measured by HHH
emulating this input according to the rules of the x86
language.
The same thing applies to the Linz proof yet cannot
be understood until after HHH(DDD) and HHH(DD) are
fully understood.
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 12:21 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnuee$3judg$2@dont-email.me> |
| In reply to | #118355 |
On 5/10/2025 12:19 PM, olcott wrote:
> On 5/10/2025 11:06 AM, wij wrote:
>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>> On 5/10/2025 10:28 AM, wij wrote:
>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>
>>>>>>> Look at their replies to this post.
>>>>>>> Not a one of them will agree that
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return; // final halt state
>>>>>>> }
>>>>>>>
>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>
>>>>>>> They have consistently disagreed with this
>>>>>>> simple point for three years.
>>>>>>
>>>>>> I guess that not even a professor of theoretical computer
>>>>>> science would spend years working on so few lines of code.
>>>>>>
>>>>>
>>>>> I created a whole x86utm operating system.
>>>>> It correctly determines that the halting problem's
>>>>> otherwise "impossible" input is actually non halting.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> https://github.com/plolcott/x86utm
>>>>>
>>>>
>>>> Nope.
>>>> From I know HHH(DD) decides whether the input DD is "impossible"
>>>> input or not.
>>>>
>>>
>>> DD has the standard form of the "impossible" input.
>>> HHH merely rejects it as non-halting.
>>>
>>
>> You said 'merely' rejects it as non-halting.
>> So, POOH do not answer the input of any other function?
>>
>
> The input that has baffled computer scientists for 90
> years is merely correctly determined to be non-halting
> when the behavior of this input is measured by HHH
> emulating this input according to the rules of the x86
> language.
Which is not the required measure to be a solution to the halting problem.
>
> The same thing applies to the Linz proof yet cannot
> be understood until after HHH(DDD) and HHH(DD) are
> fully understood.
>
False, because that proof starts with the assumption that the following
mapping can be computed and that H computes it:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 00:29 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <674a661e498281cca55b322cbd5905a1988a6171.camel@gmail.com> |
| In reply to | #118355 |
On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
> On 5/10/2025 11:06 AM, wij wrote:
> > On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
> > > On 5/10/2025 10:28 AM, wij wrote:
> > > > On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
> > > > > On 5/10/2025 7:37 AM, Bonita Montero wrote:
> > > > > > Am 09.05.2025 um 04:22 schrieb olcott:
> > > > > >
> > > > > > > Look at their replies to this post.
> > > > > > > Not a one of them will agree that
> > > > > > >
> > > > > > > void DDD()
> > > > > > > {
> > > > > > > HHH(DDD);
> > > > > > > return; // final halt state
> > > > > > > }
> > > > > > >
> > > > > > > When 1 or more instructions of DDD are correctly
> > > > > > > simulated by HHH then the correctly simulated DDD cannot
> > > > > > > possibly reach its "return" instruction (final halt state).
> > > > > > >
> > > > > > > They have consistently disagreed with this
> > > > > > > simple point for three years.
> > > > > >
> > > > > > I guess that not even a professor of theoretical computer
> > > > > > science would spend years working on so few lines of code.
> > > > > >
> > > > >
> > > > > I created a whole x86utm operating system.
> > > > > It correctly determines that the halting problem's
> > > > > otherwise "impossible" input is actually non halting.
> > > > >
> > > > > int DD()
> > > > > {
> > > > > int Halt_Status = HHH(DD);
> > > > > if (Halt_Status)
> > > > > HERE: goto HERE;
> > > > > return Halt_Status;
> > > > > }
> > > > >
> > > > > https://github.com/plolcott/x86utm
> > > > >
> > > >
> > > > Nope.
> > > > From I know HHH(DD) decides whether the input DD is "impossible" input or not.
> > > >
> > >
> > > DD has the standard form of the "impossible" input.
> > > HHH merely rejects it as non-halting.
> > >
> >
> > You said 'merely' rejects it as non-halting.
> > So, POOH do not answer the input of any other function?
> >
>
> The input that has baffled computer scientists for 90
> years is merely correctly determined to be non-halting
> when the behavior of this input is measured by HHH
> emulating this input according to the rules of the x86
> language.
>
> The same thing applies to the Linz proof yet cannot
> be understood until after HHH(DDD) and HHH(DD) are
> fully understood.
>
HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
Others of what you say are your imagine and wishes, so far so true.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 11:47 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnvut$3kher$3@dont-email.me> |
| In reply to | #118358 |
On 5/10/2025 11:29 AM, wij wrote:
> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>> On 5/10/2025 11:06 AM, wij wrote:
>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>
>>>>>>>> Look at their replies to this post.
>>>>>>>> Not a one of them will agree that
>>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return; // final halt state
>>>>>>>> }
>>>>>>>>
>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>
>>>>>>>> They have consistently disagreed with this
>>>>>>>> simple point for three years.
>>>>>>>
>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>> science would spend years working on so few lines of code.
>>>>>>>
>>>>>>
>>>>>> I created a whole x86utm operating system.
>>>>>> It correctly determines that the halting problem's
>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>
>>>>>> int DD()
>>>>>> {
>>>>>> int Halt_Status = HHH(DD);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> https://github.com/plolcott/x86utm
>>>>>>
>>>>>
>>>>> Nope.
>>>>> From I know HHH(DD) decides whether the input DD is "impossible" input or not.
>>>>>
>>>>
>>>> DD has the standard form of the "impossible" input.
>>>> HHH merely rejects it as non-halting.
>>>>
>>>
>>> You said 'merely' rejects it as non-halting.
>>> So, POOH do not answer the input of any other function?
>>>
>>
>> The input that has baffled computer scientists for 90
>> years is merely correctly determined to be non-halting
>> when the behavior of this input is measured by HHH
>> emulating this input according to the rules of the x86
>> language.
>>
>> The same thing applies to the Linz proof yet cannot
>> be understood until after HHH(DDD) and HHH(DD) are
>> fully understood.
>>
>
> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
> Others of what you say are your imagine and wishes, so far so true.
>
DDD emulated by HHH according to the rules of
the x86 language specifies recursive emulation
that cannot possibly reach the final halt state
of DDD.
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 01:01 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <088556c03067d8de7184bf88dd01cc6b8c99ba1b.camel@gmail.com> |
| In reply to | #118362 |
On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
> On 5/10/2025 11:29 AM, wij wrote:
> > On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
> > > On 5/10/2025 11:06 AM, wij wrote:
> > > > On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
> > > > > On 5/10/2025 10:28 AM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
> > > > > > > On 5/10/2025 7:37 AM, Bonita Montero wrote:
> > > > > > > > Am 09.05.2025 um 04:22 schrieb olcott:
> > > > > > > >
> > > > > > > > > Look at their replies to this post.
> > > > > > > > > Not a one of them will agree that
> > > > > > > > >
> > > > > > > > > void DDD()
> > > > > > > > > {
> > > > > > > > > HHH(DDD);
> > > > > > > > > return; // final halt state
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > When 1 or more instructions of DDD are correctly
> > > > > > > > > simulated by HHH then the correctly simulated DDD cannot
> > > > > > > > > possibly reach its "return" instruction (final halt state).
> > > > > > > > >
> > > > > > > > > They have consistently disagreed with this
> > > > > > > > > simple point for three years.
> > > > > > > >
> > > > > > > > I guess that not even a professor of theoretical computer
> > > > > > > > science would spend years working on so few lines of code.
> > > > > > > >
> > > > > > >
> > > > > > > I created a whole x86utm operating system.
> > > > > > > It correctly determines that the halting problem's
> > > > > > > otherwise "impossible" input is actually non halting.
> > > > > > >
> > > > > > > int DD()
> > > > > > > {
> > > > > > > int Halt_Status = HHH(DD);
> > > > > > > if (Halt_Status)
> > > > > > > HERE: goto HERE;
> > > > > > > return Halt_Status;
> > > > > > > }
> > > > > > >
> > > > > > > https://github.com/plolcott/x86utm
> > > > > > >
> > > > > >
> > > > > > Nope.
> > > > > > From I know HHH(DD) decides whether the input DD is "impossible" input or not.
> > > > > >
> > > > >
> > > > > DD has the standard form of the "impossible" input.
> > > > > HHH merely rejects it as non-halting.
> > > > >
> > > >
> > > > You said 'merely' rejects it as non-halting.
> > > > So, POOH do not answer the input of any other function?
> > > >
> > >
> > > The input that has baffled computer scientists for 90
> > > years is merely correctly determined to be non-halting
> > > when the behavior of this input is measured by HHH
> > > emulating this input according to the rules of the x86
> > > language.
> > >
> > > The same thing applies to the Linz proof yet cannot
> > > be understood until after HHH(DDD) and HHH(DD) are
> > > fully understood.
> > >
> >
> > HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
> > Others of what you say are your imagine and wishes, so far so true.
> >
>
> DDD emulated by HHH according to the rules of
> the x86 language specifies recursive emulation
> that cannot possibly reach the final halt state
> of DDD.
>
I have no problem with that. And, you said HHH merely rejects it as non-halting.
You had denied HHH can decide the halting property of any input, except DDD/DD/D..
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 12:17 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvo1ni$3l14p$1@dont-email.me> |
| In reply to | #118364 |
On 5/10/2025 12:01 PM, wij wrote:
> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>> On 5/10/2025 11:29 AM, wij wrote:
>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>
>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>
>>>>>>>>>> void DDD()
>>>>>>>>>> {
>>>>>>>>>> HHH(DDD);
>>>>>>>>>> return; // final halt state
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>
>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>> simple point for three years.
>>>>>>>>>
>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I created a whole x86utm operating system.
>>>>>>>> It correctly determines that the halting problem's
>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>
>>>>>>>> int DD()
>>>>>>>> {
>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return Halt_Status;
>>>>>>>> }
>>>>>>>>
>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>
>>>>>>>
>>>>>>> Nope.
>>>>>>> From I know HHH(DD) decides whether the input DD is "impossible" input or not.
>>>>>>>
>>>>>>
>>>>>> DD has the standard form of the "impossible" input.
>>>>>> HHH merely rejects it as non-halting.
>>>>>>
>>>>>
>>>>> You said 'merely' rejects it as non-halting.
>>>>> So, POOH do not answer the input of any other function?
>>>>>
>>>>
>>>> The input that has baffled computer scientists for 90
>>>> years is merely correctly determined to be non-halting
>>>> when the behavior of this input is measured by HHH
>>>> emulating this input according to the rules of the x86
>>>> language.
>>>>
>>>> The same thing applies to the Linz proof yet cannot
>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>> fully understood.
>>>>
>>>
>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
>>> Others of what you say are your imagine and wishes, so far so true.
>>>
>>
>> DDD emulated by HHH according to the rules of
>> the x86 language specifies recursive emulation
>> that cannot possibly reach the final halt state
>> of DDD.
>>
>
> I have no problem with that. And, you said HHH merely rejects it as non-halting.
> You had denied HHH can decide the halting property of any input, except DDD/DD/D..
>
As long as HHH correctly determines the halt status
of a single input that has no inputs then HHH is
a correct termination analyzer for that 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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 13:19 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvo1q5$3judg$4@dont-email.me> |
| In reply to | #118365 |
On 5/10/2025 1:17 PM, olcott wrote:
> On 5/10/2025 12:01 PM, wij wrote:
>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>> On 5/10/2025 11:29 AM, wij wrote:
>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>
>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>
>>>>>>>>>>> void DDD()
>>>>>>>>>>> {
>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>> return; // final halt state
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>>
>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>> simple point for three years.
>>>>>>>>>>
>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>
>>>>>>>>> int DD()
>>>>>>>>> {
>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>> if (Halt_Status)
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return Halt_Status;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope.
>>>>>>>> From I know HHH(DD) decides whether the input DD is
>>>>>>>> "impossible" input or not.
>>>>>>>>
>>>>>>>
>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>
>>>>>>
>>>>>> You said 'merely' rejects it as non-halting.
>>>>>> So, POOH do not answer the input of any other function?
>>>>>>
>>>>>
>>>>> The input that has baffled computer scientists for 90
>>>>> years is merely correctly determined to be non-halting
>>>>> when the behavior of this input is measured by HHH
>>>>> emulating this input according to the rules of the x86
>>>>> language.
>>>>>
>>>>> The same thing applies to the Linz proof yet cannot
>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>> fully understood.
>>>>>
>>>>
>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
>>>> Others of what you say are your imagine and wishes, so far so true.
>>>>
>>>
>>> DDD emulated by HHH according to the rules of
>>> the x86 language specifies recursive emulation
>>> that cannot possibly reach the final halt state
>>> of DDD.
>>>
>>
>> I have no problem with that. And, you said HHH merely rejects it as
>> non-halting.
>> You had denied HHH can decide the halting property of any input,
>> except DDD/DD/D..
>>
>
> As long as HHH correctly determines the halt status
> of a single input that has no inputs then HHH is
> a correct termination analyzer for that input.
>
Which is isn't, as it isn't performing the required mapping for DDD:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 02:09 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <c09f468e8485c22150cedb12a9010b401f292054.camel@gmail.com> |
| In reply to | #118365 |
On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
> On 5/10/2025 12:01 PM, wij wrote:
> > On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
> > > On 5/10/2025 11:29 AM, wij wrote:
> > > > On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
> > > > > On 5/10/2025 11:06 AM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
> > > > > > > On 5/10/2025 10:28 AM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 7:37 AM, Bonita Montero wrote:
> > > > > > > > > > Am 09.05.2025 um 04:22 schrieb olcott:
> > > > > > > > > >
> > > > > > > > > > > Look at their replies to this post.
> > > > > > > > > > > Not a one of them will agree that
> > > > > > > > > > >
> > > > > > > > > > > void DDD()
> > > > > > > > > > > {
> > > > > > > > > > > HHH(DDD);
> > > > > > > > > > > return; // final halt state
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > When 1 or more instructions of DDD are correctly
> > > > > > > > > > > simulated by HHH then the correctly simulated DDD cannot
> > > > > > > > > > > possibly reach its "return" instruction (final halt state).
> > > > > > > > > > >
> > > > > > > > > > > They have consistently disagreed with this
> > > > > > > > > > > simple point for three years.
> > > > > > > > > >
> > > > > > > > > > I guess that not even a professor of theoretical computer
> > > > > > > > > > science would spend years working on so few lines of code.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I created a whole x86utm operating system.
> > > > > > > > > It correctly determines that the halting problem's
> > > > > > > > > otherwise "impossible" input is actually non halting.
> > > > > > > > >
> > > > > > > > > int DD()
> > > > > > > > > {
> > > > > > > > > int Halt_Status = HHH(DD);
> > > > > > > > > if (Halt_Status)
> > > > > > > > > HERE: goto HERE;
> > > > > > > > > return Halt_Status;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > https://github.com/plolcott/x86utm
> > > > > > > > >
> > > > > > > >
> > > > > > > > Nope.
> > > > > > > > From I know HHH(DD) decides whether the input DD is "impossible" input or not.
> > > > > > > >
> > > > > > >
> > > > > > > DD has the standard form of the "impossible" input.
> > > > > > > HHH merely rejects it as non-halting.
> > > > > > >
> > > > > >
> > > > > > You said 'merely' rejects it as non-halting.
> > > > > > So, POOH do not answer the input of any other function?
> > > > > >
> > > > >
> > > > > The input that has baffled computer scientists for 90
> > > > > years is merely correctly determined to be non-halting
> > > > > when the behavior of this input is measured by HHH
> > > > > emulating this input according to the rules of the x86
> > > > > language.
> > > > >
> > > > > The same thing applies to the Linz proof yet cannot
> > > > > be understood until after HHH(DDD) and HHH(DD) are
> > > > > fully understood.
> > > > >
> > > >
> > > > HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
> > > > Others of what you say are your imagine and wishes, so far so true.
> > > >
> > >
> > > DDD emulated by HHH accor not the 'HHH' that makes the final decision
(otherwise, it will be an infinite recursive call which you agreed)
> > > ding to the rules of
> > > the x86 language specifies recursive emulation
> > > that cannot possibly reach the final halt state
> > > of DDD.
> > >
> >
> > I have no problem with that. And, you said HHH merely rejects it as non-halting.
> > You had denied HHH can decide the halting property of any input, except DDD/DD/D..
> >
>
> As long as HHH correctly determines the halt status
> of a single input that has no inputs then HHH is
> a correct termination analyzer for that input.
Go it, that is a stronger statement that HHH ONLY decides DD.
I have no problem with that, but be noticed that the HHH inside DD
is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
will be an infinite recursive which cannot make any decision, which
you had agreed)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 13:17 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvo58a$3lnkd$1@dont-email.me> |
| In reply to | #118367 |
On 5/10/2025 1:09 PM, wij wrote:
> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>> On 5/10/2025 12:01 PM, wij wrote:
>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>
>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>
>>>>>>>>>>>> void DDD()
>>>>>>>>>>>> {
>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>> return; // final halt state
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>>>
>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>
>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>
>>>>>>>>>> int DD()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nope.
>>>>>>>>> From I know HHH(DD) decides whether the input DD is "impossible" input or not.
>>>>>>>>>
>>>>>>>>
>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>
>>>>>>>
>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>
>>>>>>
>>>>>> The input that has baffled computer scientists for 90
>>>>>> years is merely correctly determined to be non-halting
>>>>>> when the behavior of this input is measured by HHH
>>>>>> emulating this input according to the rules of the x86
>>>>>> language.
>>>>>>
>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>> fully understood.
>>>>>>
>>>>>
>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
>>>>> Others of what you say are your imagine and wishes, so far so true.
>>>>>
>>>>
>>>> DDD emulated by HHH accor not the 'HHH' that makes the final decision
> (otherwise, it will be an infinite recursive call which you agreed)
>
>>>> ding to the rules of
>>>> the x86 language specifies recursive emulation
>>>> that cannot possibly reach the final halt state
>>>> of DDD.
>>>>
>>>
>>> I have no problem with that. And, you said HHH merely rejects it as non-halting.
>>> You had denied HHH can decide the halting property of any input, except DDD/DD/D..
>>>
>>
>> As long as HHH correctly determines the halt status
>> of a single input that has no inputs then HHH is
>> a correct termination analyzer for that input.
>
> Go it, that is a stronger statement that HHH ONLY decides DD.
> I have no problem with that, but be noticed that the HHH inside DD
> is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
> will be an infinite recursive which cannot make any decision, which
> you had agreed)
>
HHH(DD) correctly determines that its input specifies
recursive emulation when this input is emulated by HHH
HHH according to the rules of the x86 language.
*Thus exactly meets the following specification*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Professor Sipser is the best selling author of theory of
computation textbooks.
It is a pity that he could never take the five more minutes
required to understand the notion of recursive emulation and
thus see the significance of my work.
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 14:24 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvo5k9$3lo73$1@dont-email.me> |
| In reply to | #118368 |
On 5/10/2025 2:17 PM, olcott wrote:
> On 5/10/2025 1:09 PM, wij wrote:
>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>> On 5/10/2025 12:01 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>>
>>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>>
>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>>> return; // final halt state
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>>>>
>>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>>
>>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>>
>>>>>>>>>>> int DD()
>>>>>>>>>>> {
>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope.
>>>>>>>>>> From I know HHH(DD) decides whether the input DD is
>>>>>>>>>> "impossible" input or not.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>>
>>>>>>>
>>>>>>> The input that has baffled computer scientists for 90
>>>>>>> years is merely correctly determined to be non-halting
>>>>>>> when the behavior of this input is measured by HHH
>>>>>>> emulating this input according to the rules of the x86
>>>>>>> language.
>>>>>>>
>>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>>> fully understood.
>>>>>>>
>>>>>>
>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken
>>>>>> input.
>>>>>> Others of what you say are your imagine and wishes, so far so true.
>>>>>>
>>>>>
>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final decision
>> (otherwise, it will be an infinite recursive call which you agreed)
>>
>>>>> ding to the rules of
>>>>> the x86 language specifies recursive emulation
>>>>> that cannot possibly reach the final halt state
>>>>> of DDD.
>>>>>
>>>>
>>>> I have no problem with that. And, you said HHH merely rejects it as
>>>> non-halting.
>>>> You had denied HHH can decide the halting property of any input,
>>>> except DDD/DD/D..
>>>>
>>>
>>> As long as HHH correctly determines the halt status
>>> of a single input that has no inputs then HHH is
>>> a correct termination analyzer for that input.
>>
>> Go it, that is a stronger statement that HHH ONLY decides DD.
>> I have no problem with that, but be noticed that the HHH inside DD
>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
>> will be an infinite recursive which cannot make any decision, which
>> you had agreed)
>>
>
> HHH(DD) correctly determines that its input specifies
> recursive emulation when this input is emulated by HHH
> HHH according to the rules of the x86 language.
>
A lie, as you are on record as admitting that it does not:
On 5/5/2025 8:24 AM, dbush wrote:
> On 5/4/2025 11:03 PM, dbush wrote:
>> On 5/4/2025 10:05 PM, olcott wrote:
>>> On 5/4/2025 7:23 PM, Richard Damon wrote:
>>>> But HHH doesn't correct emulated DD by those rules, as those rules
>>>> do not allow HHH to stop its emulation,
>>>
>>> Sure they do you freaking moron...
>>
>> Then show where in the Intel instruction manual that the execution of
>> any instruction other than a HLT is allowed to stop instead of
>> executing the next instruction.
>>
>> Failure to do so in your next reply, or within one hour of your next
>> post on this newsgroup, will be taken as you official on-the-record
>> admission that there is no such allowance and that HHH does NOT
>> correctly simulate DD.
>
> Let the record show that Peter Olcott made the following post in this
> newsgroup after the above message:
>
> On 5/4/2025 11:04 PM, olcott wrote:
> > D *WOULD NEVER STOP RUNNING UNLESS*
> > indicates that professor Sipser was agreeing
> > to hypotheticals AS *NOT CHANGING THE INPUT*
> >
> > You are taking
> > *WOULD NEVER STOP RUNNING UNLESS*
> > to mean *NEVER STOPS RUNNING* that is incorrect.
>
> And has made no attempt after over 9 hours to show where in the Intel
> instruction manual that execution is allowed to stop after any
> instruction other than HLT.
>
> Therefore, as per the above criteria:
>
> LET THE RECORD SHOW
>
> That Peter Olcott
>
> Has *officially* admitted
>
> That DD is NOT correctly simulated by HHH
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 02:37 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <dc76ef3215a83481dfddc40c466bb9ebc0e77341.camel@gmail.com> |
| In reply to | #118368 |
On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
> On 5/10/2025 1:09 PM, wij wrote:
> > On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
> > > On 5/10/2025 12:01 PM, wij wrote:
> > > > On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
> > > > > On 5/10/2025 11:29 AM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
> > > > > > > On 5/10/2025 11:06 AM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 10:28 AM, wij wrote:
> > > > > > > > > > On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
> > > > > > > > > > > On 5/10/2025 7:37 AM, Bonita Montero wrote:
> > > > > > > > > > > > Am 09.05.2025 um 04:22 schrieb olcott:
> > > > > > > > > > > >
> > > > > > > > > > > > > Look at their replies to this post.
> > > > > > > > > > > > > Not a one of them will agree that
> > > > > > > > > > > > >
> > > > > > > > > > > > > void DDD()
> > > > > > > > > > > > > {
> > > > > > > > > > > > > HHH(DDD);
> > > > > > > > > > > > > return; // final halt state
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > When 1 or more instructions of DDD are correctly
> > > > > > > > > > > > > simulated by HHH then the correctly simulated DDD cannot
> > > > > > > > > > > > > possibly reach its "return" instruction (final halt state).
> > > > > > > > > > > > >
> > > > > > > > > > > > > They have consistently disagreed with this
> > > > > > > > > > > > > simple point for three years.
> > > > > > > > > > > >
> > > > > > > > > > > > I guess that not even a professor of theoretical computer
> > > > > > > > > > > > science would spend years working on so few lines of code.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I created a whole x86utm operating system.
> > > > > > > > > > > It correctly determines that the halting problem's
> > > > > > > > > > > otherwise "impossible" input is actually non halting.
> > > > > > > > > > >
> > > > > > > > > > > int DD()
> > > > > > > > > > > {
> > > > > > > > > > > int Halt_Status = HHH(DD);
> > > > > > > > > > > if (Halt_Status)
> > > > > > > > > > > HERE: goto HERE;
> > > > > > > > > > > return Halt_Status;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > https://github.com/plolcott/x86utm
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Nope.
> > > > > > > > > > From I know HHH(DD) decides whether the input DD is "impossible" input or
> > > > > > > > > > not.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > DD has the standard form of the "impossible" input.
> > > > > > > > > HHH merely rejects it as non-halting.
> > > > > > > > >
> > > > > > > >
> > > > > > > > You said 'merely' rejects it as non-halting.
> > > > > > > > So, POOH do not answer the input of any other function?
> > > > > > > >
> > > > > > >
> > > > > > > The input that has baffled computer scientists for 90
> > > > > > > years is merely correctly determined to be non-halting
> > > > > > > when the behavior of this input is measured by HHH
> > > > > > > emulating this input according to the rules of the x86
> > > > > > > language.
> > > > > > >
> > > > > > > The same thing applies to the Linz proof yet cannot
> > > > > > > be understood until after HHH(DDD) and HHH(DD) are
> > > > > > > fully understood.
> > > > > > >
> > > > > >
> > > > > > HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
> > > > > > Others of what you say are your imagine and wishes, so far so true.
> > > > > >
> > > > >
> > > > > DDD emulated by HHH accor not the 'HHH' that makes the final decision
> > (otherwise, it will be an infinite recursive call which you agreed)
> >
> > > > > ding to the rules of
> > > > > the x86 language specifies recursive emulation
> > > > > that cannot possibly reach the final halt state
> > > > > of DDD.
> > > > >
> > > >
> > > > I have no problem with that. And, you said HHH merely rejects it as non-halting.
> > > > You had denied HHH can decide the halting property of any input, except DDD/DD/D..
> > > >
> > >
> > > As long as HHH correctly determines the halt status
> > > of a single input that has no inputs then HHH is
> > > a correct termination analyzer for that input.
> >
> > Go it, that is a stronger statement that HHH ONLY decides DD.
> > I have no problem with that, but be noticed that the HHH inside DD
> > is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
> > will be an infinite recursive which cannot make any decision, which
> > you had agreed)
> >
>
> HHH(DD) correctly determines that its input specifies
> recursive emulation when this input is emulated by HHH
> HHH according to the rules of the x86 language.
From the about, so you are talking about 'the HHH' which does not compute the final decision.
> *Thus exactly meets the following specification*
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its
> input D until H correctly determines that its simulated D
> would never stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
This H won't be the same HHH inside the DD, otherwise an infinite recursive call happens.
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
> Professor Sipser is the best selling author of theory of
> computation textbooks.
> It is a pity that he could never take the five more minutes
> required to understand the notion of recursive emulation and
> thus see the significance of my work.
You can cite any one, I don't know who Sipsper is.
But yes, it is also a pity that Socrites and Turing did not know POOH.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 13:47 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvo709$3m1oc$1@dont-email.me> |
| In reply to | #118370 |
On 5/10/2025 1:37 PM, wij wrote:
> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>> On 5/10/2025 1:09 PM, wij wrote:
>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>>>> return; // final halt state
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>>>
>>>>>>>>>>>> int DD()
>>>>>>>>>>>> {
>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope.
>>>>>>>>>>> From I know HHH(DD) decides whether the input DD is "impossible" input or
>>>>>>>>>>> not.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The input that has baffled computer scientists for 90
>>>>>>>> years is merely correctly determined to be non-halting
>>>>>>>> when the behavior of this input is measured by HHH
>>>>>>>> emulating this input according to the rules of the x86
>>>>>>>> language.
>>>>>>>>
>>>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>>>> fully understood.
>>>>>>>>
>>>>>>>
>>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
>>>>>>> Others of what you say are your imagine and wishes, so far so true.
>>>>>>>
>>>>>>
>>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final decision
>>> (otherwise, it will be an infinite recursive call which you agreed)
>>>
>>>>>> ding to the rules of
>>>>>> the x86 language specifies recursive emulation
>>>>>> that cannot possibly reach the final halt state
>>>>>> of DDD.
>>>>>>
>>>>>
>>>>> I have no problem with that. And, you said HHH merely rejects it as non-halting.
>>>>> You had denied HHH can decide the halting property of any input, except DDD/DD/D..
>>>>>
>>>>
>>>> As long as HHH correctly determines the halt status
>>>> of a single input that has no inputs then HHH is
>>>> a correct termination analyzer for that input.
>>>
>>> Go it, that is a stronger statement that HHH ONLY decides DD.
>>> I have no problem with that, but be noticed that the HHH inside DD
>>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
>>> will be an infinite recursive which cannot make any decision, which
>>> you had agreed)
>>>
>>
>> HHH(DD) correctly determines that its input specifies
>> recursive emulation when this input is emulated by HHH
>> HHH according to the rules of the x86 language.
>
> From the about, so you are talking about 'the HHH' which does not compute the final decision.
>
HHH does recognize the recursive emulation pattern
of DDD emulated by HHH according to the rules of
the x86 language.
>> *Thus exactly meets the following specification*
>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>> If simulating halt decider H correctly simulates its
>> input D until H correctly determines that its simulated D
>> would never stop running unless aborted then
>>
>> H can abort its simulation of D and correctly report that D
>
> This H won't be the same HHH inside the DD, otherwise an infinite recursive call happens.
>
It must always be the outermost HHH that does this
because it has seen one entire recursive emulation
more than the next inner HHH.
>> specifies a non-halting sequence of configurations.
>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>
>> Professor Sipser is the best selling author of theory of
>> computation textbooks.
>> It is a pity that he could never take the five more minutes
>> required to understand the notion of recursive emulation and
>> thus see the significance of my work.
>
> You can cite any one, I don't know who Sipsper is.
> But yes, it is also a pity that Socrites and Turing did not know POOH.
>
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 03:02 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <b503e969e23dd1b2a6201ba78c82c9ff7906eaae.camel@gmail.com> |
| In reply to | #118371 |
On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
> On 5/10/2025 1:37 PM, wij wrote:
> > On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
> > > On 5/10/2025 1:09 PM, wij wrote:
> > > > On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
> > > > > On 5/10/2025 12:01 PM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
> > > > > > > On 5/10/2025 11:29 AM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 11:06 AM, wij wrote:
> > > > > > > > > > On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
> > > > > > > > > > > On 5/10/2025 10:28 AM, wij wrote:
> > > > > > > > > > > > On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
> > > > > > > > > > > > > On 5/10/2025 7:37 AM, Bonita Montero wrote:
> > > > > > > > > > > > > > Am 09.05.2025 um 04:22 schrieb olcott:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Look at their replies to this post.
> > > > > > > > > > > > > > > Not a one of them will agree that
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > void DDD()
> > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > > HHH(DDD);
> > > > > > > > > > > > > > > return; // final halt state
> > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > When 1 or more instructions of DDD are correctly
> > > > > > > > > > > > > > > simulated by HHH then the correctly simulated DDD cannot
> > > > > > > > > > > > > > > possibly reach its "return" instruction (final halt state).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > They have consistently disagreed with this
> > > > > > > > > > > > > > > simple point for three years.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I guess that not even a professor of theoretical computer
> > > > > > > > > > > > > > science would spend years working on so few lines of code.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I created a whole x86utm operating system.
> > > > > > > > > > > > > It correctly determines that the halting problem's
> > > > > > > > > > > > > otherwise "impossible" input is actually non halting.
> > > > > > > > > > > > >
> > > > > > > > > > > > > int DD()
> > > > > > > > > > > > > {
> > > > > > > > > > > > > int Halt_Status = HHH(DD);
> > > > > > > > > > > > > if (Halt_Status)
> > > > > > > > > > > > > HERE: goto HERE;
> > > > > > > > > > > > > return Halt_Status;
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://github.com/plolcott/x86utm
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Nope.
> > > > > > > > > > > > From I know HHH(DD) decides whether the input DD is "impossible" input
> > > > > > > > > > > > or
> > > > > > > > > > > > not.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > DD has the standard form of the "impossible" input.
> > > > > > > > > > > HHH merely rejects it as non-halting.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > You said 'merely' rejects it as non-halting.
> > > > > > > > > > So, POOH do not answer the input of any other function?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The input that has baffled computer scientists for 90
> > > > > > > > > years is merely correctly determined to be non-halting
> > > > > > > > > when the behavior of this input is measured by HHH
> > > > > > > > > emulating this input according to the rules of the x86
> > > > > > > > > language.
> > > > > > > > >
> > > > > > > > > The same thing applies to the Linz proof yet cannot
> > > > > > > > > be understood until after HHH(DDD) and HHH(DD) are
> > > > > > > > > fully understood.
> > > > > > > > >
> > > > > > > >
> > > > > > > > HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
> > > > > > > > Others of what you say are your imagine and wishes, so far so true.
> > > > > > > >
> > > > > > >
> > > > > > > DDD emulated by HHH accor not the 'HHH' that makes the final decision
> > > > (otherwise, it will be an infinite recursive call which you agreed)
> > > >
> > > > > > > ding to the rules of
> > > > > > > the x86 language specifies recursive emulation
> > > > > > > that cannot possibly reach the final halt state
> > > > > > > of DDD.
> > > > > > >
> > > > > >
> > > > > > I have no problem with that. And, you said HHH merely rejects it as non-halting.
> > > > > > You had denied HHH can decide the halting property of any input, except DDD/DD/D..
> > > > > >
> > > > >
> > > > > As long as HHH correctly determines the halt status
> > > > > of a single input that has no inputs then HHH is
> > > > > a correct termination analyzer for that input.
> > > >
> > > > Go it, that is a stronger statement that HHH ONLY decides DD.
> > > > I have no problem with that, but be noticed that the HHH inside DD
> > > > is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
> > > > will be an infinite recursive which cannot make any decision, which
> > > > you had agreed)
> > > >
> > >
> > > HHH(DD) correctly determines that its input specifies
> > > recursive emulation when this input is emulated by HHH
> > > HHH according to the rules of the x86 language.
> >
> > From the about, so you are talking about 'the HHH' which does not compute the final decision.
> >
>
> HHH does recognize the recursive emulation pattern
> of DDD emulated by HHH according to the rules of
> the x86 language.
>
> > > *Thus exactly meets the following specification*
> > > <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> > > If simulating halt decider H correctly simulates its
> > > input D until H correctly determines that its simulated D
> > > would never stop running unless aborted then
> > >
> > > H can abort its simulation of D and correctly report that D
> >
> > This H won't be the same HHH inside the DD, otherwise an infinite recursive call happens.
> >
>
> It must always be the outermost HHH that does this
> because it has seen one entire recursive emulation
> more than the next inner HHH.
No problem. H is not HHH.
This is also a pitty no one here understand POOH can help AI industry and mankind, even so mini.
> > > specifies a non-halting sequence of configurations.
> > > </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> > >
> > > Professor Sipser is the best selling author of theory of
> > > computation textbooks.
> > > It is a pity that he could never take the five more minutes
> > > required to understand the notion of recursive emulation and
> > > thus see the significance of my work.
> >
> > You can cite any one, I don't know who Sipsper is.
> > But yes, it is also a pity that Socrites and Turing did not know POOH.
> >
>
> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 14:29 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvo9e8$3m1oc$3@dont-email.me> |
| In reply to | #118375 |
On 5/10/2025 2:02 PM, wij wrote:
> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>> On 5/10/2025 1:37 PM, wij wrote:
>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>>>>>> return; // final halt state
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>> From I know HHH(DD) decides whether the input DD is "impossible" input
>>>>>>>>>>>>> or
>>>>>>>>>>>>> not.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The input that has baffled computer scientists for 90
>>>>>>>>>> years is merely correctly determined to be non-halting
>>>>>>>>>> when the behavior of this input is measured by HHH
>>>>>>>>>> emulating this input according to the rules of the x86
>>>>>>>>>> language.
>>>>>>>>>>
>>>>>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>>>>>> fully understood.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
>>>>>>>>> Others of what you say are your imagine and wishes, so far so true.
>>>>>>>>>
>>>>>>>>
>>>>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final decision
>>>>> (otherwise, it will be an infinite recursive call which you agreed)
>>>>>
>>>>>>>> ding to the rules of
>>>>>>>> the x86 language specifies recursive emulation
>>>>>>>> that cannot possibly reach the final halt state
>>>>>>>> of DDD.
>>>>>>>>
>>>>>>>
>>>>>>> I have no problem with that. And, you said HHH merely rejects it as non-halting.
>>>>>>> You had denied HHH can decide the halting property of any input, except DDD/DD/D..
>>>>>>>
>>>>>>
>>>>>> As long as HHH correctly determines the halt status
>>>>>> of a single input that has no inputs then HHH is
>>>>>> a correct termination analyzer for that input.
>>>>>
>>>>> Go it, that is a stronger statement that HHH ONLY decides DD.
>>>>> I have no problem with that, but be noticed that the HHH inside DD
>>>>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
>>>>> will be an infinite recursive which cannot make any decision, which
>>>>> you had agreed)
>>>>>
>>>>
>>>> HHH(DD) correctly determines that its input specifies
>>>> recursive emulation when this input is emulated by HHH
>>>> HHH according to the rules of the x86 language.
>>>
>>> From the about, so you are talking about 'the HHH' which does not compute the final decision.
>>>
>>
>> HHH does recognize the recursive emulation pattern
>> of DDD emulated by HHH according to the rules of
>> the x86 language.
>>
>>>> *Thus exactly meets the following specification*
>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>> If simulating halt decider H correctly simulates its
>>>> input D until H correctly determines that its simulated D
>>>> would never stop running unless aborted then
>>>>
>>>> H can abort its simulation of D and correctly report that D
>>>
>>> This H won't be the same HHH inside the DD, otherwise an infinite recursive call happens.
>>>
>>
>> It must always be the outermost HHH that does this
>> because it has seen one entire recursive emulation
>> more than the next inner HHH.
>
> No problem. H is not HHH.
>
The H is the template that Professor Sipser agreed to.
HHH is a specific implementation of H.
> This is also a pitty no one here understand POOH can help AI industry and mankind, even so mini.
>
It is the same halting problem after its mistake
has been corrected. So just like how ZFC corrected
the error in set theory so that Russell's Paradox
could be correctly decided, HHH corrects the error
in the halting problem proof so that the otherwise
impossible input is correctly decided.
The original set theory is now called naive set
theory after its mistake has been corrected. Thus
the original halting problem proofs can now be
called the naive halting problem proofs.
The halting problem itself remains the same, yet
loses its most important proof.
>>>> specifies a non-halting sequence of configurations.
>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>
>>>> Professor Sipser is the best selling author of theory of
>>>> computation textbooks.
>>>> It is a pity that he could never take the five more minutes
>>>> required to understand the notion of recursive emulation and
>>>> thus see the significance of my work.
>>>
>>> You can cite any one, I don't know who Sipsper is.
>>> But yes, it is also a pity that Socrites and Turing did not know POOH.
>>>
>>
>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>
>
>
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 05:44 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <b9cec56c1d257e09fdf8043f02f123a4243de6e1.camel@gmail.com> |
| In reply to | #118388 |
On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
> On 5/10/2025 2:02 PM, wij wrote:
> > On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
> > > On 5/10/2025 1:37 PM, wij wrote:
> > > > On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
> > > > > On 5/10/2025 1:09 PM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
> > > > > > > On 5/10/2025 12:01 PM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 11:29 AM, wij wrote:
> > > > > > > > > > On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
> > > > > > > > > > > On 5/10/2025 11:06 AM, wij wrote:
> > > > > > > > > > > > On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
> > > > > > > > > > > > > On 5/10/2025 10:28 AM, wij wrote:
> > > > > > > > > > > > > > On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
> > > > > > > > > > > > > > > On 5/10/2025 7:37 AM, Bonita Montero wrote:
> > > > > > > > > > > > > > > > Am 09.05.2025 um 04:22 schrieb olcott:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Look at their replies to this post.
> > > > > > > > > > > > > > > > > Not a one of them will agree that
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > void DDD()
> > > > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > > > > HHH(DDD);
> > > > > > > > > > > > > > > > > return; // final halt state
> > > > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > When 1 or more instructions of DDD are correctly
> > > > > > > > > > > > > > > > > simulated by HHH then the correctly simulated DDD cannot
> > > > > > > > > > > > > > > > > possibly reach its "return" instruction (final halt state).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > They have consistently disagreed with this
> > > > > > > > > > > > > > > > > simple point for three years.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I guess that not even a professor of theoretical computer
> > > > > > > > > > > > > > > > science would spend years working on so few lines of code.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I created a whole x86utm operating system.
> > > > > > > > > > > > > > > It correctly determines that the halting problem's
> > > > > > > > > > > > > > > otherwise "impossible" input is actually non halting.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > int DD()
> > > > > > > > > > > > > > > {
> > > > > > > > > > > > > > > int Halt_Status = HHH(DD);
> > > > > > > > > > > > > > > if (Halt_Status)
> > > > > > > > > > > > > > > HERE: goto HERE;
> > > > > > > > > > > > > > > return Halt_Status;
> > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > https://github.com/plolcott/x86utm
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Nope.
> > > > > > > > > > > > > > From I know HHH(DD) decides whether the input DD is "impossible"
> > > > > > > > > > > > > > input
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > not.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > DD has the standard form of the "impossible" input.
> > > > > > > > > > > > > HHH merely rejects it as non-halting.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > You said 'merely' rejects it as non-halting.
> > > > > > > > > > > > So, POOH do not answer the input of any other function?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > The input that has baffled computer scientists for 90
> > > > > > > > > > > years is merely correctly determined to be non-halting
> > > > > > > > > > > when the behavior of this input is measured by HHH
> > > > > > > > > > > emulating this input according to the rules of the x86
> > > > > > > > > > > language.
> > > > > > > > > > >
> > > > > > > > > > > The same thing applies to the Linz proof yet cannot
> > > > > > > > > > > be understood until after HHH(DDD) and HHH(DD) are
> > > > > > > > > > > fully understood.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
> > > > > > > > > > Others of what you say are your imagine and wishes, so far so true.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > DDD emulated by HHH accor not the 'HHH' that makes the final decision
> > > > > > (otherwise, it will be an infinite recursive call which you agreed)
> > > > > >
> > > > > > > > > ding to the rules of
> > > > > > > > > the x86 language specifies recursive emulation
> > > > > > > > > that cannot possibly reach the final halt state
> > > > > > > > > of DDD.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I have no problem with that. And, you said HHH merely rejects it as non-halting.
> > > > > > > > You had denied HHH can decide the halting property of any input, except DDD/DD/D..
> > > > > > > >
> > > > > > >
> > > > > > > As long as HHH correctly determines the halt status
> > > > > > > of a single input that has no inputs then HHH is
> > > > > > > a correct termination analyzer for that input.
> > > > > >
> > > > > > Go it, that is a stronger statement that HHH ONLY decides DD.
> > > > > > I have no problem with that, but be noticed that the HHH inside DD
> > > > > > is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
> > > > > > will be an infinite recursive which cannot make any decision, which
> > > > > > you had agreed)
> > > > > >
> > > > >
> > > > > HHH(DD) correctly determines that its input specifies
> > > > > recursive emulation when this input is emulated by HHH
> > > > > HHH according to the rules of the x86 language.
> > > >
> > > > From the about, so you are talking about 'the HHH' which does not compute the final
> > > > decision.
> > > >
> > >
> > > HHH does recognize the recursive emulation pattern
> > > of DDD emulated by HHH according to the rules of
> > > the x86 language.
> > >
> > > > > *Thus exactly meets the following specification*
> > > > > <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> > > > > If simulating halt decider H correctly simulates its
> > > > > input D until H correctly determines that its simulated D
> > > > > would never stop running unless aborted then
> > > > >
> > > > > H can abort its simulation of D and correctly report that D
> > > >
> > > > This H won't be the same HHH inside the DD, otherwise an infinite recursive call happens.
> > > >
> > >
> > > It must always be the outermost HHH that does this
> > > because it has seen one entire recursive emulation
> > > more than the next inner HHH.
> >
> > No problem. H is not HHH.
> >
>
> The H is the template that Professor Sipser agreed to.
> HHH is a specific implementation of H.
>
> > This is also a pitty no one here understand POOH can help AI industry and mankind, even so mini.
> >
>
> It is the same halting problem after its mistake
> has been corrected. So just like how ZFC corrected
> the error in set theory so that Russell's Paradox
> could be correctly decided, HHH corrects the error
> in the halting problem proof so that the otherwise
> impossible input is correctly decided.
I don't know what that part of set theory works.
(My feeling is that they are garbage, for reasons,
unless you are doing logic researches)
> The original set theory is now called naive set
> theory after its mistake has been corrected. Thus
> the original halting problem proofs can now be
> called the naive halting problem proofs.
Traditional logic (or the part mostly used) that won't
cause confusion is more reliable.
> The halting problem itself remains the same, yet
> loses its most important proof.
HP is based on TM. Proof of any other kind other than TM have to be cautious.
The part of 'logic' or 'philosophy' I saw from your posts are very dubious,
hardly valid for HP.
I think you are referring to (and confused by) self-reference.
Sadly, the HP proof has nothing to do with self-reference.
Let me make the counter example this way:
void D() {
for(int X; X<LimX; ++X) { // X would enum all possible 'TM' whose value<LimX
if(simu(H',X) while(1); // H' decides whether X halts or not
} // (If X is not a valid program, simu(H',X) returns 0.
// So, this H' is not exactly the halting decider H
// but can be build from the original H)
}
So, there exists an encoding X that functions the same as D that H cannot decide.
(note that no function call or self-reference in the above D)
The above D can be simplified to form another "impossible input":
void D2() {
if(simu(H',D2') while(1); // D2' is the 'source' of D2, also no self ref. RECURSIVELY.
}
> > > > > specifies a non-halting sequence of configurations.
> > > > > </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> > > > >
> > > > > Professor Sipser is the best selling author of theory of
> > > > > computation textbooks.
> > > > > It is a pity that he could never take the five more minutes
> > > > > required to understand the notion of recursive emulation and
> > > > > thus see the significance of my work.
> > > >
> > > > You can cite any one, I don't know who Sipsper is.
> > > > But yes, it is also a pity that Socrites and Turing did not know POOH.
> > > >
> > >
> > > https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
> > >
> >
> >
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 17:03 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvoife$3ofmu$1@dont-email.me> |
| In reply to | #118404 |
On 5/10/2025 4:44 PM, wij wrote:
> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>> On 5/10/2025 2:02 PM, wij wrote:
>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>>> On 5/10/2025 1:37 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>>>>>>>> return; // final halt state
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>> From I know HHH(DD) decides whether the input DD is "impossible"
>>>>>>>>>>>>>>> input
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The input that has baffled computer scientists for 90
>>>>>>>>>>>> years is merely correctly determined to be non-halting
>>>>>>>>>>>> when the behavior of this input is measured by HHH
>>>>>>>>>>>> emulating this input according to the rules of the x86
>>>>>>>>>>>> language.
>>>>>>>>>>>>
>>>>>>>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>>>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>>>>>>>> fully understood.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
>>>>>>>>>>> Others of what you say are your imagine and wishes, so far so true.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final decision
>>>>>>> (otherwise, it will be an infinite recursive call which you agreed)
>>>>>>>
>>>>>>>>>> ding to the rules of
>>>>>>>>>> the x86 language specifies recursive emulation
>>>>>>>>>> that cannot possibly reach the final halt state
>>>>>>>>>> of DDD.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have no problem with that. And, you said HHH merely rejects it as non-halting.
>>>>>>>>> You had denied HHH can decide the halting property of any input, except DDD/DD/D..
>>>>>>>>>
>>>>>>>>
>>>>>>>> As long as HHH correctly determines the halt status
>>>>>>>> of a single input that has no inputs then HHH is
>>>>>>>> a correct termination analyzer for that input.
>>>>>>>
>>>>>>> Go it, that is a stronger statement that HHH ONLY decides DD.
>>>>>>> I have no problem with that, but be noticed that the HHH inside DD
>>>>>>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
>>>>>>> will be an infinite recursive which cannot make any decision, which
>>>>>>> you had agreed)
>>>>>>>
>>>>>>
>>>>>> HHH(DD) correctly determines that its input specifies
>>>>>> recursive emulation when this input is emulated by HHH
>>>>>> HHH according to the rules of the x86 language.
>>>>>
>>>>> From the about, so you are talking about 'the HHH' which does not compute the final
>>>>> decision.
>>>>>
>>>>
>>>> HHH does recognize the recursive emulation pattern
>>>> of DDD emulated by HHH according to the rules of
>>>> the x86 language.
>>>>
>>>>>> *Thus exactly meets the following specification*
>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>> If simulating halt decider H correctly simulates its
>>>>>> input D until H correctly determines that its simulated D
>>>>>> would never stop running unless aborted then
>>>>>>
>>>>>> H can abort its simulation of D and correctly report that D
>>>>>
>>>>> This H won't be the same HHH inside the DD, otherwise an infinite recursive call happens.
>>>>>
>>>>
>>>> It must always be the outermost HHH that does this
>>>> because it has seen one entire recursive emulation
>>>> more than the next inner HHH.
>>>
>>> No problem. H is not HHH.
>>>
>>
>> The H is the template that Professor Sipser agreed to.
>> HHH is a specific implementation of H.
>>
>>> This is also a pitty no one here understand POOH can help AI industry and mankind, even so mini.
>>>
>>
>> It is the same halting problem after its mistake
>> has been corrected. So just like how ZFC corrected
>> the error in set theory so that Russell's Paradox
>> could be correctly decided, HHH corrects the error
>> in the halting problem proof so that the otherwise
>> impossible input is correctly decided.
>
> I don't know what that part of set theory works.
> (My feeling is that they are garbage, for reasons,
> unless you are doing logic researches)
>
>> The original set theory is now called naive set
>> theory after its mistake has been corrected. Thus
>> the original halting problem proofs can now be
>> called the naive halting problem proofs.
>
> Traditional logic (or the part mostly used) that won't
> cause confusion is more reliable.
>
>> The halting problem itself remains the same, yet
>> loses its most important proof.
>
> HP is based on TM. Proof of any other kind other than TM have to be cautious.
Unless this is done as an actual simulating termination
analyzer in a high level language like C and it operates
on a 100% complete exactingly precise input specification
such as the x86 language too many details slip through
the cracks of vagueness.
For example no one ever even noticed that it is 100%
impossible to derive an input that actually does the
opposite of whatever value that its termination
analyzer reports.
All of these proofs remain anchored in that false
assumption.
> The part of 'logic' or 'philosophy' I saw from your posts are very dubious,
> hardly valid for HP.
>
> I think you are referring to (and confused by) self-reference.
> Sadly, the HP proof has nothing to do with self-reference.
> Let me make the counter example this way:
>
> void D() {
> for(int X; X<LimX; ++X) { // X would enum all possible 'TM' whose value<LimX
> if(simu(H',X) while(1); // H' decides whether X halts or not
> } // (If X is not a valid program, simu(H',X) returns 0.
> // So, this H' is not exactly the halting decider H
> // but can be build from the original H)
> }
>
> So, there exists an encoding X that functions the same as D that H cannot decide.
> (note that no function call or self-reference in the above D)
>
> The above D can be simplified to form another "impossible input":
>
> void D2() {
> if(simu(H',D2') while(1); // D2' is the 'source' of D2, also no self ref. RECURSIVELY.
> }
>
I have no idea what you are saying.
>>>>>> specifies a non-halting sequence of configurations.
>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>>
>>>>>> Professor Sipser is the best selling author of theory of
>>>>>> computation textbooks.
>>>>>> It is a pity that he could never take the five more minutes
>>>>>> required to understand the notion of recursive emulation and
>>>>>> thus see the significance of my work.
>>>>>
>>>>> You can cite any one, I don't know who Sipsper is.
>>>>> But yes, it is also a pity that Socrites and Turing did not know POOH.
>>>>>
>>>>
>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>>>
>>>
>>>
>>
>>
>
>
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 18:39 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvokim$3n3km$3@dont-email.me> |
| In reply to | #118405 |
On 5/10/2025 6:03 PM, olcott wrote:
> On 5/10/2025 4:44 PM, wij wrote:
>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>> On 5/10/2025 2:02 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:
>>>>> On 5/10/2025 1:37 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>>>>>>> On 5/10/2025 1:09 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>>>>>>>>> return; // final halt state
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt
>>>>>>>>>>>>>>>>>>> state).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>>>>>>>>> science would spend years working on so few lines of
>>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>>> From I know HHH(DD) decides whether the input DD
>>>>>>>>>>>>>>>> is "impossible"
>>>>>>>>>>>>>>>> input
>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>>>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input that has baffled computer scientists for 90
>>>>>>>>>>>>> years is merely correctly determined to be non-halting
>>>>>>>>>>>>> when the behavior of this input is measured by HHH
>>>>>>>>>>>>> emulating this input according to the rules of the x86
>>>>>>>>>>>>> language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>>>>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>>>>>>>>> fully understood.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/
>>>>>>>>>>>> midtaken input.
>>>>>>>>>>>> Others of what you say are your imagine and wishes, so far
>>>>>>>>>>>> so true.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final
>>>>>>>>>>> decision
>>>>>>>> (otherwise, it will be an infinite recursive call which you agreed)
>>>>>>>>
>>>>>>>>>>> ding to the rules of
>>>>>>>>>>> the x86 language specifies recursive emulation
>>>>>>>>>>> that cannot possibly reach the final halt state
>>>>>>>>>>> of DDD.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have no problem with that. And, you said HHH merely rejects
>>>>>>>>>> it as non-halting.
>>>>>>>>>> You had denied HHH can decide the halting property of any
>>>>>>>>>> input, except DDD/DD/D..
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As long as HHH correctly determines the halt status
>>>>>>>>> of a single input that has no inputs then HHH is
>>>>>>>>> a correct termination analyzer for that input.
>>>>>>>>
>>>>>>>> Go it, that is a stronger statement that HHH ONLY decides DD.
>>>>>>>> I have no problem with that, but be noticed that the HHH inside DD
>>>>>>>> is not the 'HHH' that makes the final decision (otherwise, the
>>>>>>>> 'HHH'
>>>>>>>> will be an infinite recursive which cannot make any decision, which
>>>>>>>> you had agreed)
>>>>>>>>
>>>>>>>
>>>>>>> HHH(DD) correctly determines that its input specifies
>>>>>>> recursive emulation when this input is emulated by HHH
>>>>>>> HHH according to the rules of the x86 language.
>>>>>>
>>>>>> From the about, so you are talking about 'the HHH' which does
>>>>>> not compute the final
>>>>>> decision.
>>>>>>
>>>>>
>>>>> HHH does recognize the recursive emulation pattern
>>>>> of DDD emulated by HHH according to the rules of
>>>>> the x86 language.
>>>>>
>>>>>>> *Thus exactly meets the following specification*
>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>>> 10/13/2022>
>>>>>>> If simulating halt decider H correctly simulates its
>>>>>>> input D until H correctly determines that its simulated D
>>>>>>> would never stop running unless aborted then
>>>>>>>
>>>>>>> H can abort its simulation of D and correctly report that D
>>>>>>
>>>>>> This H won't be the same HHH inside the DD, otherwise an infinite
>>>>>> recursive call happens.
>>>>>>
>>>>>
>>>>> It must always be the outermost HHH that does this
>>>>> because it has seen one entire recursive emulation
>>>>> more than the next inner HHH.
>>>>
>>>> No problem. H is not HHH.
>>>>
>>>
>>> The H is the template that Professor Sipser agreed to.
>>> HHH is a specific implementation of H.
>>>
>>>> This is also a pitty no one here understand POOH can help AI
>>>> industry and mankind, even so mini.
>>>>
>>>
>>> It is the same halting problem after its mistake
>>> has been corrected. So just like how ZFC corrected
>>> the error in set theory so that Russell's Paradox
>>> could be correctly decided, HHH corrects the error
>>> in the halting problem proof so that the otherwise
>>> impossible input is correctly decided.
>>
>> I don't know what that part of set theory works.
>> (My feeling is that they are garbage, for reasons,
>> unless you are doing logic researches)
>>
>>> The original set theory is now called naive set
>>> theory after its mistake has been corrected. Thus
>>> the original halting problem proofs can now be
>>> called the naive halting problem proofs.
>>
>> Traditional logic (or the part mostly used) that won't
>> cause confusion is more reliable.
>>
>>> The halting problem itself remains the same, yet
>>> loses its most important proof.
>>
>> HP is based on TM. Proof of any other kind other than TM have to be
>> cautious.
>
> Unless this is done as an actual simulating termination
> analyzer
That assumes one exists. Linz and others proved it doesn't, and you
have *explicitly* agreed with that.
On 5/5/2025 5:39 PM, olcott wrote:
> On 5/5/2025 4:31 PM, dbush wrote:
>> Strawman. The square root of a dead rabbit does not exist, but the
>> question of whether any arbitrary algorithm X with input Y halts when
>> executed directly has a correct answer in all cases.
>>
>
> It has a correct answer that cannot ever be computed
[toc] | [prev] | [next] | [standalone]
Page 13 of 32 — ← Prev page 1 … 11 12 [13] 14 15 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web