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 14 of 32 — ← Prev page 1 … 12 13 [14] 15 16 … 32 Next page →
| From | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-05-10 22:55 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <kPQTP.680776$4AM6.646736@fx17.ams4> |
| In reply to | #118406 |
On Sat, 10 May 2025 18:39:18 -0400, dbush wrote:
> 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.
Linz and others haven't proved jack shit: the contradiction at the heart
of the halting problem is a category (type) error, i.e. ill-formed.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 19:03 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvolvd$3n3km$4@dont-email.me> |
| In reply to | #118407 |
On 5/10/2025 6:55 PM, Mr Flibble wrote:
> On Sat, 10 May 2025 18:39:18 -0400, dbush wrote:
>
>> 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.
>
> Linz and others haven't proved jack shit: the contradiction at the heart
> of the halting problem is a category (type) error, i.e. ill-formed.
>
There's no such thing as an ill-formed contradiction.
Once an assumption is made, *any* contradiction proves that assumption
false. It doesn't matter how outlandish the contradiction might seem.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-05-10 23:35 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <OoRTP.97974$0ia.90132@fx11.ams4> |
| In reply to | #118408 |
On Sat, 10 May 2025 19:03:09 -0400, dbush wrote:
> On 5/10/2025 6:55 PM, Mr Flibble wrote:
>> On Sat, 10 May 2025 18:39:18 -0400, dbush wrote:
>>
>>> 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.
>>
>> Linz and others haven't proved jack shit: the contradiction at the
>> heart of the halting problem is a category (type) error, i.e.
>> ill-formed.
>>
>>
> There's no such thing as an ill-formed contradiction.
False.
>
> Once an assumption is made, *any* contradiction proves that assumption
> false. It doesn't matter how outlandish the contradiction might seem.
For a contradiction to be well-formed its two propositions must be of the
same category otherwise the contradiction is ill-formed as is the case for
the contradiction at the heart of the Halting Problem.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 18:57 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <dfdeb144781090e3a38f7918b642255f06cbb9e0@i2pn2.org> |
| In reply to | #118405 |
On 5/10/25 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 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.
Nope. You need to use the vagueness of High level languages and complex
machines to hide your compuational shenanigans.
>
> 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.
Sure they have. Your problem is you don't understand what the meaning of
correct or behavior is.
> All of these proofs remain anchored in that false
> assumption.
No, all your preofs are anchored in false assumptions, like that 1 step
correctly emulated is a correctly emulated program.
I guess you think answer 1 question on the IQ test coffectly and then
stopping means you got the test correct, even though you never answered
the other 99.
"Correct Emuation" means correctly emulating *ALL* the steps, and 1 to n
steps was not all.
>
>> 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.
>
Yep, that is your problem.
>>>>>>> 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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 09:17 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <09cea75db07408dc9203aca3fb74408ad3a095b4.camel@gmail.com> |
| In reply to | #118405 |
On Sat, 2025-05-10 at 17:03 -0500, 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 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.
You don't know the counter example in the HP proof, your D is not the case what HP says.
> > > > > > > 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 20:26 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvoubl$3qtsi$1@dont-email.me> |
| In reply to | #118421 |
On 5/10/2025 8:17 PM, wij wrote:
> On Sat, 2025-05-10 at 17:03 -0500, 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:
>
> You don't know the counter example in the HP proof, your D is not the case what HP says.
>
Sure I do this is it! (as correctly encoded in C)
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-11 02:43 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvovb7$3qqcv$1@dont-email.me> |
| In reply to | #118424 |
On 11/05/2025 02:26, olcott wrote:
> On 5/10/2025 8:17 PM, wij wrote:
>> On Sat, 2025-05-10 at 17:03 -0500, 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:
>
>>
>> You don't know the counter example in the HP proof, your D is
>> not the case what HP says.
>>
>
> Sure I do this is it! (as correctly encoded in C)
'correctly' is a bit of a stretch. 'Incorrectly' would be closer
to the mark.
$ gcc -c -o hhhagain.o hhhagain.c
hhhagain.c: In function ‘DD’:
hhhagain.c:6:25: warning: passing argument 1 of ‘HHH’ from
incompatible pointer type [-Wincompatible-pointer-types]
6 | int Halt_Status = HHH(DD);
| ^~
| |
| int (*)()
hhhagain.c:2:13: note: expected ‘ptr’ {aka ‘void (*)()’} but
argument is of type ‘int (*)()’
2 | int HHH(ptr P);
| ~~~~^
hhhagain.c: In function ‘main’:
hhhagain.c:14:7: warning: passing argument 1 of ‘HHH’ from
incompatible pointer type [-Wincompatible-pointer-types]
14 | HHH(DD);
| ^~
| |
| int (*)()
hhhagain.c:2:13: note: expected ‘ptr’ {aka ‘void (*)()’} but
argument is of type ‘int (*)()’
2 | int HHH(ptr P);
| ~~~~^
Tedious details are best left to competent programmers.
What you need is a 6" brush, a few tins of white paint, a ladder,
and a nice big barn.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 09:44 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <bc4fb153ff914177dba706ce6e0dfb467e2126eb.camel@gmail.com> |
| In reply to | #118424 |
On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
> On 5/10/2025 8:17 PM, wij wrote:
> > On Sat, 2025-05-10 at 17:03 -0500, 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:
>
> >
> > You don't know the counter example in the HP proof, your D is not the case what HP says.
> >
>
> Sure I do this is it! (as correctly encoded in C)
>
> typedef void (*ptr)();
> int HHH(ptr P);
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> HHH(DD);
> }
>
>
Try to convert it to TM language to know you know nothing.
To refute the HP, you need to understand what it exactly means in TM.
Assembly (or C) also work, but you need to understand more details and
be able to map every assembly instruction or C expressions to TM language.
The form of the DD above (in some books maybe) is for layman to understand,
which is not exactly the case that the HP provides. Don't be silly.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 20:56 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvp04i$3r5li$3@dont-email.me> |
| In reply to | #118426 |
On 5/10/2025 8:44 PM, wij wrote:
> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>> On 5/10/2025 8:17 PM, wij wrote:
>>> On Sat, 2025-05-10 at 17:03 -0500, 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:
>>
>>>
>>> You don't know the counter example in the HP proof, your D is not the case what HP says.
>>>
>>
>> Sure I do this is it! (as correctly encoded in C)
>>
>> typedef void (*ptr)();
>> int HHH(ptr P);
>>
>> int DD()
>> {
>> int Halt_Status = HHH(DD);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> int main()
>> {
>> HHH(DD);
>> }
>>
>>
>
> Try to convert it to TM language to know you know nothing.
>
I spent 22 years on this. I started with the Linz text
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
cannot possibly reach its simulated final halt state
⟨Ĥ.qn⟩
> To refute the HP, you need to understand what it exactly means in TM.
I have known this for 22 years.
> Assembly (or C) also work, but you need to understand more details and
> be able to map every assembly instruction or C expressions to TM language.
> The form of the DD above (in some books maybe) is for layman to understand,
> which is not exactly the case that the HP provides. Don't be silly.
>
--
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 10:09 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <853816e160c7b3fe75c71f0728e72989d9fb2e41.camel@gmail.com> |
| In reply to | #118431 |
On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
> On 5/10/2025 8:44 PM, wij wrote:
> > On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
> > > On 5/10/2025 8:17 PM, wij wrote:
> > > > On Sat, 2025-05-10 at 17:03 -0500, 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:
> > >
> > > >
> > > > You don't know the counter example in the HP proof, your D is not the case what HP says.
> > > >
> > >
> > > Sure I do this is it! (as correctly encoded in C)
> > >
> > > typedef void (*ptr)();
> > > int HHH(ptr P);
> > >
> > > int DD()
> > > {
> > > int Halt_Status = HHH(DD);
> > > if (Halt_Status)
> > > HERE: goto HERE;
> > > return Halt_Status;
> > > }
> > >
> > > int main()
> > > {
> > > HHH(DD);
> > > }
> > >
> > >
> >
> > Try to convert it to TM language to know you know nothing.
> >
>
> I spent 22 years on this. I started with the Linz text
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> or
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>
> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
> cannot possibly reach its simulated final halt state
> ⟨Ĥ.qn⟩
>
> > To refute the HP, you need to understand what it exactly means in TM.
>
> I have known this for 22 years.
A working TM. Build it explicitly from transition function, then explain
your derivation. You know nothing.
> > Assembly (or C) also work, but you need to understand more details and
> > be able to map every assembly instruction or C expressions to TM language.
> > The form of the DD above (in some books maybe) is for layman to understand,
> > which is not exactly the case that the HP provides. Don't be silly.
> >
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 21:19 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvp1fm$3r5li$4@dont-email.me> |
| In reply to | #118434 |
On 5/10/2025 9:09 PM, wij wrote:
> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>> On 5/10/2025 8:44 PM, wij wrote:
>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 17:03 -0500, 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:
>>>>
>>>>>
>>>>> You don't know the counter example in the HP proof, your D is not the case what HP says.
>>>>>
>>>>
>>>> Sure I do this is it! (as correctly encoded in C)
>>>>
>>>> typedef void (*ptr)();
>>>> int HHH(ptr P);
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> HHH(DD);
>>>> }
>>>>
>>>>
>>>
>>> Try to convert it to TM language to know you know nothing.
>>>
>>
>> I spent 22 years on this. I started with the Linz text
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> or
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> (a) Ĥ copies its input ⟨Ĥ⟩
>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>
>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>> cannot possibly reach its simulated final halt state
>> ⟨Ĥ.qn⟩
>>
>>> To refute the HP, you need to understand what it exactly means in TM.
>>
>> I have known this for 22 years.
>
> A working TM. Build it explicitly from transition function, then explain
> your derivation. You know nothing.
>
That would be like examining how an operating system
works entirely from its machine code.
We only have to actually know one detail:
Every counter-example input encoded in any model
of computation always specifies recursive simulation
that never halts to its corresponding simulating
termination analyzer.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-11 07:03 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <bd98b08c432b1bd38ae49288dffac3f66c55549a@i2pn2.org> |
| In reply to | #118436 |
On 5/10/25 10:19 PM, olcott wrote:
> On 5/10/2025 9:09 PM, wij wrote:
>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>> On 5/10/2025 8:44 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 17:03 -0500, 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:
>>>>>
>>>>>>
>>>>>> You don't know the counter example in the HP proof, your D is not
>>>>>> the case what HP says.
>>>>>>
>>>>>
>>>>> Sure I do this is it! (as correctly encoded in C)
>>>>>
>>>>> typedef void (*ptr)();
>>>>> int HHH(ptr P);
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> HHH(DD);
>>>>> }
>>>>>
>>>>>
>>>>
>>>> Try to convert it to TM language to know you know nothing.
>>>>
>>>
>>> I spent 22 years on this. I started with the Linz text
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> or
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>
>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>>> cannot possibly reach its simulated final halt state
>>> ⟨Ĥ.qn⟩
>>>
>>>> To refute the HP, you need to understand what it exactly means in TM.
>>>
>>> I have known this for 22 years.
>>
>> A working TM. Build it explicitly from transition function, then explain
>> your derivation. You know nothing.
>>
>
> That would be like examining how an operating system
> works entirely from its machine code.
And what is wrong with that?
Some parts need to be analyzed at that level.
>
> We only have to actually know one detail:
> Every counter-example input encoded in any model
> of computation always specifies recursive simulation
> that never halts to its corresponding simulating
> termination analyzer.
>
You are missing an important qualifier, it specifices FINITE recursive
simulation as each level of the simulation limits how deep it will allow
its self to go, or it just fails to meet its requirement to be a decider.
Your error is thinking that you can have as an input, claimed to be the
same for every decider, that doesn't include the code it uses. WHen you
include that needed code, they are no longer the "same input".
In simpler terms, your argument uses the equivalent of assume x = =, and
then divides by x assuming that x is not equal to 0.
Sorry, your world is just based on you believing your own lies.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 22:34 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <b049926b61baa5d69d11655a8af06e537b7acd71.camel@gmail.com> |
| In reply to | #118436 |
On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
> On 5/10/2025 9:09 PM, wij wrote:
> > On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
> > > On 5/10/2025 8:44 PM, wij wrote:
> > > > On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
> > > > > On 5/10/2025 8:17 PM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 17:03 -0500, 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:
> > > > >
> > > > > >
> > > > > > You don't know the counter example in the HP proof, your D is not the case what HP says.
> > > > > >
> > > > >
> > > > > Sure I do this is it! (as correctly encoded in C)
> > > > >
> > > > > typedef void (*ptr)();
> > > > > int HHH(ptr P);
> > > > >
> > > > > int DD()
> > > > > {
> > > > > int Halt_Status = HHH(DD);
> > > > > if (Halt_Status)
> > > > > HERE: goto HERE;
> > > > > return Halt_Status;
> > > > > }
> > > > >
> > > > > int main()
> > > > > {
> > > > > HHH(DD);
> > > > > }
> > > > >
> > > > >
> > > >
> > > > Try to convert it to TM language to know you know nothing.
> > > >
> > >
> > > I spent 22 years on this. I started with the Linz text
> > >
> > > When Ĥ is applied to ⟨Ĥ⟩
> > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> > > or
> > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> > >
> > > (a) Ĥ copies its input ⟨Ĥ⟩
> > > (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> > > (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
> > >
> > > Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
> > > cannot possibly reach its simulated final halt state
> > > ⟨Ĥ.qn⟩
> > >
> > > > To refute the HP, you need to understand what it exactly means in TM.
> > >
> > > I have known this for 22 years.
> >
> > A working TM. Build it explicitly from transition function, then explain
> > your derivation. You know nothing.
> >
>
> That would be like examining how an operating system
> works entirely from its machine code.
You are refuting a CS foundamental theorem (i.e. HP) officially.
So, yes, and actually MORE need to be done (beyond your imagination).
Knowing a car or smart phone,... is far different from making one.
Knowing E=mc^2 is far from knowing relativity, making A-bomb (actually, making
A-bomb don't need to know E=mc^2, people are often fooled by popular saying)
Every chapter of Linz's book, C text textbook has exercises, you need to those
exercises AT LEAST to comment CS (and computation theory is more advanced topic
than TM). Saying so is because we know you can't do the exercise and boast lots
about TM stuff (and pretty much anything else from just reading words), even
about theorem.
> We only have to actually know one detail:
> Every counter-example input encoded in any model
> of computation always specifies recursive simulation
> that never halts to its corresponding simulating
> termination analyzer.
More example here that you don't understand nearly all CS terms.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 10:38 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvqga9$gldn$3@dont-email.me> |
| In reply to | #118477 |
On 5/11/2025 9:34 AM, wij wrote:
> On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
>> On 5/10/2025 9:09 PM, wij wrote:
>>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>>> On 5/10/2025 8:44 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 17:03 -0500, 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:
>>>>>>
>>>>>>>
>>>>>>> You don't know the counter example in the HP proof, your D is not the case what HP says.
>>>>>>>
>>>>>>
>>>>>> Sure I do this is it! (as correctly encoded in C)
>>>>>>
>>>>>> typedef void (*ptr)();
>>>>>> int HHH(ptr P);
>>>>>>
>>>>>> int DD()
>>>>>> {
>>>>>> int Halt_Status = HHH(DD);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> HHH(DD);
>>>>>> }
>>>>>>
>>>>>>
>>>>>
>>>>> Try to convert it to TM language to know you know nothing.
>>>>>
>>>>
>>>> I spent 22 years on this. I started with the Linz text
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> or
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>>
>>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>>>> cannot possibly reach its simulated final halt state
>>>> ⟨Ĥ.qn⟩
>>>>
>>>>> To refute the HP, you need to understand what it exactly means in TM.
>>>>
>>>> I have known this for 22 years.
>>>
>>> A working TM. Build it explicitly from transition function, then explain
>>> your derivation. You know nothing.
>>>
>>
>> That would be like examining how an operating system
>> works entirely from its machine code.
>
> You are refuting a CS foundamental theorem (i.e. HP) officially.
> So, yes, and actually MORE need to be done (beyond your imagination).
>
> Knowing a car or smart phone,... is far different from making one.
> Knowing E=mc^2 is far from knowing relativity, making A-bomb (actually, making
> A-bomb don't need to know E=mc^2, people are often fooled by popular saying)
>
> Every chapter of Linz's book, C text textbook has exercises, you need to those
> exercises AT LEAST to comment CS (and computation theory is more advanced topic
> than TM). Saying so is because we know you can't do the exercise and boast lots
> about TM stuff (and pretty much anything else from just reading words), even
> about theorem.
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
All that I need to know is that I proved that
embedded_H correctly recognizes the repeating
pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
cannot possibly reach its own simulated final
halt state of ⟨Ĥ.qn⟩
https://www.liarparadox.org/Linz_Proof.pdf
>> We only have to actually know one detail:
>> Every counter-example input encoded in any model
>> of computation always specifies recursive simulation
>> that never halts to its corresponding simulating
>> termination analyzer.
>
> More example here that you don't understand nearly all CS terms.
>
Mere empty rhetoric entirely bereft of any supporting
reasoning. The x86 language is comparable to a RASP
machine that is equivalent to a Turing machine.
--
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-12 00:28 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <41e08841caf0d628beb5105bc78531a412eea440.camel@gmail.com> |
| In reply to | #118489 |
On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
> On 5/11/2025 9:34 AM, wij wrote:
> > On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
> > > On 5/10/2025 9:09 PM, wij wrote:
> > > > On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
> > > > > On 5/10/2025 8:44 PM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
> > > > > > > On 5/10/2025 8:17 PM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 17:03 -0500, 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:
> > > > > > >
> > > > > > > >
> > > > > > > > You don't know the counter example in the HP proof, your D is not the case what HP
> > > > > > > > says.
> > > > > > > >
> > > > > > >
> > > > > > > Sure I do this is it! (as correctly encoded in C)
> > > > > > >
> > > > > > > typedef void (*ptr)();
> > > > > > > int HHH(ptr P);
> > > > > > >
> > > > > > > int DD()
> > > > > > > {
> > > > > > > int Halt_Status = HHH(DD);
> > > > > > > if (Halt_Status)
> > > > > > > HERE: goto HERE;
> > > > > > > return Halt_Status;
> > > > > > > }
> > > > > > >
> > > > > > > int main()
> > > > > > > {
> > > > > > > HHH(DD);
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Try to convert it to TM language to know you know nothing.
> > > > > >
> > > > >
> > > > > I spent 22 years on this. I started with the Linz text
> > > > >
> > > > > When Ĥ is applied to ⟨Ĥ⟩
> > > > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> > > > > or
> > > > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> > > > >
> > > > > (a) Ĥ copies its input ⟨Ĥ⟩
> > > > > (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> > > > > (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
> > > > >
> > > > > Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
> > > > > cannot possibly reach its simulated final halt state
> > > > > ⟨Ĥ.qn⟩
> > > > >
> > > > > > To refute the HP, you need to understand what it exactly means in TM.
> > > > >
> > > > > I have known this for 22 years.
> > > >
> > > > A working TM. Build it explicitly from transition function, then explain
> > > > your derivation. You know nothing.
> > > >
> > >
> > > That would be like examining how an operating system
> > > works entirely from its machine code.
> >
> > You are refuting a CS foundamental theorem (i.e. HP) officially.
> > So, yes, and actually MORE need to be done (beyond your imagination).
> >
> > Knowing a car or smart phone,... is far different from making one.
> > Knowing E=mc^2 is far from knowing relativity, making A-bomb (actually, making
> > A-bomb don't need to know E=mc^2, people are often fooled by popular saying)
> >
> > Every chapter of Linz's book, C text textbook has exercises, you need to those
> > exercises AT LEAST to comment CS (and computation theory is more advanced topic
> > than TM). Saying so is because we know you can't do the exercise and boast lots
> > about TM stuff (and pretty much anything else from just reading words), even
> > about theorem.
> >
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> or
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>
> All that I need to know is that I proved that
> embedded_H correctly recognizes the repeating
> pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
> cannot possibly reach its own simulated final
> halt state of ⟨Ĥ.qn⟩
>
> https://www.liarparadox.org/Linz_Proof.pdf
>
> > > We only have to actually know one detail:
> > > Every counter-example input encoded in any model
> > > of computation always specifies recursive simulation
> > > that never halts to its corresponding simulating
> > > termination analyzer.
> >
> > More example here that you don't understand nearly all CS terms.
> >
>
> Mere empty rhetoric entirely bereft of any supporting
> reasoning. The x86 language is comparable to a RASP
> machine that is equivalent to a Turing machine.
Question:
1. Do you understand that you can't do the exercises in Linz's book?
2. Do you understand your ability of C/assembly/TM is less than 1 year CS level?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 12:00 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvql3p$gldn$15@dont-email.me> |
| In reply to | #118506 |
On 5/11/2025 11:28 AM, wij wrote:
> On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
>> On 5/11/2025 9:34 AM, wij wrote:
>>> On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
>>>> On 5/10/2025 9:09 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>>>>> On 5/10/2025 8:44 PM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 17:03 -0500, 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:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> You don't know the counter example in the HP proof, your D is not the case what HP
>>>>>>>>> says.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sure I do this is it! (as correctly encoded in C)
>>>>>>>>
>>>>>>>> typedef void (*ptr)();
>>>>>>>> int HHH(ptr P);
>>>>>>>>
>>>>>>>> int DD()
>>>>>>>> {
>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return Halt_Status;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> HHH(DD);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Try to convert it to TM language to know you know nothing.
>>>>>>>
>>>>>>
>>>>>> I spent 22 years on this. I started with the Linz text
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> or
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>>>>
>>>>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>>>>>> cannot possibly reach its simulated final halt state
>>>>>> ⟨Ĥ.qn⟩
>>>>>>
>>>>>>> To refute the HP, you need to understand what it exactly means in TM.
>>>>>>
>>>>>> I have known this for 22 years.
>>>>>
>>>>> A working TM. Build it explicitly from transition function, then explain
>>>>> your derivation. You know nothing.
>>>>>
>>>>
>>>> That would be like examining how an operating system
>>>> works entirely from its machine code.
>>>
>>> You are refuting a CS foundamental theorem (i.e. HP) officially.
>>> So, yes, and actually MORE need to be done (beyond your imagination).
>>>
>>> Knowing a car or smart phone,... is far different from making one.
>>> Knowing E=mc^2 is far from knowing relativity, making A-bomb (actually, making
>>> A-bomb don't need to know E=mc^2, people are often fooled by popular saying)
>>>
>>> Every chapter of Linz's book, C text textbook has exercises, you need to those
>>> exercises AT LEAST to comment CS (and computation theory is more advanced topic
>>> than TM). Saying so is because we know you can't do the exercise and boast lots
>>> about TM stuff (and pretty much anything else from just reading words), even
>>> about theorem.
>>>
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> or
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> (a) Ĥ copies its input ⟨Ĥ⟩
>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>
>> All that I need to know is that I proved that
>> embedded_H correctly recognizes the repeating
>> pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
>> cannot possibly reach its own simulated final
>> halt state of ⟨Ĥ.qn⟩
>>
>> https://www.liarparadox.org/Linz_Proof.pdf
>>
>>>> We only have to actually know one detail:
>>>> Every counter-example input encoded in any model
>>>> of computation always specifies recursive simulation
>>>> that never halts to its corresponding simulating
>>>> termination analyzer.
>>>
>>> More example here that you don't understand nearly all CS terms.
>>>
>>
>> Mere empty rhetoric entirely bereft of any supporting
>> reasoning. The x86 language is comparable to a RASP
>> machine that is equivalent to a Turing machine.
>
> Question:
> 1. Do you understand that you can't do the exercises in Linz's book?
Everything is 100% irrelevant besides the fact that
I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
embedded_H cannot possibly reach its own simulated
final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
on the behavior that its input specifies it can
correctly transition to Ĥ.qn.
> 2. Do you understand your ability of C/assembly/TM is less than 1 year CS level?
>
I construe C as high level assembly language thus
disregard any inessentials. No change since K & R
is of any use to me. I write C++ the same way. I
use it as C with classes. I also use std::vector a lot.
--
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-12 01:21 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <cb999b6746607a1445c196e485a2c1124eaee8b5.camel@gmail.com> |
| In reply to | #118515 |
On Sun, 2025-05-11 at 12:00 -0500, olcott wrote:
> On 5/11/2025 11:28 AM, wij wrote:
> > On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
> > > On 5/11/2025 9:34 AM, wij wrote:
> > > > On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
> > > > > On 5/10/2025 9:09 PM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
> > > > > > > On 5/10/2025 8:44 PM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 8:17 PM, wij wrote:
> > > > > > > > > > On Sat, 2025-05-10 at 17:03 -0500, 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:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > You don't know the counter example in the HP proof, your D is not the case what HP
> > > > > > > > > > says.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Sure I do this is it! (as correctly encoded in C)
> > > > > > > > >
> > > > > > > > > typedef void (*ptr)();
> > > > > > > > > int HHH(ptr P);
> > > > > > > > >
> > > > > > > > > int DD()
> > > > > > > > > {
> > > > > > > > > int Halt_Status = HHH(DD);
> > > > > > > > > if (Halt_Status)
> > > > > > > > > HERE: goto HERE;
> > > > > > > > > return Halt_Status;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > int main()
> > > > > > > > > {
> > > > > > > > > HHH(DD);
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > Try to convert it to TM language to know you know nothing.
> > > > > > > >
> > > > > > >
> > > > > > > I spent 22 years on this. I started with the Linz text
> > > > > > >
> > > > > > > When Ĥ is applied to ⟨Ĥ⟩
> > > > > > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> > > > > > > or
> > > > > > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> > > > > > >
> > > > > > > (a) Ĥ copies its input ⟨Ĥ⟩
> > > > > > > (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> > > > > > > (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
> > > > > > >
> > > > > > > Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
> > > > > > > cannot possibly reach its simulated final halt state
> > > > > > > ⟨Ĥ.qn⟩
> > > > > > >
> > > > > > > > To refute the HP, you need to understand what it exactly means in TM.
> > > > > > >
> > > > > > > I have known this for 22 years.
> > > > > >
> > > > > > A working TM. Build it explicitly from transition function, then explain
> > > > > > your derivation. You know nothing.
> > > > > >
> > > > >
> > > > > That would be like examining how an operating system
> > > > > works entirely from its machine code.
> > > >
> > > > You are refuting a CS foundamental theorem (i.e. HP) officially.
> > > > So, yes, and actually MORE need to be done (beyond your imagination).
> > > >
> > > > Knowing a car or smart phone,... is far different from making one.
> > > > Knowing E=mc^2 is far from knowing relativity, making A-bomb (actually, making
> > > > A-bomb don't need to know E=mc^2, people are often fooled by popular saying)
> > > >
> > > > Every chapter of Linz's book, C text textbook has exercises, you need to those
> > > > exercises AT LEAST to comment CS (and computation theory is more advanced topic
> > > > than TM). Saying so is because we know you can't do the exercise and boast lots
> > > > about TM stuff (and pretty much anything else from just reading words), even
> > > > about theorem.
> > > >
> > >
> > > When Ĥ is applied to ⟨Ĥ⟩
> > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> > > or
> > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> > >
> > > (a) Ĥ copies its input ⟨Ĥ⟩
> > > (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> > > (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> > >
> > > All that I need to know is that I proved that
> > > embedded_H correctly recognizes the repeating
> > > pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
> > > cannot possibly reach its own simulated final
> > > halt state of ⟨Ĥ.qn⟩
> > >
> > > https://www.liarparadox.org/Linz_Proof.pdf
> > >
> > > > > We only have to actually know one detail:
> > > > > Every counter-example input encoded in any model
> > > > > of computation always specifies recursive simulation
> > > > > that never halts to its corresponding simulating
> > > > > termination analyzer.
> > > >
> > > > More example here that you don't understand nearly all CS terms.
> > > >
> > >
> > > Mere empty rhetoric entirely bereft of any supporting
> > > reasoning. The x86 language is comparable to a RASP
> > > machine that is equivalent to a Turing machine.
> >
> > Question:
> > 1. Do you understand that you can't do the exercises in Linz's book?
>
> Everything is 100% irrelevant besides the fact that
> I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
> embedded_H cannot possibly reach its own simulated
> final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
> on the behavior that its input specifies it can
> correctly transition to Ĥ.qn.
>
> > 2. Do you understand your ability of C/assembly/TM is less than 1 year CS level?
> >
>
> I construe C as high level assembly language thus
> disregard any inessentials. No change since K & R
> is of any use to me. I write C++ the same way. I
> use it as C with classes. I also use std::vector a lot.
Q3. If people know the capability of the author of POOH is less than 1 year CS
level. How persuasive and reliable of POOH do you think it would be?
Q4: Why no one can reproduce the result of POOH for these 22? years?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 12:40 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvqnev$i5d0$3@dont-email.me> |
| In reply to | #118523 |
On 5/11/2025 12:21 PM, wij wrote:
> On Sun, 2025-05-11 at 12:00 -0500, olcott wrote:
>> On 5/11/2025 11:28 AM, wij wrote:
>>> On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
>>>> On 5/11/2025 9:34 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
>>>>>> On 5/10/2025 9:09 PM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 8:44 PM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 17:03 -0500, 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:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You don't know the counter example in the HP proof, your D is not the case what HP
>>>>>>>>>>> says.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sure I do this is it! (as correctly encoded in C)
>>>>>>>>>>
>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>
>>>>>>>>>> int DD()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> HHH(DD);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Try to convert it to TM language to know you know nothing.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I spent 22 years on this. I started with the Linz text
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> or
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>>>>>>
>>>>>>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>>>>>>>> cannot possibly reach its simulated final halt state
>>>>>>>> ⟨Ĥ.qn⟩
>>>>>>>>
>>>>>>>>> To refute the HP, you need to understand what it exactly means in TM.
>>>>>>>>
>>>>>>>> I have known this for 22 years.
>>>>>>>
>>>>>>> A working TM. Build it explicitly from transition function, then explain
>>>>>>> your derivation. You know nothing.
>>>>>>>
>>>>>>
>>>>>> That would be like examining how an operating system
>>>>>> works entirely from its machine code.
>>>>>
>>>>> You are refuting a CS foundamental theorem (i.e. HP) officially.
>>>>> So, yes, and actually MORE need to be done (beyond your imagination).
>>>>>
>>>>> Knowing a car or smart phone,... is far different from making one.
>>>>> Knowing E=mc^2 is far from knowing relativity, making A-bomb (actually, making
>>>>> A-bomb don't need to know E=mc^2, people are often fooled by popular saying)
>>>>>
>>>>> Every chapter of Linz's book, C text textbook has exercises, you need to those
>>>>> exercises AT LEAST to comment CS (and computation theory is more advanced topic
>>>>> than TM). Saying so is because we know you can't do the exercise and boast lots
>>>>> about TM stuff (and pretty much anything else from just reading words), even
>>>>> about theorem.
>>>>>
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> or
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>
>>>> All that I need to know is that I proved that
>>>> embedded_H correctly recognizes the repeating
>>>> pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> cannot possibly reach its own simulated final
>>>> halt state of ⟨Ĥ.qn⟩
>>>>
>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>
>>>>>> We only have to actually know one detail:
>>>>>> Every counter-example input encoded in any model
>>>>>> of computation always specifies recursive simulation
>>>>>> that never halts to its corresponding simulating
>>>>>> termination analyzer.
>>>>>
>>>>> More example here that you don't understand nearly all CS terms.
>>>>>
>>>>
>>>> Mere empty rhetoric entirely bereft of any supporting
>>>> reasoning. The x86 language is comparable to a RASP
>>>> machine that is equivalent to a Turing machine.
>>>
>>> Question:
>>> 1. Do you understand that you can't do the exercises in Linz's book?
>>
>> Everything is 100% irrelevant besides the fact that
>> I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
>> embedded_H cannot possibly reach its own simulated
>> final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
>> on the behavior that its input specifies it can
>> correctly transition to Ĥ.qn.
>>
>>> 2. Do you understand your ability of C/assembly/TM is less than 1 year CS level?
>>>
>>
>> I construe C as high level assembly language thus
>> disregard any inessentials. No change since K & R
>> is of any use to me. I write C++ the same way. I
>> use it as C with classes. I also use std::vector a lot.
>
> Q3. If people know the capability of the author of POOH is less than 1 year CS
> level. How persuasive and reliable of POOH do you think it would be?
>
> Q4: Why no one can reproduce the result of POOH for these 22? years?
>
>
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
All anyone need do to show that I am wrong
is provide the steps where DDD emulated by
HHH according to the rules of the x86 language
reaches its own emulated "ret" instruction.
Because no one can actually correctly show any
mistake in the above they resort to rhetoric
because that have no actual reasoning.
--
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-11 13:44 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvqnlc$h4nm$8@dont-email.me> |
| In reply to | #118531 |
On 5/11/2025 1:40 PM, olcott wrote:
> On 5/11/2025 12:21 PM, wij wrote:
>> On Sun, 2025-05-11 at 12:00 -0500, olcott wrote:
>>> On 5/11/2025 11:28 AM, wij wrote:
>>>> On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
>>>>> On 5/11/2025 9:34 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
>>>>>>> On 5/10/2025 9:09 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 8:44 PM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 17:03 -0500, 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:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You don't know the counter example in the HP proof, your D
>>>>>>>>>>>> is not the case what HP
>>>>>>>>>>>> says.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sure I do this is it! (as correctly encoded in C)
>>>>>>>>>>>
>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>
>>>>>>>>>>> int DD()
>>>>>>>>>>> {
>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> HHH(DD);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Try to convert it to TM language to know you know nothing.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I spent 22 years on this. I started with the Linz text
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> or
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>>>>>>>
>>>>>>>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>>>>>>>>> cannot possibly reach its simulated final halt state
>>>>>>>>> ⟨Ĥ.qn⟩
>>>>>>>>>
>>>>>>>>>> To refute the HP, you need to understand what it exactly means
>>>>>>>>>> in TM.
>>>>>>>>>
>>>>>>>>> I have known this for 22 years.
>>>>>>>>
>>>>>>>> A working TM. Build it explicitly from transition function, then
>>>>>>>> explain
>>>>>>>> your derivation. You know nothing.
>>>>>>>>
>>>>>>>
>>>>>>> That would be like examining how an operating system
>>>>>>> works entirely from its machine code.
>>>>>>
>>>>>> You are refuting a CS foundamental theorem (i.e. HP) officially.
>>>>>> So, yes, and actually MORE need to be done (beyond your imagination).
>>>>>>
>>>>>> Knowing a car or smart phone,... is far different from making one.
>>>>>> Knowing E=mc^2 is far from knowing relativity, making A-bomb
>>>>>> (actually, making
>>>>>> A-bomb don't need to know E=mc^2, people are often fooled by
>>>>>> popular saying)
>>>>>> Every chapter of Linz's book, C text textbook has exercises, you
>>>>>> need to those
>>>>>> exercises AT LEAST to comment CS (and computation theory is more
>>>>>> advanced topic
>>>>>> than TM). Saying so is because we know you can't do the exercise
>>>>>> and boast lots
>>>>>> about TM stuff (and pretty much anything else from just reading
>>>>>> words), even
>>>>>> about theorem.
>>>>>>
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> or
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>
>>>>> All that I need to know is that I proved that
>>>>> embedded_H correctly recognizes the repeating
>>>>> pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> cannot possibly reach its own simulated final
>>>>> halt state of ⟨Ĥ.qn⟩
>>>>>
>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>
>>>>>>> We only have to actually know one detail:
>>>>>>> Every counter-example input encoded in any model
>>>>>>> of computation always specifies recursive simulation
>>>>>>> that never halts to its corresponding simulating
>>>>>>> termination analyzer.
>>>>>>
>>>>>> More example here that you don't understand nearly all CS terms.
>>>>>>
>>>>>
>>>>> Mere empty rhetoric entirely bereft of any supporting
>>>>> reasoning. The x86 language is comparable to a RASP
>>>>> machine that is equivalent to a Turing machine.
>>>>
>>>> Question:
>>>> 1. Do you understand that you can't do the exercises in Linz's book?
>>>
>>> Everything is 100% irrelevant besides the fact that
>>> I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
>>> embedded_H cannot possibly reach its own simulated
>>> final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
>>> on the behavior that its input specifies it can
>>> correctly transition to Ĥ.qn.
>>>
>>>> 2. Do you understand your ability of C/assembly/TM is less than 1
>>>> year CS level?
>>>>
>>>
>>> I construe C as high level assembly language thus
>>> disregard any inessentials. No change since K & R
>>> is of any use to me. I write C++ the same way. I
>>> use it as C with classes. I also use std::vector a lot.
>>
>> Q3. If people know the capability of the author of POOH is less than 1
>> year CS
>> level. How persuasive and reliable of POOH do you think it would be?
>>
>> Q4: Why no one can reproduce the result of POOH for these 22? years?
>>
>>
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> All anyone need do to show that I am wrong
> is provide the steps where DDD emulated by
> HHH according to the rules of the x86 language
But it doesn't as you have admitted on the record:
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-12 02:38 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <07c4f2302645a7e58957b5e5bffed80397a6ddae.camel@gmail.com> |
| In reply to | #118531 |
On Sun, 2025-05-11 at 12:40 -0500, olcott wrote:
> On 5/11/2025 12:21 PM, wij wrote:
> > On Sun, 2025-05-11 at 12:00 -0500, olcott wrote:
> > > On 5/11/2025 11:28 AM, wij wrote:
> > > > On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
> > > > > On 5/11/2025 9:34 AM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 21:19 -0500, olcott wrote:
> > > > > > > On 5/10/2025 9:09 PM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 8:44 PM, wij wrote:
> > > > > > > > > > On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
> > > > > > > > > > > On 5/10/2025 8:17 PM, wij wrote:
> > > > > > > > > > > > On Sat, 2025-05-10 at 17:03 -0500, 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:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > You don't know the counter example in the HP proof, your D is not the case
> > > > > > > > > > > > what HP
> > > > > > > > > > > > says.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Sure I do this is it! (as correctly encoded in C)
> > > > > > > > > > >
> > > > > > > > > > > typedef void (*ptr)();
> > > > > > > > > > > int HHH(ptr P);
> > > > > > > > > > >
> > > > > > > > > > > int DD()
> > > > > > > > > > > {
> > > > > > > > > > > int Halt_Status = HHH(DD);
> > > > > > > > > > > if (Halt_Status)
> > > > > > > > > > > HERE: goto HERE;
> > > > > > > > > > > return Halt_Status;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > int main()
> > > > > > > > > > > {
> > > > > > > > > > > HHH(DD);
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Try to convert it to TM language to know you know nothing.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I spent 22 years on this. I started with the Linz text
> > > > > > > > >
> > > > > > > > > When Ĥ is applied to ⟨Ĥ⟩
> > > > > > > > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> > > > > > > > > or
> > > > > > > > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> > > > > > > > >
> > > > > > > > > (a) Ĥ copies its input ⟨Ĥ⟩
> > > > > > > > > (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> > > > > > > > > (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
> > > > > > > > >
> > > > > > > > > Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
> > > > > > > > > cannot possibly reach its simulated final halt state
> > > > > > > > > ⟨Ĥ.qn⟩
> > > > > > > > >
> > > > > > > > > > To refute the HP, you need to understand what it exactly means in TM.
> > > > > > > > >
> > > > > > > > > I have known this for 22 years.
> > > > > > > >
> > > > > > > > A working TM. Build it explicitly from transition function, then explain
> > > > > > > > your derivation. You know nothing.
> > > > > > > >
> > > > > > >
> > > > > > > That would be like examining how an operating system
> > > > > > > works entirely from its machine code.
> > > > > >
> > > > > > You are refuting a CS foundamental theorem (i.e. HP) officially.
> > > > > > So, yes, and actually MORE need to be done (beyond your imagination).
> > > > > >
> > > > > > Knowing a car or smart phone,... is far different from making one.
> > > > > > Knowing E=mc^2 is far from knowing relativity, making A-bomb (actually, making
> > > > > > A-bomb don't need to know E=mc^2, people are often fooled by popular saying)
> > > > > >
> > > > > > Every chapter of Linz's book, C text textbook has exercises, you need to those
> > > > > > exercises AT LEAST to comment CS (and computation theory is more advanced topic
> > > > > > than TM). Saying so is because we know you can't do the exercise and boast lots
> > > > > > about TM stuff (and pretty much anything else from just reading words), even
> > > > > > about theorem.
> > > > > >
> > > > >
> > > > > When Ĥ is applied to ⟨Ĥ⟩
> > > > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> > > > > or
> > > > > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> > > > >
> > > > > (a) Ĥ copies its input ⟨Ĥ⟩
> > > > > (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> > > > > (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> > > > >
> > > > > All that I need to know is that I proved that
> > > > > embedded_H correctly recognizes the repeating
> > > > > pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
> > > > > cannot possibly reach its own simulated final
> > > > > halt state of ⟨Ĥ.qn⟩
> > > > >
> > > > > https://www.liarparadox.org/Linz_Proof.pdf
> > > > >
> > > > > > > We only have to actually know one detail:
> > > > > > > Every counter-example input encoded in any model
> > > > > > > of computation always specifies recursive simulation
> > > > > > > that never halts to its corresponding simulating
> > > > > > > termination analyzer.
> > > > > >
> > > > > > More example here that you don't understand nearly all CS terms.
> > > > > >
> > > > >
> > > > > Mere empty rhetoric entirely bereft of any supporting
> > > > > reasoning. The x86 language is comparable to a RASP
> > > > > machine that is equivalent to a Turing machine.
> > > >
> > > > Question:
> > > > 1. Do you understand that you can't do the exercises in Linz's book?
> > >
> > > Everything is 100% irrelevant besides the fact that
> > > I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
> > > embedded_H cannot possibly reach its own simulated
> > > final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
> > > on the behavior that its input specifies it can
> > > correctly transition to Ĥ.qn.
> > >
> > > > 2. Do you understand your ability of C/assembly/TM is less than 1 year CS level?
> > > >
> > >
> > > I construe C as high level assembly language thus
> > > disregard any inessentials. No change since K & R
> > > is of any use to me. I write C++ the same way. I
> > > use it as C with classes. I also use std::vector a lot.
> >
> > Q3. If people know the capability of the author of POOH is less than 1 year CS
> > level. How persuasive and reliable of POOH do you think it would be?
> >
> > Q4: Why no one can reproduce the result of POOH for these 22? years?
> >
> >
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> All anyone need do to show that I am wrong
> is provide the steps where DDD emulated by
> HHH according to the rules of the x86 language
> reaches its own emulated "ret" instruction.
>
> Because no one can actually correctly show any
> mistake in the above they resort to rhetoric
> because that have no actual reasoning.
Q5: Do you remember you had claimed H(D) returns 1,0,both,... is correct and
more. The answer changes. What is your comment of this?
q6: What is the return value of H(D) now, exactly?
[toc] | [prev] | [next] | [standalone]
Page 14 of 32 — ← Prev page 1 … 12 13 [14] 15 16 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web