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 8 of 32 — ← Prev page 1 … 6 7 [8] 9 10 … 32 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 00:19 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmnl5$3c2gn$1@dont-email.me> |
| In reply to | #118271 |
On 5/10/2025 12:13 AM, wij wrote: > On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>> >> When mathematical mapping is properly understood >> it will be known that functions computed by models >> of computation must transform their input into >> outputs according to the specific steps of an >> algorithm. >> >> _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] >> >> For example HHH(DDD) only correctly map to the >> behavior that its input actually specifies by correctly >> emulating DDD according to the rules of the x86 language. >> >> This causes the first four instructions of DDD >> to be emulated followed by HHH emulating itself >> emulating the first three instructions of DDD. >> >> It is right at this recursive simulation just >> before HHH(DDD) is called again that HHH recognizes >> the repeating pattern and rejects DDD. > > Yes, but you still did not answer the question: Is POOH exactly about HP? > >>>>> H(D)=1 if D() halt. >>>>> H(D)=0 if D() not halt. Right now it is mostly about proving the above requirements are is mistaken. -- 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-10 13:27 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <f430dde2c5313bf6657c11b7a9eca183e2432291.camel@gmail.com> |
| In reply to | #118272 |
On Sat, 2025-05-10 at 00:19 -0500, olcott wrote: > On 5/10/2025 12:13 AM, wij wrote: > > On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>> > > > When mathematical mapping is properly understood > > > it will be known that functions computed by models > > > of computation must transform their input into > > > outputs according to the specific steps of an > > > algorithm. > > > > > > _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] > > > > > > For example HHH(DDD) only correctly map to the > > > behavior that its input actually specifies by correctly > > > emulating DDD according to the rules of the x86 language. > > > > > > This causes the first four instructions of DDD > > > to be emulated followed by HHH emulating itself > > > emulating the first three instructions of DDD. > > > > > > It is right at this recursive simulation just > > > before HHH(DDD) is called again that HHH recognizes > > > the repeating pattern and rejects DDD. > > > > Yes, but you still did not answer the question: Is POOH exactly about HP? > > > > >>>>> H(D)=1 if D() halt. > >>>>> H(D)=0 if D() not halt. > > Right now it is mostly about proving the > above requirements are is mistaken. > Why is the requirement invalid? H(D)=1 if D() halt. H(D)=0 if D() not halt.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 00:41 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmou2$3cac3$1@dont-email.me> |
| In reply to | #118273 |
On 5/10/2025 12:27 AM, wij wrote: > On Sat, 2025-05-10 at 00:19 -0500, olcott wrote: >> On 5/10/2025 12:13 AM, wij wrote: >>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>> >>>> When mathematical mapping is properly understood >>>> it will be known that functions computed by models >>>> of computation must transform their input into >>>> outputs according to the specific steps of an >>>> algorithm. >>>> >>>> _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] >>>> >>>> For example HHH(DDD) only correctly map to the >>>> behavior that its input actually specifies by correctly >>>> emulating DDD according to the rules of the x86 language. >>>> >>>> This causes the first four instructions of DDD >>>> to be emulated followed by HHH emulating itself >>>> emulating the first three instructions of DDD. >>>> >>>> It is right at this recursive simulation just >>>> before HHH(DDD) is called again that HHH recognizes >>>> the repeating pattern and rejects DDD. >>> >>> Yes, but you still did not answer the question: Is POOH exactly about HP? >>> >> >> >>>>> H(D)=1 if D() halt. >> >>>>> H(D)=0 if D() not halt. >> >> Right now it is mostly about proving the >> above requirements are is mistaken. >> > > Why is the requirement invalid? > > H(D)=1 if D() halt. > H(D)=0 if D() not halt. > The notion that the behavior specified by the finite string input to a simulating termination analyzer does sometimes differ from the behavior of its direct execution. It is a provably different sequence of steps. -- 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-10 14:00 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <84b09a0d53d77e2a8fddf567226d05c0d65e60c0.camel@gmail.com> |
| In reply to | #118274 |
On Sat, 2025-05-10 at 00:41 -0500, olcott wrote: > On 5/10/2025 12:27 AM, wij wrote: > > On Sat, 2025-05-10 at 00:19 -0500, olcott wrote: > > > On 5/10/2025 12:13 AM, wij wrote: > > > > On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>> > > > > > When mathematical mapping is properly understood > > > > > it will be known that functions computed by models > > > > > of computation must transform their input into > > > > > outputs according to the specific steps of an > > > > > algorithm. > > > > > > > > > > _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] > > > > > > > > > > For example HHH(DDD) only correctly map to the > > > > > behavior that its input actually specifies by correctly > > > > > emulating DDD according to the rules of the x86 language. > > > > > > > > > > This causes the first four instructions of DDD > > > > > to be emulated followed by HHH emulating itself > > > > > emulating the first three instructions of DDD. > > > > > > > > > > It is right at this recursive simulation just > > > > > before HHH(DDD) is called again that HHH recognizes > > > > > the repeating pattern and rejects DDD. > > > > > > > > Yes, but you still did not answer the question: Is POOH exactly about HP? > > > > > > > > > > >>>>> H(D)=1 if D() halt. > > > >>>>> H(D)=0 if D() not halt. > > > > > > Right now it is mostly about proving the > > > above requirements are is mistaken. > > > > > > > Why is the requirement invalid? > > > > H(D)=1 if D() halt. > > H(D)=0 if D() not halt. > > > > The notion that the behavior specified by the finite > string input to a simulating termination analyzer POOH reads(takes) its input as a function, not 'finite string'. Are you talking about POOH now? There is no POOH that takes 'finite string'. > does sometimes differ from the behavior of its direct > execution. It is a provably different sequence of steps. So, you are talking about the behavior of the 'simulating termination analyzer' i.e. POOH? (not really about the HP)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 01:06 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmqdo$3ce48$1@dont-email.me> |
| In reply to | #118275 |
On 5/10/2025 1:00 AM, wij wrote: > On Sat, 2025-05-10 at 00:41 -0500, olcott wrote: >> On 5/10/2025 12:27 AM, wij wrote: >>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote: >>>> On 5/10/2025 12:13 AM, wij wrote: >>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>> >>>>>> When mathematical mapping is properly understood >>>>>> it will be known that functions computed by models >>>>>> of computation must transform their input into >>>>>> outputs according to the specific steps of an >>>>>> algorithm. >>>>>> >>>>>> _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] >>>>>> >>>>>> For example HHH(DDD) only correctly map to the >>>>>> behavior that its input actually specifies by correctly >>>>>> emulating DDD according to the rules of the x86 language. >>>>>> >>>>>> This causes the first four instructions of DDD >>>>>> to be emulated followed by HHH emulating itself >>>>>> emulating the first three instructions of DDD. >>>>>> >>>>>> It is right at this recursive simulation just >>>>>> before HHH(DDD) is called again that HHH recognizes >>>>>> the repeating pattern and rejects DDD. >>>>> >>>>> Yes, but you still did not answer the question: Is POOH exactly about HP? >>>>> >>>> >>>> >>>>> H(D)=1 if D() halt. >>>> >>>>> H(D)=0 if D() not halt. >>>> >>>> Right now it is mostly about proving the >>>> above requirements are is mistaken. >>>> >>> >>> Why is the requirement invalid? >>> >>> H(D)=1 if D() halt. >>> H(D)=0 if D() not halt. >>> >> > >> The notion that the behavior specified by the finite >> string input to a simulating termination analyzer > > POOH reads(takes) its input as a function, not 'finite string'. > Are you talking about POOH now? There is no POOH that takes > 'finite string'. > It <is> a finite string of x86 bytes. >> does sometimes differ from the behavior of its direct >> execution. It is a provably different sequence of steps. > This is a verified fact. The pathological relationship that inputs can have with their simulating termination analyzer changes the behavior of these inputs relative to their direct execution. > So, you are talking about the behavior of the 'simulating termination analyzer' > i.e. POOH? (not really about the HP) > > > > -- 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-10 14:19 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <235107421488220fb79fa83cbe8bf44709f6445a.camel@gmail.com> |
| In reply to | #118276 |
On Sat, 2025-05-10 at 01:06 -0500, olcott wrote: > On 5/10/2025 1:00 AM, wij wrote: > > On Sat, 2025-05-10 at 00:41 -0500, olcott wrote: > > > On 5/10/2025 12:27 AM, wij wrote: > > > > On Sat, 2025-05-10 at 00:19 -0500, olcott wrote: > > > > > On 5/10/2025 12:13 AM, wij wrote: > > > > > > On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>> > > > > > > > When mathematical mapping is properly understood > > > > > > > it will be known that functions computed by models > > > > > > > of computation must transform their input into > > > > > > > outputs according to the specific steps of an > > > > > > > algorithm. > > > > > > > > > > > > > > _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] > > > > > > > > > > > > > > For example HHH(DDD) only correctly map to the > > > > > > > behavior that its input actually specifies by correctly > > > > > > > emulating DDD according to the rules of the x86 language. > > > > > > > > > > > > > > This causes the first four instructions of DDD > > > > > > > to be emulated followed by HHH emulating itself > > > > > > > emulating the first three instructions of DDD. > > > > > > > > > > > > > > It is right at this recursive simulation just > > > > > > > before HHH(DDD) is called again that HHH recognizes > > > > > > > the repeating pattern and rejects DDD. > > > > > > > > > > > > Yes, but you still did not answer the question: Is POOH exactly about HP? > > > > > > > > > > > > > > > > >>>>> H(D)=1 if D() halt. > > > > > >>>>> H(D)=0 if D() not halt. > > > > > > > > > > Right now it is mostly about proving the > > > > > above requirements are is mistaken. > > > > > > > > > > > > > Why is the requirement invalid? > > > > > > > > H(D)=1 if D() halt. > > > > H(D)=0 if D() not halt. > > > > > > > > > > > > The notion that the behavior specified by the finite > > > string input to a simulating termination analyzer > > > > POOH reads(takes) its input as a function, not 'finite string'. > > Are you talking about POOH now? There is no POOH that takes > > 'finite string'. > > > > It <is> a finite string of x86 bytes. Disagree. The D in Halt7.c (I just saw once) does not treat H as 'finite string', D calls H. H also does not treat D as 'finite string'. > > > does sometimes differ from the behavior of its direct > > > execution. It is a provably different sequence of steps. > > > > This is a verified fact. > The pathological relationship that inputs can have > with their simulating termination analyzer changes > the behavior of these inputs relative to their direct > execution. So, you redefined the halting problem should be about the behavior of D decided by POOH, not the 'direct' behavior of D? I.e, H(D)=1 iff H(D)=1? > > So, you are talking about the behavior of the 'simulating termination analyzer' > > i.e. POOH? (not really about the HP) > > > > > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 09:51 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnp62$3in62$3@dont-email.me> |
| In reply to | #118277 |
On 5/10/2025 1:19 AM, wij wrote:
> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>> On 5/10/2025 1:00 AM, wij wrote:
>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>> When mathematical mapping is properly understood
>>>>>>>> it will be known that functions computed by models
>>>>>>>> of computation must transform their input into
>>>>>>>> outputs according to the specific steps of an
>>>>>>>> algorithm.
>>>>>>>>
>>>>>>>> _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]
>>>>>>>>
>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>
>>>>>>>> This causes the first four instructions of DDD
>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>
>>>>>>>> It is right at this recursive simulation just
>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>
>>>>>>> Yes, but you still did not answer the question: Is POOH exactly about HP?
>>>>>>>
>>>>>>
>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>
>>>>>> Right now it is mostly about proving the
>>>>>> above requirements are is mistaken.
>>>>>>
>>>>>
>>>>> Why is the requirement invalid?
>>>>>
>>>>> H(D)=1 if D() halt.
>>>>> H(D)=0 if D() not halt.
>>>>>
>>>>
>>>
>>>> The notion that the behavior specified by the finite
>>>> string input to a simulating termination analyzer
>>>
>>> POOH reads(takes) its input as a function, not 'finite string'.
>>> Are you talking about POOH now? There is no POOH that takes
>>> 'finite string'.
>>>
>>
>> It <is> a finite string of x86 bytes.
>
> Disagree.
> The D in Halt7.c (I just saw once) does not treat H as 'finite string',
> D calls H. H also does not treat D as 'finite string'.
>
HHH and DDD and DD are the most recent functions.
HHH does emulate its finite strings of x86 machine code
according to the rules of the x86 language.
>>>> does sometimes differ from the behavior of its direct
>>>> execution. It is a provably different sequence of steps.
>>>
>>
>> This is a verified fact.
>> The pathological relationship that inputs can have
>> with their simulating termination analyzer changes
>> the behavior of these inputs relative to their direct
>> execution.
>
> So, you redefined the halting problem should be about the behavior of D
> decided by POOH, not the 'direct' behavior of D?
>
Not at all. HHH(DDD) reports on the behavior that DDD
actually specifies. All my critics require HHH to report
on behavior that DDD does not actually specify.
The actual behavior that DDD specifies is measured
by HHH emulating DDD according to the rules of the
x86 language. My critics insist on ignoring these
rules because it does not derive the behavior that
they expect.
I proved that these expectations are incorrect.
int sum(int x, int y) { return x + y ;}
sum must apply the rules of arithmetic to
its inputs thus sum(3,2) cannot correctly
derive the sum of 5 + 7.
HHH must apply the rules of the x86 language
to its input DDD. This results in DDD calling
HHH(DDD) in recursive emulation.
When HHH1(DDD) applies these same rules to its input
there is no recursive emulation because DDD does
not call HHH1(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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 11:01 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnpno$3j8lm$2@dont-email.me> |
| In reply to | #118327 |
On 5/10/2025 10:51 AM, olcott wrote:
> On 5/10/2025 1:19 AM, wij wrote:
>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>> On 5/10/2025 1:00 AM, wij wrote:
>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>> it will be known that functions computed by models
>>>>>>>>> of computation must transform their input into
>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>> algorithm.
>>>>>>>>>
>>>>>>>>> _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]
>>>>>>>>>
>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>
>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>
>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>
>>>>>>>> Yes, but you still did not answer the question: Is POOH exactly
>>>>>>>> about HP?
>>>>>>>>
>>>>>>>
>>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>>
>>>>>>> Right now it is mostly about proving the
>>>>>>> above requirements are is mistaken.
>>>>>>>
>>>>>>
>>>>>> Why is the requirement invalid?
>>>>>>
>>>>>> H(D)=1 if D() halt.
>>>>>> H(D)=0 if D() not halt.
>>>>>>
>>>>>
>>>>
>>>>> The notion that the behavior specified by the finite
>>>>> string input to a simulating termination analyzer
>>>>
>>>> POOH reads(takes) its input as a function, not 'finite string'.
>>>> Are you talking about POOH now? There is no POOH that takes
>>>> 'finite string'.
>>>>
>>>
>>> It <is> a finite string of x86 bytes.
>>
>> Disagree.
>> The D in Halt7.c (I just saw once) does not treat H as 'finite string',
>> D calls H. H also does not treat D as 'finite string'.
>>
>
> HHH and DDD and DD are the most recent functions.
> HHH does emulate its finite strings of x86 machine code
> according to the rules of the x86 language.
>
>>>>> does sometimes differ from the behavior of its direct
>>>>> execution. It is a provably different sequence of steps.
>>>>
>>>
>>> This is a verified fact.
>>> The pathological relationship that inputs can have
>>> with their simulating termination analyzer changes
>>> the behavior of these inputs relative to their direct
>>> execution.
>>
>> So, you redefined the halting problem should be about the behavior of D
>> decided by POOH, not the 'direct' behavior of D?
>>
>
> Not at all. HHH(DDD) reports on the behavior that DDD
> actually specifies.
Which is the behavior of the algorithm described by the input, which halts.
> All my critics require HHH to report
> on behavior that DDD does not actually specify.
>
> The actual behavior that DDD specifies is measured
> by
Executing DDD directly, as per the requirements:
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
> int sum(int x, int y) { return x + y ;}
> sum must apply the rules of arithmetic to
> its inputs thus sum(3,2) cannot correctly
> derive the sum of 5 + 7.
>
> HHH must apply the rules of the x86 language
> to its input DDD.
And those rules say that when DDD is actually run on an actual x86
processor that it will halt.
>
> When HHH1(DDD) applies these same rules to its input
> there is no recursive emulation because DDD does
> not call HHH1(DDD).
>
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 17:14 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnqgg$3j0g1$3@dont-email.me> |
| In reply to | #118327 |
Op 10.mei.2025 om 16:51 schreef olcott: > On 5/10/2025 1:19 AM, wij wrote: >> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote: >>> On 5/10/2025 1:00 AM, wij wrote: >>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote: >>>>> On 5/10/2025 12:27 AM, wij wrote: >>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote: >>>>>>> On 5/10/2025 12:13 AM, wij wrote: >>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>> >>>>>>>>> When mathematical mapping is properly understood >>>>>>>>> it will be known that functions computed by models >>>>>>>>> of computation must transform their input into >>>>>>>>> outputs according to the specific steps of an >>>>>>>>> algorithm. >>>>>>>>> >>>>>>>>> _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] >>>>>>>>> >>>>>>>>> For example HHH(DDD) only correctly map to the >>>>>>>>> behavior that its input actually specifies by correctly >>>>>>>>> emulating DDD according to the rules of the x86 language. >>>>>>>>> >>>>>>>>> This causes the first four instructions of DDD >>>>>>>>> to be emulated followed by HHH emulating itself >>>>>>>>> emulating the first three instructions of DDD. >>>>>>>>> >>>>>>>>> It is right at this recursive simulation just >>>>>>>>> before HHH(DDD) is called again that HHH recognizes >>>>>>>>> the repeating pattern and rejects DDD. >>>>>>>> >>>>>>>> Yes, but you still did not answer the question: Is POOH exactly >>>>>>>> about HP? >>>>>>>> >>>>>>> >>>>>>> >>>>> H(D)=1 if D() halt. >>>>>>> >>>>> H(D)=0 if D() not halt. >>>>>>> >>>>>>> Right now it is mostly about proving the >>>>>>> above requirements are is mistaken. >>>>>>> >>>>>> >>>>>> Why is the requirement invalid? >>>>>> >>>>>> H(D)=1 if D() halt. >>>>>> H(D)=0 if D() not halt. >>>>>> >>>>> >>>> >>>>> The notion that the behavior specified by the finite >>>>> string input to a simulating termination analyzer >>>> >>>> POOH reads(takes) its input as a function, not 'finite string'. >>>> Are you talking about POOH now? There is no POOH that takes >>>> 'finite string'. >>>> >>> >>> It <is> a finite string of x86 bytes. >> >> Disagree. >> The D in Halt7.c (I just saw once) does not treat H as 'finite string', >> D calls H. H also does not treat D as 'finite string'. >> > > HHH and DDD and DD are the most recent functions. > HHH does emulate its finite strings of x86 machine code > according to the rules of the x86 language. > But it violates the x86 semantics by halting the simulation before it reached the reachable halt of the program specified in the input. That it is reachable is proven by direct execution and world-class simulators, which do not do that violation of the x86 semantics.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-10 23:14 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <83120a5793367c0231c0ecef701f26c51d35055b.camel@gmail.com> |
| In reply to | #118327 |
On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
> On 5/10/2025 1:19 AM, wij wrote:
> > On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
> > > On 5/10/2025 1:00 AM, wij wrote:
> > > > On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
> > > > > On 5/10/2025 12:27 AM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
> > > > > > > On 5/10/2025 12:13 AM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
> > > > > > > > > When mathematical mapping is properly understood
> > > > > > > > > it will be known that functions computed by models
> > > > > > > > > of computation must transform their input into
> > > > > > > > > outputs according to the specific steps of an
> > > > > > > > > algorithm.
> > > > > > > > >
> > > > > > > > > _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]
> > > > > > > > >
> > > > > > > > > For example HHH(DDD) only correctly map to the
> > > > > > > > > behavior that its input actually specifies by correctly
> > > > > > > > > emulating DDD according to the rules of the x86 language.
> > > > > > > > >
> > > > > > > > > This causes the first four instructions of DDD
> > > > > > > > > to be emulated followed by HHH emulating itself
> > > > > > > > > emulating the first three instructions of DDD.
> > > > > > > > >
> > > > > > > > > It is right at this recursive simulation just
> > > > > > > > > before HHH(DDD) is called again that HHH recognizes
> > > > > > > > > the repeating pattern and rejects DDD.
> > > > > > > >
> > > > > > > > Yes, but you still did not answer the question: Is POOH exactly about HP?
> > > > > > > >
> > > > > > >
> > > > > > > >>>>> H(D)=1 if D() halt.
> > > > > > > >>>>> H(D)=0 if D() not halt.
> > > > > > >
> > > > > > > Right now it is mostly about proving the
> > > > > > > above requirements are is mistaken.
> > > > > > >
> > > > > >
> > > > > > Why is the requirement invalid?
> > > > > >
> > > > > > H(D)=1 if D() halt.
> > > > > > H(D)=0 if D() not halt.
> > > > > >
> > > > >
> > > >
> > > > > The notion that the behavior specified by the finite
> > > > > string input to a simulating termination analyzer
> > > >
> > > > POOH reads(takes) its input as a function, not 'finite string'.
> > > > Are you talking about POOH now? There is no POOH that takes
> > > > 'finite string'.
> > > >
> > >
> > > It <is> a finite string of x86 bytes.
> >
> > Disagree.
> > The D in Halt7.c (I just saw once) does not treat H as 'finite string',
> > D calls H. H also does not treat D as 'finite string'.
> >
>
> HHH and DDD and DD are the most recent functions.
> HHH does emulate its finite strings of x86 machine code
> according to the rules of the x86 language.
This is from a copy of Halt7.c:
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
H reads a *pointer*.
In P, P *calls* H.
Both do not process 'finite string'.
> > > > > does sometimes differ from the behavior of its direct
> > > > > execution. It is a provably different sequence of steps.
> > > >
> > >
> > > This is a verified fact.
> > > The pathological relationship that inputs can have
> > > with their simulating termination analyzer changes
> > > the behavior of these inputs relative to their direct
> > > execution.
> >
> > So, you redefined the halting problem should be about the behavior of D
> > decided by POOH, not the 'direct' behavior of D?
> >
>
> Not at all. HHH(DDD) reports on the behavior that DDD
> actually specifies. All my critics require HHH to report
> on behavior that DDD does not actually specify.
>
> The actual behavior that DDD specifies is measured
> by HHH emulating DDD according to the rules of the
> x86 language. My critics insist on ignoring these
> rules because it does not derive the behavior that
> they expect.
From this reply and others before. Can we conclude that POOH is
about the pathological relationship inputs to the halting decider H.
IOW, POOH computes the function: POOH(D)=1 iff D is pathological.
POOH is not about the 'incorrect' problem HP: POOH(D)=1 iff D() halt?
> I proved that these expectations are incorrect.
>
> int sum(int x, int y) { return x + y ;}
> sum must apply the rules of arithmetic to
> its inputs thus sum(3,2) cannot correctly
> derive the sum of 5 + 7.
>
> HHH must apply the rules of the x86 language
> to its input DDD. This results in DDD calling
> HHH(DDD) in recursive emulation.
>
> When HHH1(DDD) applies these same rules to its input
> there is no recursive emulation because DDD does
> not call HHH1(DDD).
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 10:43 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvns7a$3in62$8@dont-email.me> |
| In reply to | #118335 |
On 5/10/2025 10:14 AM, wij wrote:
> On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
>> On 5/10/2025 1:19 AM, wij wrote:
>>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>>> On 5/10/2025 1:00 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>>> it will be known that functions computed by models
>>>>>>>>>> of computation must transform their input into
>>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>>> algorithm.
>>>>>>>>>>
>>>>>>>>>> _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]
>>>>>>>>>>
>>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>>
>>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>>
>>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>>
>>>>>>>>> Yes, but you still did not answer the question: Is POOH exactly about HP?
>>>>>>>>>
>>>>>>>>
>>>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>>>
>>>>>>>> Right now it is mostly about proving the
>>>>>>>> above requirements are is mistaken.
>>>>>>>>
>>>>>>>
>>>>>>> Why is the requirement invalid?
>>>>>>>
>>>>>>> H(D)=1 if D() halt.
>>>>>>> H(D)=0 if D() not halt.
>>>>>>>
>>>>>>
>>>>>
>>>>>> The notion that the behavior specified by the finite
>>>>>> string input to a simulating termination analyzer
>>>>>
>>>>> POOH reads(takes) its input as a function, not 'finite string'.
>>>>> Are you talking about POOH now? There is no POOH that takes
>>>>> 'finite string'.
>>>>>
>>>>
>>>> It <is> a finite string of x86 bytes.
>>>
>>> Disagree.
>>> The D in Halt7.c (I just saw once) does not treat H as 'finite string',
>>> D calls H. H also does not treat D as 'finite string'.
>>>
>>
>> HHH and DDD and DD are the most recent functions.
>> HHH does emulate its finite strings of x86 machine code
>> according to the rules of the x86 language.
>
> This is from a copy of Halt7.c:
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> H reads a *pointer*.
> In P, P *calls* H.
>
> Both do not process 'finite string'.
>
What it is it a pointer to a box of chocolates?
finite strings are passed as pointers to finite
string in C.
>>>>>> does sometimes differ from the behavior of its direct
>>>>>> execution. It is a provably different sequence of steps.
>>>>>
>>>>
>>>> This is a verified fact.
>>>> The pathological relationship that inputs can have
>>>> with their simulating termination analyzer changes
>>>> the behavior of these inputs relative to their direct
>>>> execution.
>>>
>>> So, you redefined the halting problem should be about the behavior of D
>>> decided by POOH, not the 'direct' behavior of D?
>>>
>>
>> Not at all. HHH(DDD) reports on the behavior that DDD
>> actually specifies. All my critics require HHH to report
>> on behavior that DDD does not actually specify.
>>
>> The actual behavior that DDD specifies is measured
>> by HHH emulating DDD according to the rules of the
>> x86 language. My critics insist on ignoring these
>> rules because it does not derive the behavior that
>> they expect.
>
> From this reply and others before. Can we conclude that POOH is
> about the pathological relationship inputs to the halting decider H.
> IOW, POOH computes the function: POOH(D)=1 iff D is pathological.
>
> POOH is not about the 'incorrect' problem HP: POOH(D)=1 iff D() halt?
>
Once we have the extra detail about how models
of computation computing functions must compute
the mapping from their actual inputs to the
behaviors that these inputs actually specify
then we can see that I corrected a mistake in
the theory of computation.
>> I proved that these expectations are incorrect.
>>
>> int sum(int x, int y) { return x + y ;}
>> sum must apply the rules of arithmetic to
>> its inputs thus sum(3,2) cannot correctly
>> derive the sum of 5 + 7.
>>
>> HHH must apply the rules of the x86 language
>> to its input DDD. This results in DDD calling
>> HHH(DDD) in recursive emulation.
>>
>> When HHH1(DDD) applies these same rules to its input
>> there is no recursive emulation because DDD does
>> not call HHH1(DDD).
>>
>
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 00:00 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <6c1097059277dfa8e34acb2e607242a5d6e9d707.camel@gmail.com> |
| In reply to | #118342 |
On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
> On 5/10/2025 10:14 AM, wij wrote:
> > On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
> > > On 5/10/2025 1:19 AM, wij wrote:
> > > > On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
> > > > > On 5/10/2025 1:00 AM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
> > > > > > > On 5/10/2025 12:27 AM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 12:13 AM, wij wrote:
> > > > > > > > > > On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
> > > > > > > > > > > When mathematical mapping is properly understood
> > > > > > > > > > > it will be known that functions computed by models
> > > > > > > > > > > of computation must transform their input into
> > > > > > > > > > > outputs according to the specific steps of an
> > > > > > > > > > > algorithm.
> > > > > > > > > > >
> > > > > > > > > > > _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]
> > > > > > > > > > >
> > > > > > > > > > > For example HHH(DDD) only correctly map to the
> > > > > > > > > > > behavior that its input actually specifies by correctly
> > > > > > > > > > > emulating DDD according to the rules of the x86 language.
> > > > > > > > > > >
> > > > > > > > > > > This causes the first four instructions of DDD
> > > > > > > > > > > to be emulated followed by HHH emulating itself
> > > > > > > > > > > emulating the first three instructions of DDD.
> > > > > > > > > > >
> > > > > > > > > > > It is right at this recursive simulation just
> > > > > > > > > > > before HHH(DDD) is called again that HHH recognizes
> > > > > > > > > > > the repeating pattern and rejects DDD.
> > > > > > > > > >
> > > > > > > > > > Yes, but you still did not answer the question: Is POOH exactly about HP?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > >>>>> H(D)=1 if D() halt.
> > > > > > > > > >>>>> H(D)=0 if D() not halt.
> > > > > > > > >
> > > > > > > > > Right now it is mostly about proving the
> > > > > > > > > above requirements are is mistaken.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Why is the requirement invalid?
> > > > > > > >
> > > > > > > > H(D)=1 if D() halt.
> > > > > > > > H(D)=0 if D() not halt.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > > > The notion that the behavior specified by the finite
> > > > > > > string input to a simulating termination analyzer
> > > > > >
> > > > > > POOH reads(takes) its input as a function, not 'finite string'.
> > > > > > Are you talking about POOH now? There is no POOH that takes
> > > > > > 'finite string'.
> > > > > >
> > > > >
> > > > > It <is> a finite string of x86 bytes.
> > > >
> > > > Disagree.
> > > > The D in Halt7.c (I just saw once) does not treat H as 'finite string',
> > > > D calls H. H also does not treat D as 'finite string'.
> > > >
> > >
> > > HHH and DDD and DD are the most recent functions.
> > > HHH does emulate its finite strings of x86 machine code
> > > according to the rules of the x86 language.
> >
> > This is from a copy of Halt7.c:
> >
> > void P(ptr x)
> > {
> > int Halt_Status = H(x, x);
> > if (Halt_Status)
> > HERE: goto HERE;
> > return;
> > }
> >
> > int main()
> > {
> > Output("Input_Halts = ", H(P, P));
> > }
> >
> > H reads a *pointer*.
> > In P, P *calls* H.
> >
> > Both do not process 'finite string'.
> >
>
> What it is it a pointer to a box of chocolates?
> finite strings are passed as pointers to finite
> string in C.
Nope. I don't believe it is a pointer to chocolates, even if you say so.
It is about the code of D/H itself. They do not process string, the fact says
the author of the program does not intend to process 'string'.
> > > > > > > does sometimes differ from the behavior of its direct
> > > > > > > execution. It is a provably different sequence of steps.
> > > > > >
> > > > >
> > > > > This is a verified fact.
> > > > > The pathological relationship that inputs can have
> > > > > with their simulating termination analyzer changes
> > > > > the behavior of these inputs relative to their direct
> > > > > execution.
> > > >
> > > > So, you redefined the halting problem should be about the behavior of D
> > > > decided by POOH, not the 'direct' behavior of D?
> > > >
> > >
> > > Not at all. HHH(DDD) reports on the behavior that DDD
> > > actually specifies. All my critics require HHH to report
> > > on behavior that DDD does not actually specify.
> > >
> > > The actual behavior that DDD specifies is measured
> > > by HHH emulating DDD according to the rules of the
> > > x86 language. My critics insist on ignoring these
> > > rules because it does not derive the behavior that
> > > they expect.
> >
> > From this reply and others before. Can we conclude that POOH is
> > about the pathological relationship inputs to the halting decider H.
> > IOW, POOH computes the function: POOH(D)=1 iff D is pathological.
> >
> > POOH is not about the 'incorrect' problem HP: POOH(D)=1 iff D() halt?
> >
>
> Once we have the extra detail about how models
> of computation computing functions must compute
> the mapping from their actual inputs to the
> behaviors that these inputs actually specify
>
> then we can see that I corrected a mistake in
> the theory of computation.
What is the theory of computation? HP?
> > > I proved that these expectations are incorrect.
> > >
> > > int sum(int x, int y) { return x + y ;}
> > > sum must apply the rules of arithmetic to
> > > its inputs thus sum(3,2) cannot correctly
> > > derive the sum of 5 + 7.
> > >
> > > HHH must apply the rules of the x86 language
> > > to its input DDD. This results in DDD calling
> > > HHH(DDD) in recursive emulation.
> > >
> > > When HHH1(DDD) applies these same rules to its input
> > > there is no recursive emulation because DDD does
> > > not call HHH1(DDD).
> > >
> >
> >
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 11:15 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnu2o$3k258$1@dont-email.me> |
| In reply to | #118348 |
On 5/10/2025 11:00 AM, wij wrote:
> On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
>> On 5/10/2025 10:14 AM, wij wrote:
>>> On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
>>>> On 5/10/2025 1:19 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>>>>> On 5/10/2025 1:00 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>>>>> it will be known that functions computed by models
>>>>>>>>>>>> of computation must transform their input into
>>>>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>>>>> algorithm.
>>>>>>>>>>>>
>>>>>>>>>>>> _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]
>>>>>>>>>>>>
>>>>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>>>>
>>>>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>>>>
>>>>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>>>>
>>>>>>>>>>> Yes, but you still did not answer the question: Is POOH exactly about HP?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>>>>>
>>>>>>>>>> Right now it is mostly about proving the
>>>>>>>>>> above requirements are is mistaken.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why is the requirement invalid?
>>>>>>>>>
>>>>>>>>> H(D)=1 if D() halt.
>>>>>>>>> H(D)=0 if D() not halt.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> The notion that the behavior specified by the finite
>>>>>>>> string input to a simulating termination analyzer
>>>>>>>
>>>>>>> POOH reads(takes) its input as a function, not 'finite string'.
>>>>>>> Are you talking about POOH now? There is no POOH that takes
>>>>>>> 'finite string'.
>>>>>>>
>>>>>>
>>>>>> It <is> a finite string of x86 bytes.
>>>>>
>>>>> Disagree.
>>>>> The D in Halt7.c (I just saw once) does not treat H as 'finite string',
>>>>> D calls H. H also does not treat D as 'finite string'.
>>>>>
>>>>
>>>> HHH and DDD and DD are the most recent functions.
>>>> HHH does emulate its finite strings of x86 machine code
>>>> according to the rules of the x86 language.
>>>
>>> This is from a copy of Halt7.c:
>>>
>>> void P(ptr x)
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> H reads a *pointer*.
>>> In P, P *calls* H.
>>>
>>> Both do not process 'finite string'.
>>>
>>
>> What it is it a pointer to a box of chocolates?
>> finite strings are passed as pointers to finite
>> string in C.
>
> Nope. I don't believe it is a pointer to chocolates, even if you say so.
> It is about the code of D/H itself. They do not process string, the fact says
> the author of the program does not intend to process 'string'.
>
The input to HHH(DDD) is a pointer to a finite string
of machine code. HHH applies an x86 emulator to this
finite string.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 12:18 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnu83$3judg$1@dont-email.me> |
| In reply to | #118352 |
On 5/10/2025 12:15 PM, olcott wrote:
> On 5/10/2025 11:00 AM, wij wrote:
>> On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
>>> On 5/10/2025 10:14 AM, wij wrote:
>>>> On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
>>>>> On 5/10/2025 1:19 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>>>>>> On 5/10/2025 1:00 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>>>>>> it will be known that functions computed by models
>>>>>>>>>>>>> of computation must transform their input into
>>>>>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>>>>>> algorithm.
>>>>>>>>>>>>>
>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, but you still did not answer the question: Is POOH
>>>>>>>>>>>> exactly about HP?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>>>>>>
>>>>>>>>>>> Right now it is mostly about proving the
>>>>>>>>>>> above requirements are is mistaken.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Why is the requirement invalid?
>>>>>>>>>>
>>>>>>>>>> H(D)=1 if D() halt.
>>>>>>>>>> H(D)=0 if D() not halt.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>> The notion that the behavior specified by the finite
>>>>>>>>> string input to a simulating termination analyzer
>>>>>>>>
>>>>>>>> POOH reads(takes) its input as a function, not 'finite string'.
>>>>>>>> Are you talking about POOH now? There is no POOH that takes
>>>>>>>> 'finite string'.
>>>>>>>>
>>>>>>>
>>>>>>> It <is> a finite string of x86 bytes.
>>>>>>
>>>>>> Disagree.
>>>>>> The D in Halt7.c (I just saw once) does not treat H as 'finite
>>>>>> string',
>>>>>> D calls H. H also does not treat D as 'finite string'.
>>>>>>
>>>>>
>>>>> HHH and DDD and DD are the most recent functions.
>>>>> HHH does emulate its finite strings of x86 machine code
>>>>> according to the rules of the x86 language.
>>>>
>>>> This is from a copy of Halt7.c:
>>>>
>>>> void P(ptr x)
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>>
>>>> H reads a *pointer*.
>>>> In P, P *calls* H.
>>>>
>>>> Both do not process 'finite string'.
>>>>
>>>
>>> What it is it a pointer to a box of chocolates?
>>> finite strings are passed as pointers to finite
>>> string in C.
>>
>> Nope. I don't believe it is a pointer to chocolates, even if you say so.
>> It is about the code of D/H itself. They do not process string, the
>> fact says
>> the author of the program does not intend to process 'string'.
>>
>
> The input to HHH(DDD) is a pointer to a finite string
> of machine code.
Specifically, the fixed code of the function DDD, the fixed code of the
function HHH, and the fixed code of everything that HHH calls down to
the OS level.
> HHH applies an x86 emulator to this
> finite string.
And it does so incorrectly, as you have admitted on the record:
On 5/5/2025 8:24 AM, dbush wrote:
> On 5/4/2025 11:03 PM, dbush wrote:
>> On 5/4/2025 10:05 PM, olcott wrote:
>>> On 5/4/2025 7:23 PM, Richard Damon wrote:
>>>> But HHH doesn't correct emulated DD by those rules, as those rules
>>>> do not allow HHH to stop its emulation,
>>>
>>> Sure they do you freaking moron...
>>
>> Then show where in the Intel instruction manual that the execution of
>> any instruction other than a HLT is allowed to stop instead of
>> executing the next instruction.
>>
>> Failure to do so in your next reply, or within one hour of your next
>> post on this newsgroup, will be taken as you official on-the-record
>> admission that there is no such allowance and that HHH does NOT
>> correctly simulate DD.
>
> Let the record show that Peter Olcott made the following post in this
> newsgroup after the above message:
>
> On 5/4/2025 11:04 PM, olcott wrote:
> > D *WOULD NEVER STOP RUNNING UNLESS*
> > indicates that professor Sipser was agreeing
> > to hypotheticals AS *NOT CHANGING THE INPUT*
> >
> > You are taking
> > *WOULD NEVER STOP RUNNING UNLESS*
> > to mean *NEVER STOPS RUNNING* that is incorrect.
>
> And has made no attempt after over 9 hours to show where in the Intel
> instruction manual that execution is allowed to stop after any
> instruction other than HLT.
>
> Therefore, as per the above criteria:
>
> LET THE RECORD SHOW
>
> That Peter Olcott
>
> Has *officially* admitted
>
> That DD is NOT correctly simulated by HHH
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-05-11 00:21 +0800 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <f5e2f5b132c0cc465ae86538af91dd12185999e3.camel@gmail.com> |
| In reply to | #118352 |
On Sat, 2025-05-10 at 11:15 -0500, olcott wrote:
> On 5/10/2025 11:00 AM, wij wrote:
> > On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
> > > On 5/10/2025 10:14 AM, wij wrote:
> > > > On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
> > > > > On 5/10/2025 1:19 AM, wij wrote:
> > > > > > On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
> > > > > > > On 5/10/2025 1:00 AM, wij wrote:
> > > > > > > > On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
> > > > > > > > > On 5/10/2025 12:27 AM, wij wrote:
> > > > > > > > > > On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
> > > > > > > > > > > On 5/10/2025 12:13 AM, wij wrote:
> > > > > > > > > > > > On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
> > > > > > > > > > > > > When mathematical mapping is properly understood
> > > > > > > > > > > > > it will be known that functions computed by models
> > > > > > > > > > > > > of computation must transform their input into
> > > > > > > > > > > > > outputs according to the specific steps of an
> > > > > > > > > > > > > algorithm.
> > > > > > > > > > > > >
> > > > > > > > > > > > > _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]
> > > > > > > > > > > > >
> > > > > > > > > > > > > For example HHH(DDD) only correctly map to the
> > > > > > > > > > > > > behavior that its input actually specifies by correctly
> > > > > > > > > > > > > emulating DDD according to the rules of the x86 language.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This causes the first four instructions of DDD
> > > > > > > > > > > > > to be emulated followed by HHH emulating itself
> > > > > > > > > > > > > emulating the first three instructions of DDD.
> > > > > > > > > > > > >
> > > > > > > > > > > > > It is right at this recursive simulation just
> > > > > > > > > > > > > before HHH(DDD) is called again that HHH recognizes
> > > > > > > > > > > > > the repeating pattern and rejects DDD.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, but you still did not answer the question: Is POOH exactly about HP?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >>>>> H(D)=1 if D() halt.
> > > > > > > > > > > >>>>> H(D)=0 if D() not halt.
> > > > > > > > > > >
> > > > > > > > > > > Right now it is mostly about proving the
> > > > > > > > > > > above requirements are is mistaken.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Why is the requirement invalid?
> > > > > > > > > >
> > > > > > > > > > H(D)=1 if D() halt.
> > > > > > > > > > H(D)=0 if D() not halt.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > > The notion that the behavior specified by the finite
> > > > > > > > > string input to a simulating termination analyzer
> > > > > > > >
> > > > > > > > POOH reads(takes) its input as a function, not 'finite string'.
> > > > > > > > Are you talking about POOH now? There is no POOH that takes
> > > > > > > > 'finite string'.
> > > > > > > >
> > > > > > >
> > > > > > > It <is> a finite string of x86 bytes.
> > > > > >
> > > > > > Disagree.
> > > > > > The D in Halt7.c (I just saw once) does not treat H as 'finite string',
> > > > > > D calls H. H also does not treat D as 'finite string'.
> > > > > >
> > > > >
> > > > > HHH and DDD and DD are the most recent functions.
> > > > > HHH does emulate its finite strings of x86 machine code
> > > > > according to the rules of the x86 language.
> > > >
> > > > This is from a copy of Halt7.c:
> > > >
> > > > void P(ptr x)
> > > > {
> > > > int Halt_Status = H(x, x);
> > > > if (Halt_Status)
> > > > HERE: goto HERE;
> > > > return;
> > > > }
> > > >
> > > > int main()
> > > > {
> > > > Output("Input_Halts = ", H(P, P));
> > > > }
> > > >
> > > > H reads a *pointer*.
> > > > In P, P *calls* H.
> > > >
> > > > Both do not process 'finite string'.
> > > >
> > >
> > > What it is it a pointer to a box of chocolates?
> > > finite strings are passed as pointers to finite
> > > string in C.
> >
> > Nope. I don't believe it is a pointer to chocolates, even if you say so.
> > It is about the code of D/H itself. They do not process string, the fact says
> > the author of the program does not intend to process 'string'.
> >
>
> The input to HHH(DDD) is a pointer to a finite string
> of machine code. HHH applies an x86 emulator to this
> finite string.
Do you read English? Do D/H read and process 'finite string'?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-10 11:44 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnvpg$3kher$2@dont-email.me> |
| In reply to | #118357 |
On 5/10/2025 11:21 AM, wij wrote:
> On Sat, 2025-05-10 at 11:15 -0500, olcott wrote:
>> On 5/10/2025 11:00 AM, wij wrote:
>>> On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
>>>> On 5/10/2025 10:14 AM, wij wrote:
>>>>> On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
>>>>>> On 5/10/2025 1:19 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 1:00 AM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>>>>>>> it will be known that functions computed by models
>>>>>>>>>>>>>> of computation must transform their input into
>>>>>>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>>>>>>> algorithm.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, but you still did not answer the question: Is POOH exactly about HP?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>>>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>>>>>>>
>>>>>>>>>>>> Right now it is mostly about proving the
>>>>>>>>>>>> above requirements are is mistaken.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Why is the requirement invalid?
>>>>>>>>>>>
>>>>>>>>>>> H(D)=1 if D() halt.
>>>>>>>>>>> H(D)=0 if D() not halt.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The notion that the behavior specified by the finite
>>>>>>>>>> string input to a simulating termination analyzer
>>>>>>>>>
>>>>>>>>> POOH reads(takes) its input as a function, not 'finite string'.
>>>>>>>>> Are you talking about POOH now? There is no POOH that takes
>>>>>>>>> 'finite string'.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It <is> a finite string of x86 bytes.
>>>>>>>
>>>>>>> Disagree.
>>>>>>> The D in Halt7.c (I just saw once) does not treat H as 'finite string',
>>>>>>> D calls H. H also does not treat D as 'finite string'.
>>>>>>>
>>>>>>
>>>>>> HHH and DDD and DD are the most recent functions.
>>>>>> HHH does emulate its finite strings of x86 machine code
>>>>>> according to the rules of the x86 language.
>>>>>
>>>>> This is from a copy of Halt7.c:
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>> int Halt_Status = H(x, x);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> H reads a *pointer*.
>>>>> In P, P *calls* H.
>>>>>
>>>>> Both do not process 'finite string'.
>>>>>
>>>>
>>>> What it is it a pointer to a box of chocolates?
>>>> finite strings are passed as pointers to finite
>>>> string in C.
>>>
>>> Nope. I don't believe it is a pointer to chocolates, even if you say so.
>>> It is about the code of D/H itself. They do not process string, the fact says
>>> the author of the program does not intend to process 'string'.
>>>
>>
>> The input to HHH(DDD) is a pointer to a finite string
>> of machine code. HHH applies an x86 emulator to this
>> finite string.
>
> Do you read English? Do D/H read and process 'finite string'?
>
Like I have always said... DD, and DDD are finite
strings of x86 machine code and HHH emulates these
according to 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-10 12:55 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvo0ei$3judg$3@dont-email.me> |
| In reply to | #118361 |
On 5/10/2025 12:44 PM, olcott wrote:
> On 5/10/2025 11:21 AM, wij wrote:
>> On Sat, 2025-05-10 at 11:15 -0500, olcott wrote:
>>> On 5/10/2025 11:00 AM, wij wrote:
>>>> On Sat, 2025-05-10 at 10:43 -0500, olcott wrote:
>>>>> On 5/10/2025 10:14 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
>>>>>>> On 5/10/2025 1:19 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 1:00 AM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>>>>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>>>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>>>>>>>> it will be known that functions computed by models
>>>>>>>>>>>>>>> of computation must transform their input into
>>>>>>>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>>>>>>>> algorithm.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, but you still did not answer the question: Is POOH
>>>>>>>>>>>>>> exactly about HP?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>>>>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right now it is mostly about proving the
>>>>>>>>>>>>> above requirements are is mistaken.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Why is the requirement invalid?
>>>>>>>>>>>>
>>>>>>>>>>>> H(D)=1 if D() halt.
>>>>>>>>>>>> H(D)=0 if D() not halt.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> The notion that the behavior specified by the finite
>>>>>>>>>>> string input to a simulating termination analyzer
>>>>>>>>>>
>>>>>>>>>> POOH reads(takes) its input as a function, not 'finite string'.
>>>>>>>>>> Are you talking about POOH now? There is no POOH that takes
>>>>>>>>>> 'finite string'.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It <is> a finite string of x86 bytes.
>>>>>>>>
>>>>>>>> Disagree.
>>>>>>>> The D in Halt7.c (I just saw once) does not treat H as 'finite
>>>>>>>> string',
>>>>>>>> D calls H. H also does not treat D as 'finite string'.
>>>>>>>>
>>>>>>>
>>>>>>> HHH and DDD and DD are the most recent functions.
>>>>>>> HHH does emulate its finite strings of x86 machine code
>>>>>>> according to the rules of the x86 language.
>>>>>>
>>>>>> This is from a copy of Halt7.c:
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>> int Halt_Status = H(x, x);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>> }
>>>>>>
>>>>>> H reads a *pointer*.
>>>>>> In P, P *calls* H.
>>>>>>
>>>>>> Both do not process 'finite string'.
>>>>>>
>>>>>
>>>>> What it is it a pointer to a box of chocolates?
>>>>> finite strings are passed as pointers to finite
>>>>> string in C.
>>>>
>>>> Nope. I don't believe it is a pointer to chocolates, even if you say
>>>> so.
>>>> It is about the code of D/H itself. They do not process string, the
>>>> fact says
>>>> the author of the program does not intend to process 'string'.
>>>>
>>>
>>> The input to HHH(DDD) is a pointer to a finite string
>>> of machine code. HHH applies an x86 emulator to this
>>> finite string.
>>
>> Do you read English? Do D/H read and process 'finite string'?
>>
>
> Like I have always said... DD, and DDD are finite
> strings of x86 machine code and HHH emulates these
> according to the x86 language.
A lie, as you have admitted to the contrary:
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-10 17:34 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnv5v$3jj6u$1@dont-email.me> |
| In reply to | #118352 |
On 10/05/2025 17:15, olcott wrote: > On 5/10/2025 11:00 AM, wij wrote: >> On Sat, 2025-05-10 at 10:43 -0500, olcott wrote: >>> On 5/10/2025 10:14 AM, wij wrote: <snip> >>>> H reads a *pointer*. >>>> In P, P *calls* H. >>>> >>>> Both do not process 'finite string'. >>>> >>> >>> What it is it a pointer to a box of chocolates? >>> finite strings are passed as pointers to finite >>> string in C. >> >> Nope. I don't believe it is a pointer to chocolates, even if >> you say so. >> It is about the code of D/H itself. They do not process string, >> the fact says >> the author of the program does not intend to process 'string'. >> > > The input to HHH(DDD) is a pointer to a finite string > of machine code. No, it's not. It's a pointer to function. > HHH applies an x86 emulator to this > finite string. No, HHH casts P's value to uint32_t (which is legal) and then dereferences it (which is not). There is no string to apply anything to. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 18:05 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvntfd$3j0g2$1@dont-email.me> |
| In reply to | #118342 |
Op 10.mei.2025 om 17:43 schreef olcott:
> On 5/10/2025 10:14 AM, wij wrote:
>> On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
>>> On 5/10/2025 1:19 AM, wij wrote:
>>>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>>>> On 5/10/2025 1:00 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>>>> it will be known that functions computed by models
>>>>>>>>>>> of computation must transform their input into
>>>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>>>> algorithm.
>>>>>>>>>>>
>>>>>>>>>>> _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]
>>>>>>>>>>>
>>>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>>>
>>>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>>>
>>>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>>>
>>>>>>>>>> Yes, but you still did not answer the question: Is POOH
>>>>>>>>>> exactly about HP?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>>>>
>>>>>>>>> Right now it is mostly about proving the
>>>>>>>>> above requirements are is mistaken.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why is the requirement invalid?
>>>>>>>>
>>>>>>>> H(D)=1 if D() halt.
>>>>>>>> H(D)=0 if D() not halt.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>> The notion that the behavior specified by the finite
>>>>>>> string input to a simulating termination analyzer
>>>>>>
>>>>>> POOH reads(takes) its input as a function, not 'finite string'.
>>>>>> Are you talking about POOH now? There is no POOH that takes
>>>>>> 'finite string'.
>>>>>>
>>>>>
>>>>> It <is> a finite string of x86 bytes.
>>>>
>>>> Disagree.
>>>> The D in Halt7.c (I just saw once) does not treat H as 'finite string',
>>>> D calls H. H also does not treat D as 'finite string'.
>>>>
>>>
>>> HHH and DDD and DD are the most recent functions.
>>> HHH does emulate its finite strings of x86 machine code
>>> according to the rules of the x86 language.
>>
>> This is from a copy of Halt7.c:
>>
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> H reads a *pointer*.
>> In P, P *calls* H.
>>
>> Both do not process 'finite string'.
>>
>
> What it is it a pointer to a box of chocolates?
> finite strings are passed as pointers to finite
> string in C.
>
>>>>>>> does sometimes differ from the behavior of its direct
>>>>>>> execution. It is a provably different sequence of steps.
>>>>>>
>>>>>
>>>>> This is a verified fact.
>>>>> The pathological relationship that inputs can have
>>>>> with their simulating termination analyzer changes
>>>>> the behavior of these inputs relative to their direct
>>>>> execution.
>>>>
>>>> So, you redefined the halting problem should be about the behavior of D
>>>> decided by POOH, not the 'direct' behavior of D?
>>>>
>>>
>>> Not at all. HHH(DDD) reports on the behavior that DDD
>>> actually specifies. All my critics require HHH to report
>>> on behavior that DDD does not actually specify.
>>>
>>> The actual behavior that DDD specifies is measured
>>> by HHH emulating DDD according to the rules of the
>>> x86 language. My critics insist on ignoring these
>>> rules because it does not derive the behavior that
>>> they expect.
>>
>> From this reply and others before. Can we conclude that POOH is
>> about the pathological relationship inputs to the halting decider H.
>> IOW, POOH computes the function: POOH(D)=1 iff D is pathological.
>>
>> POOH is not about the 'incorrect' problem HP: POOH(D)=1 iff D() halt?
>>
>
> Once we have the extra detail about how models
> of computation computing functions must compute
> the mapping from their actual inputs to the
> behaviors that these inputs actually specify
and when we see that the input specifies a program that includes the HHH
that aborts prematurely, we see that HHH misses that specification in
the input. That does not make the behaviour in the specification any
different.
>
> then we can see that I corrected a mistake in
> the theory of computation.
>
So, the mistake is in thinking that HHH is correct. But it fails to
reach the reachable end of the program specified in its input.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-10 17:07 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvntk8$3jj6t$1@dont-email.me> |
| In reply to | #118342 |
On 10/05/2025 16:43, olcott wrote:
> On 5/10/2025 10:14 AM, wij wrote:
>> On Sat, 2025-05-10 at 09:51 -0500, olcott wrote:
>>> On 5/10/2025 1:19 AM, wij wrote:
>>>> On Sat, 2025-05-10 at 01:06 -0500, olcott wrote:
>>>>> On 5/10/2025 1:00 AM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 00:41 -0500, olcott wrote:
>>>>>>> On 5/10/2025 12:27 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 00:19 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 12:13 AM, wij wrote:
>>>>>>>>>> On Sat, 2025-05-10 at 00:06 -0500, olcott wrote:>>
>>>>>>>>>>> When mathematical mapping is properly understood
>>>>>>>>>>> it will be known that functions computed by models
>>>>>>>>>>> of computation must transform their input into
>>>>>>>>>>> outputs according to the specific steps of an
>>>>>>>>>>> algorithm.
>>>>>>>>>>>
>>>>>>>>>>> _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]
>>>>>>>>>>>
>>>>>>>>>>> For example HHH(DDD) only correctly map to the
>>>>>>>>>>> behavior that its input actually specifies by correctly
>>>>>>>>>>> emulating DDD according to the rules of the x86 language.
>>>>>>>>>>>
>>>>>>>>>>> This causes the first four instructions of DDD
>>>>>>>>>>> to be emulated followed by HHH emulating itself
>>>>>>>>>>> emulating the first three instructions of DDD.
>>>>>>>>>>>
>>>>>>>>>>> It is right at this recursive simulation just
>>>>>>>>>>> before HHH(DDD) is called again that HHH recognizes
>>>>>>>>>>> the repeating pattern and rejects DDD.
>>>>>>>>>>
>>>>>>>>>> Yes, but you still did not answer the question: Is POOH
>>>>>>>>>> exactly about HP?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> >>>>> H(D)=1 if D() halt.
>>>>>>>>> >>>>> H(D)=0 if D() not halt.
>>>>>>>>>
>>>>>>>>> Right now it is mostly about proving the
>>>>>>>>> above requirements are is mistaken.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why is the requirement invalid?
>>>>>>>>
>>>>>>>> H(D)=1 if D() halt.
>>>>>>>> H(D)=0 if D() not halt.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>> The notion that the behavior specified by the finite
>>>>>>> string input to a simulating termination analyzer
>>>>>>
>>>>>> POOH reads(takes) its input as a function, not 'finite
>>>>>> string'.
>>>>>> Are you talking about POOH now? There is no POOH that takes
>>>>>> 'finite string'.
>>>>>>
>>>>>
>>>>> It <is> a finite string of x86 bytes.
>>>>
>>>> Disagree.
>>>> The D in Halt7.c (I just saw once) does not treat H as
>>>> 'finite string',
>>>> D calls H. H also does not treat D as 'finite string'.
>>>>
>>>
>>> HHH and DDD and DD are the most recent functions.
>>> HHH does emulate its finite strings of x86 machine code
>>> according to the rules of the x86 language.
>>
>> This is from a copy of Halt7.c:
>>
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> H reads a *pointer*.
>> In P, P *calls* H.
>>
>> Both do not process 'finite string'.
>>
>
> What it is it a pointer to a box of chocolates?
No, it's a pointer to a function. On line 23 of your github
posting you typedef the type as void (*ptr)().
It is certainly finite, but it is not a string.
7.1.1(1) reads "A string is a contiguous sequence of characters
terminated by and including the first null character."
Functions are not characters.
3.7
1
character
〈abstract〉 member of a set of elements used for the organization,
control, or representation of data
3.7.1
1
character
single-byte character
〈C〉 bit representation that fits in a byte
> finite strings are passed as pointers to finite
> string in C.
In C, you pass a string to a function by passing a pointer to the
string's first character, using char *, not void(*)().
<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 8 of 32 — ← Prev page 1 … 6 7 [8] 9 10 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web