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 15 of 32 — ← Prev page 1 … 13 14 [15] 16 17 … 32 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 15:19 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr0ot$k9nu$1@dont-email.me> |
| In reply to | #118542 |
On 5/11/2025 1:38 PM, wij wrote:
> 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?
>
>
I am only referring to the behavior of DDD
emulated by HHH according to the rules of
the x86 language.
--
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 16:21 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr0ro$k1ua$1@dont-email.me> |
| In reply to | #118544 |
On 5/11/2025 4:19 PM, olcott wrote:
> On 5/11/2025 1:38 PM, wij wrote:
>> 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?
>>
>>
>
> I am only referring to the behavior of DDD
> emulated by HHH according to the rules of
> the x86 language.
>
Which it doesn't do as you've 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 04:23 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <04bd32e2a5572305de0376f9569172932ffb252f.camel@gmail.com> |
| In reply to | #118544 |
On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:
> On 5/11/2025 1:38 PM, wij wrote:
> > 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?
> >
> >
>
> I am only referring to the behavior of DDD
> emulated by HHH according to the rules of
> the x86 language.
So, you longer refute the HP now?
Therefore, no longer claims that POOH is supposed helpful to AI and human?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 15:50 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr2iu$khl4$1@dont-email.me> |
| In reply to | #118546 |
On 5/11/2025 3:23 PM, wij wrote:
> On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:
>> On 5/11/2025 1:38 PM, wij wrote:
>>> 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?
>>>
>>>
>>
>> I am only referring to the behavior of DDD
>> emulated by HHH according to the rules of
>> the x86 language.
>
> So, you longer refute the HP now?
> Therefore, no longer claims that POOH is supposed helpful to AI and human?
>
I never tried to refute the HP.
I only proved that the proof is wrong.
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 15:53 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr2ov$khl4$2@dont-email.me> |
| In reply to | #118546 |
On 5/11/2025 3:23 PM, wij wrote:
> On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:
>> On 5/11/2025 1:38 PM, wij wrote:
>>> 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?
>>>
>>>
>>
>> I am only referring to the behavior of DDD
>> emulated by HHH according to the rules of
>> the x86 language.
>
> So, you longer refute the HP now?
ZFC corrected the error in set theory so that
it could resolve Russell's Paradox. The original
set theory has now called naive set theory.
I corrected the error of the HP that expects
HHH to report on behavior that is different
than the behavior that its input actually
specifies.
Anyone having a very deep understanding of
computable functions knows inputs must be
transformed into outputs by a specific algorithm.
> Therefore, no longer claims that POOH is supposed helpful to AI and human?
>
--
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 17:01 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr386$k1ua$2@dont-email.me> |
| In reply to | #118549 |
On 5/11/2025 4:53 PM, olcott wrote:
> On 5/11/2025 3:23 PM, wij wrote:
>> On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:
>>> On 5/11/2025 1:38 PM, wij wrote:
>>>> 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?
>>>>
>>>>
>>>
>>> I am only referring to the behavior of DDD
>>> emulated by HHH according to the rules of
>>> the x86 language.
>>
>> So, you longer refute the HP now?
>
> ZFC corrected the error in set theory so that
> it could resolve Russell's Paradox. The original
> set theory has now called naive set theory.
>
> I corrected the error of the HP that expects
> HHH to report on behavior that is different
> than the behavior that its input actually
> specifies.
There is no error. As per the requirements, HHH must report on the
behavior of the algorithm described by the input when executed directly:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
If I want to know if any arbitrary algorithm X with input Y will halt
when executed directly, I don't care what behavior X specifies to H.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-12 05:48 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <72f8c8295d3a0ff265a67b0de838516ade16c6d5.camel@gmail.com> |
| In reply to | #118549 |
On Sun, 2025-05-11 at 15:53 -0500, olcott wrote:
> On 5/11/2025 3:23 PM, wij wrote:
> > On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:
> > > On 5/11/2025 1:38 PM, wij wrote:
> > > > 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?
> > > >
> > > >
> > >
> > > I am only referring to the behavior of DDD
> > > emulated by HHH according to the rules of
> > > the x86 language.
> >
> > So, you longer refute the HP now?
>
> ZFC corrected the error in set theory so that
> it could resolve Russell's Paradox. The original
> set theory has now called naive set theory.
>
> I corrected the error of the HP that expects
> HHH to report on behavior that is different
> than the behavior that its input actually
> specifies.
Specificly, "Halt(D)=1 iff D() halts" is an error?
And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)?
> Anyone having a very deep understanding of
> computable functions knows inputs must be
> transformed into outputs by a specific algorithm.
>
> > Therefore, no longer claims that POOH is supposed helpful to AI and human?
> >
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 17:00 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr6lj$lieg$1@dont-email.me> |
| In reply to | #118571 |
On 5/11/2025 4:48 PM, wij wrote:
> On Sun, 2025-05-11 at 15:53 -0500, olcott wrote:
>> On 5/11/2025 3:23 PM, wij wrote:
>>> On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:
>>>> On 5/11/2025 1:38 PM, wij wrote:
>>>>> 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?
>>>>>
>>>>>
>>>>
>>>> I am only referring to the behavior of DDD
>>>> emulated by HHH according to the rules of
>>>> the x86 language.
>>>
>>> So, you longer refute the HP now?
>>
>> ZFC corrected the error in set theory so that
>> it could resolve Russell's Paradox. The original
>> set theory has now called naive set theory.
>>
>> I corrected the error of the HP that expects
>> HHH to report on behavior that is different
>> than the behavior that its input actually
>> specifies.
>
> Specificly, "Halt(D)=1 iff D() halts" is an error?
> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)?
>
Yes that is an error because the behavior that
the input to HHH(DDD) specifies is the behavior
that HHH must report on.
--
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 17:05 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr704$ln47$1@dont-email.me> |
| In reply to | #118572 |
On 5/11/2025 5:00 PM, olcott wrote:
> On 5/11/2025 4:48 PM, wij wrote:
>> On Sun, 2025-05-11 at 15:53 -0500, olcott wrote:
>>> On 5/11/2025 3:23 PM, wij wrote:
>>>> On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:
>>>>> On 5/11/2025 1:38 PM, wij wrote:
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>
>>>>> I am only referring to the behavior of DDD
>>>>> emulated by HHH according to the rules of
>>>>> the x86 language.
>>>>
>>>> So, you longer refute the HP now?
>>>
>>> ZFC corrected the error in set theory so that
>>> it could resolve Russell's Paradox. The original
>>> set theory has now called naive set theory.
>>>
>>> I corrected the error of the HP that expects
>>> HHH to report on behavior that is different
>>> than the behavior that its input actually
>>> specifies.
>>
>> Specificly, "Halt(D)=1 iff D() halts" is an error?
>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)?
>>
>
> Yes that is an error because the behavior that
> the input to HHH(DDD) specifies is the behavior
> that HHH must report on.
>
>
HHH(DDD) == 1 iff DDD emulated by HHH according to
the rules of the x86 language reaches its "ret"
instruction final halt state else HHH(DDD) == 0.
--
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 06:11 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <8667c45172be6519444525c30d280cde06d77e2b.camel@gmail.com> |
| In reply to | #118572 |
On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: [cut] > > > ZFC corrected the error in set theory so that > > > it could resolve Russell's Paradox. The original > > > set theory has now called naive set theory. > > > > > > I corrected the error of the HP that expects > > > HHH to report on behavior that is different > > > than the behavior that its input actually > > > specifies. > > > > Specificly, "Halt(D)=1 iff D() halts" is an error? > > And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? > > > > Yes that is an error because the behavior that > the input to HHH(DDD) specifies is the behavior > that HHH must report on. If so, how do we know a given function e.g. D, halts or not by giving it to H, i.e. H(D)? Wrong question (according to you)? Instead, every time we want to know whether D halts or not, we should ask POOH(D)? Because you said 'halt' means "the input to HHH(DDD) specifies is the behavior that HHH must report on." And, how is POOH useful to AI and human if POOH cannot be reproduced?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 17:30 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvr8dj$lu2b$1@dont-email.me> |
| In reply to | #118574 |
On 5/11/2025 5:11 PM, wij wrote: > On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: > [cut] >>>> ZFC corrected the error in set theory so that >>>> it could resolve Russell's Paradox. The original >>>> set theory has now called naive set theory. >>>> >>>> I corrected the error of the HP that expects >>>> HHH to report on behavior that is different >>>> than the behavior that its input actually >>>> specifies. >>> >>> Specificly, "Halt(D)=1 iff D() halts" is an error? >>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>> >> >> Yes that is an error because the behavior that >> the input to HHH(DDD) specifies is the behavior >> that HHH must report on. > > If so, how do we know a given function e.g. D, halts or not by giving it to H, > i.e. H(D)? Wrong question (according to you)? H and D is too vague and ambiguous. We know that the input to HHH(DDD) specifies a non-halting sequence of configurations. We know that the input to HHH1(DDD) specifies a halting sequence of configurations. > Instead, every time we want to know whether D halts or not, When we intentionally define an input to attempt to thwart a specific termination analyzer THIS DOES CHANGE THE BEHAVIOR. If we let people run uploaded programs on our network we need to know if these programs are going to halt. Unless HHH(DDD) rejects its input as non-halting HHH will continue to eat up network resources. We have to have some specific termination analyzer. It must be able to handle people trying to trick it. > we should ask > POOH(D)? Because you said 'halt' means "the input to HHH(DDD) specifies is the > behavior that HHH must report on." > > And, how is POOH useful to AI and human if POOH cannot be reproduced? > > -- 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 06:50 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <7281f97665272ea0eb85e56940648f6c807b0b8e.camel@gmail.com> |
| In reply to | #118576 |
On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: > On 5/11/2025 5:11 PM, wij wrote: > > On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: > > [cut] > > > > > ZFC corrected the error in set theory so that > > > > > it could resolve Russell's Paradox. The original > > > > > set theory has now called naive set theory. > > > > > > > > > > I corrected the error of the HP that expects > > > > > HHH to report on behavior that is different > > > > > than the behavior that its input actually > > > > > specifies. > > > > > > > > Specificly, "Halt(D)=1 iff D() halts" is an error? > > > > And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? > > > > > > > > > > Yes that is an error because the behavior that > > > the input to HHH(DDD) specifies is the behavior > > > that HHH must report on. > > > > If so, how do we know a given function e.g. D, halts or not by giving it to H, > > i.e. H(D)? Wrong question (according to you)? > > H and D is too vague and ambiguous. > We know that the input to HHH(DDD) specifies > a non-halting sequence of configurations. > > We know that the input to HHH1(DDD) specifies > a halting sequence of configurations. > > > Instead, every time we want to know whether D halts or not, > > When we intentionally define an input to attempt > to thwart a specific termination analyzer THIS DOES > CHANGE THE BEHAVIOR. > > If we let people run uploaded programs on our > network we need to know if these programs are > going to halt. > > Unless HHH(DDD) rejects its input as non-halting > HHH will continue to eat up network resources. But, according to POOH, if D going to eat up network resources, it have to happen when we run POOH(D), because you said D's halting property only valid to H. So why bother we use POOH? D only cause damage of our network (test it halt or not) while we run it. How is it helpful to AI and human if so this way? > We have to have some specific termination > analyzer. It must be able to handle people > trying to trick it. > > > we should ask > > POOH(D)? Because you said 'halt' means "the input to HHH(DDD) specifies is the > > behavior that HHH must report on." > > > > And, how is POOH useful to AI and human if POOH cannot be reproduced? > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 18:08 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvralq$me5h$1@dont-email.me> |
| In reply to | #118577 |
On 5/11/2025 5:50 PM, wij wrote: > On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: >> On 5/11/2025 5:11 PM, wij wrote: >>> On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: >>> [cut] >>>>>> ZFC corrected the error in set theory so that >>>>>> it could resolve Russell's Paradox. The original >>>>>> set theory has now called naive set theory. >>>>>> >>>>>> I corrected the error of the HP that expects >>>>>> HHH to report on behavior that is different >>>>>> than the behavior that its input actually >>>>>> specifies. >>>>> >>>>> Specificly, "Halt(D)=1 iff D() halts" is an error? >>>>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>> >>>> >>>> Yes that is an error because the behavior that >>>> the input to HHH(DDD) specifies is the behavior >>>> that HHH must report on. >>> >>> If so, how do we know a given function e.g. D, halts or not by giving it to H, >>> i.e. H(D)? Wrong question (according to you)? >> >> H and D is too vague and ambiguous. >> We know that the input to HHH(DDD) specifies >> a non-halting sequence of configurations. >> >> We know that the input to HHH1(DDD) specifies >> a halting sequence of configurations. >> >>> Instead, every time we want to know whether D halts or not, >> >> When we intentionally define an input to attempt >> to thwart a specific termination analyzer THIS DOES >> CHANGE THE BEHAVIOR. >> >> If we let people run uploaded programs on our >> network we need to know if these programs are >> going to halt. >> >> Unless HHH(DDD) rejects its input as non-halting >> HHH will continue to eat up network resources. > > But, according to POOH, if D going to eat up network resources, it have to > happen when we run POOH(D), because you said D's halting property only > valid to H. > If we want to prevent this kind of denial of service attack HHH must be able correctly handle inputs that are trying to thwart it or HHH fails. When HHH is our official denial of service attack preventer it either rejects its input DDD as non halting or it gets stuck in recursive emulation thus fails. It always has been the requirement that a termination analyzer was required to report on the behavior that its input actually specifies. This is a subtle nuance of functions computed by models of computation that no one bothered to pay attention to because they didn't know it made any difference. -- 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 08:33 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <f5a9ca0c0edaeb582b14c3babee27e25d41fc953.camel@gmail.com> |
| In reply to | #118579 |
On Sun, 2025-05-11 at 18:08 -0500, olcott wrote: > On 5/11/2025 5:50 PM, wij wrote: > > On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: > > > On 5/11/2025 5:11 PM, wij wrote: > > > > On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: > > > > [cut] > > > > > > > ZFC corrected the error in set theory so that > > > > > > > it could resolve Russell's Paradox. The original > > > > > > > set theory has now called naive set theory. > > > > > > > > > > > > > > I corrected the error of the HP that expects > > > > > > > HHH to report on behavior that is different > > > > > > > than the behavior that its input actually > > > > > > > specifies. > > > > > > > > > > > > Specificly, "Halt(D)=1 iff D() halts" is an error? > > > > > > And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? > > > > > > > > > > > > > > > > Yes that is an error because the behavior that > > > > > the input to HHH(DDD) specifies is the behavior > > > > > that HHH must report on. > > > > > > > > If so, how do we know a given function e.g. D, halts or not by giving it to H, > > > > i.e. H(D)? Wrong question (according to you)? > > > > > > H and D is too vague and ambiguous. > > > We know that the input to HHH(DDD) specifies > > > a non-halting sequence of configurations. > > > > > > We know that the input to HHH1(DDD) specifies > > > a halting sequence of configurations. > > > > > > > Instead, every time we want to know whether D halts or not, > > > > > > When we intentionally define an input to attempt > > > to thwart a specific termination analyzer THIS DOES > > > CHANGE THE BEHAVIOR. > > > > > > If we let people run uploaded programs on our > > > network we need to know if these programs are > > > going to halt. > > > > > > Unless HHH(DDD) rejects its input as non-halting > > > HHH will continue to eat up network resources. > > > > But, according to POOH, if D going to eat up network resources, it have to > > happen when we run POOH(D), because you said D's halting property only > > valid to H. > > > > If we want to prevent this kind of denial of service > attack HHH must be able correctly handle inputs that > are trying to thwart it or HHH fails. > > When HHH is our official denial of service attack > preventer it either rejects its input DDD as non > halting or it gets stuck in recursive emulation > thus fails. > > It always has been the requirement that a termination > analyzer was required to report on the behavior that > its input actually specifies. > > This is a subtle nuance of functions computed by > models of computation that no one bothered to > pay attention to because they didn't know it made > any difference. > Is DDD a virus?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 19:51 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvrgmf$n9a9$4@dont-email.me> |
| In reply to | #118592 |
On 5/11/2025 7:33 PM, wij wrote: > On Sun, 2025-05-11 at 18:08 -0500, olcott wrote: >> On 5/11/2025 5:50 PM, wij wrote: >>> On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: >>>> On 5/11/2025 5:11 PM, wij wrote: >>>>> On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: >>>>> [cut] >>>>>>>> ZFC corrected the error in set theory so that >>>>>>>> it could resolve Russell's Paradox. The original >>>>>>>> set theory has now called naive set theory. >>>>>>>> >>>>>>>> I corrected the error of the HP that expects >>>>>>>> HHH to report on behavior that is different >>>>>>>> than the behavior that its input actually >>>>>>>> specifies. >>>>>>> >>>>>>> Specificly, "Halt(D)=1 iff D() halts" is an error? >>>>>>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>>>> >>>>>> >>>>>> Yes that is an error because the behavior that >>>>>> the input to HHH(DDD) specifies is the behavior >>>>>> that HHH must report on. >>>>> >>>>> If so, how do we know a given function e.g. D, halts or not by giving it to H, >>>>> i.e. H(D)? Wrong question (according to you)? >>>> >>>> H and D is too vague and ambiguous. >>>> We know that the input to HHH(DDD) specifies >>>> a non-halting sequence of configurations. >>>> >>>> We know that the input to HHH1(DDD) specifies >>>> a halting sequence of configurations. >>>> >>>>> Instead, every time we want to know whether D halts or not, >>>> >>>> When we intentionally define an input to attempt >>>> to thwart a specific termination analyzer THIS DOES >>>> CHANGE THE BEHAVIOR. >>>> >>>> If we let people run uploaded programs on our >>>> network we need to know if these programs are >>>> going to halt. >>>> >>>> Unless HHH(DDD) rejects its input as non-halting >>>> HHH will continue to eat up network resources. >>> >>> But, according to POOH, if D going to eat up network resources, it have to >>> happen when we run POOH(D), because you said D's halting property only >>> valid to H. >>> >> >> If we want to prevent this kind of denial of service >> attack HHH must be able correctly handle inputs that >> are trying to thwart it or HHH fails. >> >> When HHH is our official denial of service attack >> preventer it either rejects its input DDD as non >> halting or it gets stuck in recursive emulation >> thus fails. >> >> It always has been the requirement that a termination >> analyzer was required to report on the behavior that >> its input actually specifies. >> >> This is a subtle nuance of functions computed by >> models of computation that no one bothered to >> pay attention to because they didn't know it made >> any difference. >> > > Is DDD a virus? > If on a real system an input tried to fool the denial-of-service-attack detector IT WOULD FAIL. Prior to my work a denial-of-service-attack detector WOULD FAIL. It would not know to reject DDD. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-11 21:15 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <d3eedafd84b780cdb0bd63c8afd0aa92209136ab@i2pn2.org> |
| In reply to | #118597 |
On 5/11/25 8:51 PM, olcott wrote: > On 5/11/2025 7:33 PM, wij wrote: >> On Sun, 2025-05-11 at 18:08 -0500, olcott wrote: >>> On 5/11/2025 5:50 PM, wij wrote: >>>> On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: >>>>> On 5/11/2025 5:11 PM, wij wrote: >>>>>> On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: >>>>>> [cut] >>>>>>>>> ZFC corrected the error in set theory so that >>>>>>>>> it could resolve Russell's Paradox. The original >>>>>>>>> set theory has now called naive set theory. >>>>>>>>> >>>>>>>>> I corrected the error of the HP that expects >>>>>>>>> HHH to report on behavior that is different >>>>>>>>> than the behavior that its input actually >>>>>>>>> specifies. >>>>>>>> >>>>>>>> Specificly, "Halt(D)=1 iff D() halts" is an error? >>>>>>>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>>>>> >>>>>>> >>>>>>> Yes that is an error because the behavior that >>>>>>> the input to HHH(DDD) specifies is the behavior >>>>>>> that HHH must report on. >>>>>> >>>>>> If so, how do we know a given function e.g. D, halts or not by >>>>>> giving it to H, >>>>>> i.e. H(D)? Wrong question (according to you)? >>>>> >>>>> H and D is too vague and ambiguous. >>>>> We know that the input to HHH(DDD) specifies >>>>> a non-halting sequence of configurations. >>>>> >>>>> We know that the input to HHH1(DDD) specifies >>>>> a halting sequence of configurations. >>>>> >>>>>> Instead, every time we want to know whether D halts or not, >>>>> >>>>> When we intentionally define an input to attempt >>>>> to thwart a specific termination analyzer THIS DOES >>>>> CHANGE THE BEHAVIOR. >>>>> >>>>> If we let people run uploaded programs on our >>>>> network we need to know if these programs are >>>>> going to halt. >>>>> >>>>> Unless HHH(DDD) rejects its input as non-halting >>>>> HHH will continue to eat up network resources. >>>> >>>> But, according to POOH, if D going to eat up network resources, it >>>> have to >>>> happen when we run POOH(D), because you said D's halting property only >>>> valid to H. >>>> >>> >>> If we want to prevent this kind of denial of service >>> attack HHH must be able correctly handle inputs that >>> are trying to thwart it or HHH fails. >>> >>> When HHH is our official denial of service attack >>> preventer it either rejects its input DDD as non >>> halting or it gets stuck in recursive emulation >>> thus fails. >>> >>> It always has been the requirement that a termination >>> analyzer was required to report on the behavior that >>> its input actually specifies. >>> >>> This is a subtle nuance of functions computed by >>> models of computation that no one bothered to >>> pay attention to because they didn't know it made >>> any difference. >>> >> >> Is DDD a virus? >> > > If on a real system an input tried to fool the > denial-of-service-attack detector IT WOULD FAIL. > > Prior to my work a denial-of-service-attack detector > WOULD FAIL. It would not know to reject DDD. > But DDD doesn't do a denial of service, so it is a false positive. Or, are you admitting that your HHH is a non-halting program, which means it isn't a decider.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 20:51 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvrk67$o2ab$2@dont-email.me> |
| In reply to | #118607 |
On 5/11/2025 8:15 PM, Richard Damon wrote: > On 5/11/25 8:51 PM, olcott wrote: >> On 5/11/2025 7:33 PM, wij wrote: >>> On Sun, 2025-05-11 at 18:08 -0500, olcott wrote: >>>> On 5/11/2025 5:50 PM, wij wrote: >>>>> On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: >>>>>> On 5/11/2025 5:11 PM, wij wrote: >>>>>>> On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: >>>>>>> [cut] >>>>>>>>>> ZFC corrected the error in set theory so that >>>>>>>>>> it could resolve Russell's Paradox. The original >>>>>>>>>> set theory has now called naive set theory. >>>>>>>>>> >>>>>>>>>> I corrected the error of the HP that expects >>>>>>>>>> HHH to report on behavior that is different >>>>>>>>>> than the behavior that its input actually >>>>>>>>>> specifies. >>>>>>>>> >>>>>>>>> Specificly, "Halt(D)=1 iff D() halts" is an error? >>>>>>>>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>>>>>> >>>>>>>> >>>>>>>> Yes that is an error because the behavior that >>>>>>>> the input to HHH(DDD) specifies is the behavior >>>>>>>> that HHH must report on. >>>>>>> >>>>>>> If so, how do we know a given function e.g. D, halts or not by >>>>>>> giving it to H, >>>>>>> i.e. H(D)? Wrong question (according to you)? >>>>>> >>>>>> H and D is too vague and ambiguous. >>>>>> We know that the input to HHH(DDD) specifies >>>>>> a non-halting sequence of configurations. >>>>>> >>>>>> We know that the input to HHH1(DDD) specifies >>>>>> a halting sequence of configurations. >>>>>> >>>>>>> Instead, every time we want to know whether D halts or not, >>>>>> >>>>>> When we intentionally define an input to attempt >>>>>> to thwart a specific termination analyzer THIS DOES >>>>>> CHANGE THE BEHAVIOR. >>>>>> >>>>>> If we let people run uploaded programs on our >>>>>> network we need to know if these programs are >>>>>> going to halt. >>>>>> >>>>>> Unless HHH(DDD) rejects its input as non-halting >>>>>> HHH will continue to eat up network resources. >>>>> >>>>> But, according to POOH, if D going to eat up network resources, it >>>>> have to >>>>> happen when we run POOH(D), because you said D's halting property only >>>>> valid to H. >>>>> >>>> >>>> If we want to prevent this kind of denial of service >>>> attack HHH must be able correctly handle inputs that >>>> are trying to thwart it or HHH fails. >>>> >>>> When HHH is our official denial of service attack >>>> preventer it either rejects its input DDD as non >>>> halting or it gets stuck in recursive emulation >>>> thus fails. >>>> >>>> It always has been the requirement that a termination >>>> analyzer was required to report on the behavior that >>>> its input actually specifies. >>>> >>>> This is a subtle nuance of functions computed by >>>> models of computation that no one bothered to >>>> pay attention to because they didn't know it made >>>> any difference. >>>> >>> >>> Is DDD a virus? >>> >> >> If on a real system an input tried to fool the >> denial-of-service-attack detector IT WOULD FAIL. >> >> Prior to my work a denial-of-service-attack detector >> WOULD FAIL. It would not know to reject DDD. >> > > But DDD doesn't do a denial of service, so it is a false positive. > When HHH is a denial-of-service-detector and DDD is trying to fool HHH into getting stuck in recursive emulation thus causing denial-of-service HHH is not fooled. -- 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 21:56 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvrkfp$mv2a$6@dont-email.me> |
| In reply to | #118614 |
On 5/11/2025 9:51 PM, olcott wrote: > On 5/11/2025 8:15 PM, Richard Damon wrote: >> On 5/11/25 8:51 PM, olcott wrote: >>> On 5/11/2025 7:33 PM, wij wrote: >>>> On Sun, 2025-05-11 at 18:08 -0500, olcott wrote: >>>>> On 5/11/2025 5:50 PM, wij wrote: >>>>>> On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: >>>>>>> On 5/11/2025 5:11 PM, wij wrote: >>>>>>>> On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: >>>>>>>> [cut] >>>>>>>>>>> ZFC corrected the error in set theory so that >>>>>>>>>>> it could resolve Russell's Paradox. The original >>>>>>>>>>> set theory has now called naive set theory. >>>>>>>>>>> >>>>>>>>>>> I corrected the error of the HP that expects >>>>>>>>>>> HHH to report on behavior that is different >>>>>>>>>>> than the behavior that its input actually >>>>>>>>>>> specifies. >>>>>>>>>> >>>>>>>>>> Specificly, "Halt(D)=1 iff D() halts" is an error? >>>>>>>>>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes that is an error because the behavior that >>>>>>>>> the input to HHH(DDD) specifies is the behavior >>>>>>>>> that HHH must report on. >>>>>>>> >>>>>>>> If so, how do we know a given function e.g. D, halts or not by >>>>>>>> giving it to H, >>>>>>>> i.e. H(D)? Wrong question (according to you)? >>>>>>> >>>>>>> H and D is too vague and ambiguous. >>>>>>> We know that the input to HHH(DDD) specifies >>>>>>> a non-halting sequence of configurations. >>>>>>> >>>>>>> We know that the input to HHH1(DDD) specifies >>>>>>> a halting sequence of configurations. >>>>>>> >>>>>>>> Instead, every time we want to know whether D halts or not, >>>>>>> >>>>>>> When we intentionally define an input to attempt >>>>>>> to thwart a specific termination analyzer THIS DOES >>>>>>> CHANGE THE BEHAVIOR. >>>>>>> >>>>>>> If we let people run uploaded programs on our >>>>>>> network we need to know if these programs are >>>>>>> going to halt. >>>>>>> >>>>>>> Unless HHH(DDD) rejects its input as non-halting >>>>>>> HHH will continue to eat up network resources. >>>>>> >>>>>> But, according to POOH, if D going to eat up network resources, it >>>>>> have to >>>>>> happen when we run POOH(D), because you said D's halting property >>>>>> only >>>>>> valid to H. >>>>>> >>>>> >>>>> If we want to prevent this kind of denial of service >>>>> attack HHH must be able correctly handle inputs that >>>>> are trying to thwart it or HHH fails. >>>>> >>>>> When HHH is our official denial of service attack >>>>> preventer it either rejects its input DDD as non >>>>> halting or it gets stuck in recursive emulation >>>>> thus fails. >>>>> >>>>> It always has been the requirement that a termination >>>>> analyzer was required to report on the behavior that >>>>> its input actually specifies. >>>>> >>>>> This is a subtle nuance of functions computed by >>>>> models of computation that no one bothered to >>>>> pay attention to because they didn't know it made >>>>> any difference. >>>>> >>>> >>>> Is DDD a virus? >>>> >>> >>> If on a real system an input tried to fool the >>> denial-of-service-attack detector IT WOULD FAIL. >>> >>> Prior to my work a denial-of-service-attack detector >>> WOULD FAIL. It would not know to reject DDD. >>> >> >> But DDD doesn't do a denial of service, so it is a false positive. >> > > When HHH is a denial-of-service-detector Then it is not a halt decider / termination analyzer, and therefore irrelevant to the halting problem.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-12 22:30 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <00f3a128e8ac35841ece8b6b4a01d75449bede14@i2pn2.org> |
| In reply to | #118614 |
On 5/11/25 9:51 PM, olcott wrote: > On 5/11/2025 8:15 PM, Richard Damon wrote: >> On 5/11/25 8:51 PM, olcott wrote: >>> On 5/11/2025 7:33 PM, wij wrote: >>>> On Sun, 2025-05-11 at 18:08 -0500, olcott wrote: >>>>> On 5/11/2025 5:50 PM, wij wrote: >>>>>> On Sun, 2025-05-11 at 17:30 -0500, olcott wrote: >>>>>>> On 5/11/2025 5:11 PM, wij wrote: >>>>>>>> On Sun, 2025-05-11 at 17:00 -0500, olcott wrote: >>>>>>>> [cut] >>>>>>>>>>> ZFC corrected the error in set theory so that >>>>>>>>>>> it could resolve Russell's Paradox. The original >>>>>>>>>>> set theory has now called naive set theory. >>>>>>>>>>> >>>>>>>>>>> I corrected the error of the HP that expects >>>>>>>>>>> HHH to report on behavior that is different >>>>>>>>>>> than the behavior that its input actually >>>>>>>>>>> specifies. >>>>>>>>>> >>>>>>>>>> Specificly, "Halt(D)=1 iff D() halts" is an error? >>>>>>>>>> And it should expect: Halt(D)=1 iff POOH(D)=1 (correct problem)? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes that is an error because the behavior that >>>>>>>>> the input to HHH(DDD) specifies is the behavior >>>>>>>>> that HHH must report on. >>>>>>>> >>>>>>>> If so, how do we know a given function e.g. D, halts or not by >>>>>>>> giving it to H, >>>>>>>> i.e. H(D)? Wrong question (according to you)? >>>>>>> >>>>>>> H and D is too vague and ambiguous. >>>>>>> We know that the input to HHH(DDD) specifies >>>>>>> a non-halting sequence of configurations. >>>>>>> >>>>>>> We know that the input to HHH1(DDD) specifies >>>>>>> a halting sequence of configurations. >>>>>>> >>>>>>>> Instead, every time we want to know whether D halts or not, >>>>>>> >>>>>>> When we intentionally define an input to attempt >>>>>>> to thwart a specific termination analyzer THIS DOES >>>>>>> CHANGE THE BEHAVIOR. >>>>>>> >>>>>>> If we let people run uploaded programs on our >>>>>>> network we need to know if these programs are >>>>>>> going to halt. >>>>>>> >>>>>>> Unless HHH(DDD) rejects its input as non-halting >>>>>>> HHH will continue to eat up network resources. >>>>>> >>>>>> But, according to POOH, if D going to eat up network resources, it >>>>>> have to >>>>>> happen when we run POOH(D), because you said D's halting property >>>>>> only >>>>>> valid to H. >>>>>> >>>>> >>>>> If we want to prevent this kind of denial of service >>>>> attack HHH must be able correctly handle inputs that >>>>> are trying to thwart it or HHH fails. >>>>> >>>>> When HHH is our official denial of service attack >>>>> preventer it either rejects its input DDD as non >>>>> halting or it gets stuck in recursive emulation >>>>> thus fails. >>>>> >>>>> It always has been the requirement that a termination >>>>> analyzer was required to report on the behavior that >>>>> its input actually specifies. >>>>> >>>>> This is a subtle nuance of functions computed by >>>>> models of computation that no one bothered to >>>>> pay attention to because they didn't know it made >>>>> any difference. >>>>> >>>> >>>> Is DDD a virus? >>>> >>> >>> If on a real system an input tried to fool the >>> denial-of-service-attack detector IT WOULD FAIL. >>> >>> Prior to my work a denial-of-service-attack detector >>> WOULD FAIL. It would not know to reject DDD. >>> >> >> But DDD doesn't do a denial of service, so it is a false positive. >> > > When HHH is a denial-of-service-detector and DDD > is trying to fool HHH into getting stuck in recursive > emulation thus causing denial-of-service HHH is not fooled. > But we aren't doing a DOS detector, that has a different criteria, as generally is allowed to have false positives (and even false negatives). You are just showing that it has always been a strawman, and you were never actually working on the problem you claimed, by have been lying for all these years out of your ignorance of what you have been trying to talk about.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-05-16 15:38 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <15a2c03c9dd9005ee5dc80c5284bff16d167c6ab@i2pn2.org> |
| In reply to | #118597 |
Am Sun, 11 May 2025 19:51:27 -0500 schrieb olcott: > If on a real system an input tried to fool the denial-of-service-attack > detector IT WOULD FAIL. > Prior to my work a denial-of-service-attack detector WOULD FAIL. It > would not know to reject DDD. No, the goal is not to make HHH run forever. It would not fail at terminating contrary to HHH's result. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
Page 15 of 32 — ← Prev page 1 … 13 14 [15] 16 17 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web