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 9 of 32 — ← Prev page 1 … 7 8 [9] 10 11 … 32 Next page →
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 10:30 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn2rf$3dv8d$7@dont-email.me> |
| In reply to | #118274 |
Op 10.mei.2025 om 07:41 schreef olcott: > 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. > Only when the simulation ignores the most relevant part of the input and halts before it can see it. Even then the only difference is that all steps that are simulated are exactly the same as the direct execution and there is no reason to think that the behaviour specified in the input would be different in the following steps. It seems difficult for you to accept verifiable facts when they disturb your dreams.
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 08:39 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnhdi$3hcaa$3@dont-email.me> |
| In reply to | #118274 |
On 5/10/2025 1:41 AM, 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 So you're staring by assuming an algorithm exists that can perform the following mapping: 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 > does sometimes differ from the behavior of its direct > execution. It is a provably different sequence of steps. > And you reach a contradiction. This proves no algorithm exists to compute the above mapping, as Linz and others have proved and as you have *explicitly* agreed is correct.
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 08:37 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnhao$3hcaa$2@dont-email.me> |
| In reply to | #118272 |
On 5/10/2025 1:19 AM, 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. > > But I want to know if any arbitrary algorithm X with input Y will halt when executed directly. It would be *very* useful to me if I had an algorithm H that could tell me that in *all* possible cases. If so, I could solve the Goldbach conjecture, among many other unsolved problems. What I'm asking for has a correct answer in all cases, and is therefore not "incorrect" or mistaken. Does an algorithm H exist that can tell me that or not?
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-10 08:36 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnh7u$3hcaa$1@dont-email.me> |
| In reply to | #118270 |
On 5/10/2025 1:06 AM, olcott wrote:
> On 5/9/2025 11:51 PM, wij wrote:
>> On Fri, 2025-05-09 at 23:44 -0500, olcott wrote:
>>> On 5/9/2025 11:32 PM, wij wrote:
>>>> On Fri, 2025-05-09 at 23:18 -0500, olcott wrote:
>>>>> On 5/9/2025 10:43 PM, wij wrote:
>>>>>> On Fri, 2025-05-09 at 22:24 -0500, olcott wrote:
>>>>>>> On 5/9/2025 10:13 PM, wij wrote:
>>>>>>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>>>>>>> "return" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> DDD can't be correctly simulated by itself (which is
>>>>>>>>>>>>> effectively
>>>>>>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>>>>>>> inside DDD).
>>>>>>>>>>>>
>>>>>>>>>>>> How the Hell did you twist my words to say that?
>>>>>>>>>>> I haven't touched your words. What I have done is to observe
>>>>>>>>>>> that
>>>>>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't
>>>>>>>>>>> itself a
>>>>>>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>>>>>>> simulator.
>>>>>>>>>>> It's recursion without a base case - a rookie error.
>>>>>>>>>>> HHH cannot successfully complete its task, because it never
>>>>>>>>>>> regains
>>>>>>>>>>> control after the first recursion. To return, it must abort the
>>>>>>>>>>> simulation, which means the simulation fails.
>>>>>>>>>>>
>>>>>>>>>>>> void DDD()
>>>>>>>>>>>> {
>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>>>>>>> simulated by HHH then this correctly simulated
>>>>>>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>>>>>>
>>>>>>>>>> Any competent C programmer can see that
>>>>>>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>>>>>>> is equivalent to infinite recursion.
>>>>>>>>>>
>>>>>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and
>>>>>>>>>>> assuming it
>>>>>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>>>>>
>>>>>>>>>>> void DDD(void) {
>>>>>>>>>>> DDD();
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Then the return statement (which is unnecessary anyway) will
>>>>>>>>>>> never be
>>>>>>>>>>> reached. In practice, the program will likely crash due to a
>>>>>>>>>>> stack
>>>>>>>>>>> overflow, unless the compiler implements tail-call
>>>>>>>>>>> optimization, in
>>>>>>>>>>> which case the program might just run forever -- which also
>>>>>>>>>>> means the
>>>>>>>>>>> unnecessary return statement will never be reached.
>>>>>>>>>
>>>>>>>>> I had not intended to post again, but I feel the need to make
>>>>>>>>> a clarification.
>>>>>>>>>
>>>>>>>>> I acknowledged that the return statement would never be reached
>>>>>>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>>>>>>> that assumption, a call to DDD() should be equivalent to a call
>>>>>>>>> to HHH(DDD).
>>>>>>>>>
>>>>>>>>> I did not address whether the assumption is valid. I merely
>>>>>>>>> temporarily accepted it for the sake of discussion, just as I
>>>>>>>>> would
>>>>>>>>> accept that if I were ten feet tall I would bump my head against
>>>>>>>>> the ceiling in my house.
>>>>>>>>>
>>>>>>>>> The discussion I had with olcott did not reach the point of
>>>>>>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>>>>>>> would even be logically possible for it to do so. I also did not
>>>>>>>>> address any issues of partial simulation, where olcott claims that
>>>>>>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>>>>>>> than simulating its entire execution. I did not participate in
>>>>>>>>> any discussion that would require knowledge of x86 machine or
>>>>>>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>>>>>>> and assembly code reasonably well if motivated to do so, but I am
>>>>>>>>> not so motivated.)
>>>>>>>>>
>>>>>>>>> What I acknowledged was barely more than "if HHH correctly
>>>>>>>>> simulates
>>>>>>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>>>>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>>>>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>>>>>>> prefer that olcott refrain from using my words to support any of
>>>>>>>>> his arguments beyond the scope of what he and I directly
>>>>>>>>> discussed.
>>>>>>>>
>>>>>>>> Don't know why you people stick on the 'simulation' stuff so long.
>>>>>>>> The HP simply asks for such an H (in function form. POOH does not
>>>>>>>> resemble TM):
>>>>>>>> H(D)=1 if D() halt.
>>>>>>>> H(D)=0 if D() not halt.
>>>>>>>
>>>>>>> My invention of a simulating termination
>>>>>>> analyzer shows exactly how to compute the
>>>>>>> mapping that the input that HHH(DD) specifies
>>>>>>> into a correct answer for the halting problem's
>>>>>>> otherwise impossible input.
>>>>>>>
>>>>>>> All rebuttals are based on failing to compute
>>>>>>> this mapping correctly.
>>>>>>>
>>>>>>
>>>>>> What is the correct mapping?
>>>>>>
>>>>>
>>>>> _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]
>>>>>
>>>>> Computing the mapping of DDD emulated by HHH
>>>>> according the the rules of the x86 language
>>>>> to its behavior by HHH actually emulating DDD.
>>>>
>>>> The above says you have no idea what the mapping is.
>>>>
>>>>>> If POOH are not talking about the mapping:
>>>>>>
>>>>>> H(D)=1 if D() halt.
>>>>>> H(D)=0 if D() not halt.
>>>>>>
>>>>>
>>>>> The way that simulating termination analyzers process
>>>>> their input by showing all of the steps of how the mapping
>>>>> must be computed refutes the above simplistic view.
>>>>
>>>> No (real) problem with that. But the HP asks:
>>>>
>>>> H(D)=1 if D() halt.
>>>> H(D)=0 if D() not halt.
>>>>
>>>> You still evade the question: Is POO H anything to do with the HP?
>>>>
>>>
>>> I have recently proven that the above requirements are incorrect.
>> it that correct?
>>
>> Be it (HP) correct or not. Your 'revision' says POOH is not about the HP,
>> it that correct?
>>
>
> 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.
And the mapping that is the halting function:
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
Cannot be computed by any algorithm, as Linz and others have proved and
as you have *explicitly* agreed is correct.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 15:16 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <f5447edc16f549d190cfce17377ebdf2478eaf64@i2pn2.org> |
| In reply to | #118270 |
On 5/10/25 1:06 AM, olcott wrote:
> On 5/9/2025 11:51 PM, wij wrote:
>> On Fri, 2025-05-09 at 23:44 -0500, olcott wrote:
>>> On 5/9/2025 11:32 PM, wij wrote:
>>>> On Fri, 2025-05-09 at 23:18 -0500, olcott wrote:
>>>>> On 5/9/2025 10:43 PM, wij wrote:
>>>>>> On Fri, 2025-05-09 at 22:24 -0500, olcott wrote:
>>>>>>> On 5/9/2025 10:13 PM, wij wrote:
>>>>>>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>>>>>>> "return" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> DDD can't be correctly simulated by itself (which is
>>>>>>>>>>>>> effectively
>>>>>>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>>>>>>> inside DDD).
>>>>>>>>>>>>
>>>>>>>>>>>> How the Hell did you twist my words to say that?
>>>>>>>>>>> I haven't touched your words. What I have done is to observe
>>>>>>>>>>> that
>>>>>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't
>>>>>>>>>>> itself a
>>>>>>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>>>>>>> simulator.
>>>>>>>>>>> It's recursion without a base case - a rookie error.
>>>>>>>>>>> HHH cannot successfully complete its task, because it never
>>>>>>>>>>> regains
>>>>>>>>>>> control after the first recursion. To return, it must abort the
>>>>>>>>>>> simulation, which means the simulation fails.
>>>>>>>>>>>
>>>>>>>>>>>> void DDD()
>>>>>>>>>>>> {
>>>>>>>>>>>> HHH(DDD);
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>>>>>>> simulated by HHH then this correctly simulated
>>>>>>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>>>>>>
>>>>>>>>>> Any competent C programmer can see that
>>>>>>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>>>>>>> is equivalent to infinite recursion.
>>>>>>>>>>
>>>>>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and
>>>>>>>>>>> assuming it
>>>>>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>>>>>
>>>>>>>>>>> void DDD(void) {
>>>>>>>>>>> DDD();
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Then the return statement (which is unnecessary anyway) will
>>>>>>>>>>> never be
>>>>>>>>>>> reached. In practice, the program will likely crash due to a
>>>>>>>>>>> stack
>>>>>>>>>>> overflow, unless the compiler implements tail-call
>>>>>>>>>>> optimization, in
>>>>>>>>>>> which case the program might just run forever -- which also
>>>>>>>>>>> means the
>>>>>>>>>>> unnecessary return statement will never be reached.
>>>>>>>>>
>>>>>>>>> I had not intended to post again, but I feel the need to make
>>>>>>>>> a clarification.
>>>>>>>>>
>>>>>>>>> I acknowledged that the return statement would never be reached
>>>>>>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>>>>>>> that assumption, a call to DDD() should be equivalent to a call
>>>>>>>>> to HHH(DDD).
>>>>>>>>>
>>>>>>>>> I did not address whether the assumption is valid. I merely
>>>>>>>>> temporarily accepted it for the sake of discussion, just as I
>>>>>>>>> would
>>>>>>>>> accept that if I were ten feet tall I would bump my head against
>>>>>>>>> the ceiling in my house.
>>>>>>>>>
>>>>>>>>> The discussion I had with olcott did not reach the point of
>>>>>>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>>>>>>> would even be logically possible for it to do so. I also did not
>>>>>>>>> address any issues of partial simulation, where olcott claims that
>>>>>>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>>>>>>> than simulating its entire execution. I did not participate in
>>>>>>>>> any discussion that would require knowledge of x86 machine or
>>>>>>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>>>>>>> and assembly code reasonably well if motivated to do so, but I am
>>>>>>>>> not so motivated.)
>>>>>>>>>
>>>>>>>>> What I acknowledged was barely more than "if HHH correctly
>>>>>>>>> simulates
>>>>>>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>>>>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>>>>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>>>>>>> prefer that olcott refrain from using my words to support any of
>>>>>>>>> his arguments beyond the scope of what he and I directly
>>>>>>>>> discussed.
>>>>>>>>
>>>>>>>> Don't know why you people stick on the 'simulation' stuff so long.
>>>>>>>> The HP simply asks for such an H (in function form. POOH does not
>>>>>>>> resemble TM):
>>>>>>>> H(D)=1 if D() halt.
>>>>>>>> H(D)=0 if D() not halt.
>>>>>>>
>>>>>>> My invention of a simulating termination
>>>>>>> analyzer shows exactly how to compute the
>>>>>>> mapping that the input that HHH(DD) specifies
>>>>>>> into a correct answer for the halting problem's
>>>>>>> otherwise impossible input.
>>>>>>>
>>>>>>> All rebuttals are based on failing to compute
>>>>>>> this mapping correctly.
>>>>>>>
>>>>>>
>>>>>> What is the correct mapping?
>>>>>>
>>>>>
>>>>> _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]
>>>>>
>>>>> Computing the mapping of DDD emulated by HHH
>>>>> according the the rules of the x86 language
>>>>> to its behavior by HHH actually emulating DDD.
>>>>
>>>> The above says you have no idea what the mapping is.
>>>>
>>>>>> If POOH are not talking about the mapping:
>>>>>>
>>>>>> H(D)=1 if D() halt.
>>>>>> H(D)=0 if D() not halt.
>>>>>>
>>>>>
>>>>> The way that simulating termination analyzers process
>>>>> their input by showing all of the steps of how the mapping
>>>>> must be computed refutes the above simplistic view.
>>>>
>>>> No (real) problem with that. But the HP asks:
>>>>
>>>> H(D)=1 if D() halt.
>>>> H(D)=0 if D() not halt.
>>>>
>>>> You still evade the question: Is POO H anything to do with the HP?
>>>>
>>>
>>> I have recently proven that the above requirements are incorrect.
>> it that correct?
>>
>> Be it (HP) correct or not. Your 'revision' says POOH is not about the HP,
>> it that correct?
>>
>
> 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.
>
Right, but not all functions must have that property. That only applie
if the function is computable (since that is the definition of being
computable).
The Halting Function is defined by the possible non-finite algortihm of
running the program that is represented by the input
> _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.
But that pre-supposses that HHH does correctly emulate its input, which
requires that HHH can NEVER abort its emuation, and thus it fails to be
a decider.
>
> This causes the first four instructions of DDD
> to be emulated followed by HHH emulating itself
> emulating the first three instructions of DDD.
Which means we should see the instructions of HHH being emulated, not
the result of the emulation they are doing.
Note, this first requires that the code for HHH was added to the input.
>
> It is right at this recursive simulation just
> before HHH(DDD) is called again that HHH recognizes
> the repeating pattern and rejects DDD.
WHich is incorrect.
If HHH decides to abort its emulation at this point, to confirm that
decision we need to actually correctly emulate this exact code, like
what HHH1 does, and it sees that later in the emulation that the
emulated HHH will also make that same decision (since it IS the same
code as the HHH that aborted) and return to DDD which then halts.
So, your "repeating pattern" is just a false premise, making your whole
arguemnt unsound.
Your whole argument is based on using equivocation to insert
contradictory definitions and lies into your system, and just some
stupid lies.
>
>>> That people consistently ignore this proof with pure bluster
>>> is not actually any rebuttal at all.
>>
>> Other people's rebuttal of POOH may not be valid, if POOH is not about
>> the HP.
>>
>>
>>>>>> POOH is likely nothing to do with HP
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 08:54 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <f0f36eb1e712a0bc87afec48c24db376a47adaf2@i2pn2.org> |
| In reply to | #118267 |
On 5/10/25 12:44 AM, olcott wrote:
> On 5/9/2025 11:32 PM, wij wrote:
>> On Fri, 2025-05-09 at 23:18 -0500, olcott wrote:
>>> On 5/9/2025 10:43 PM, wij wrote:
>>>> On Fri, 2025-05-09 at 22:24 -0500, olcott wrote:
>>>>> On 5/9/2025 10:13 PM, wij wrote:
>>>>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>>>>> "return" instruction.
>>>>>>>>>>>
>>>>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>>>>> inside DDD).
>>>>>>>>>>
>>>>>>>>>> How the Hell did you twist my words to say that?
>>>>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't
>>>>>>>>> itself a
>>>>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>>>>> simulator.
>>>>>>>>> It's recursion without a base case - a rookie error.
>>>>>>>>> HHH cannot successfully complete its task, because it never
>>>>>>>>> regains
>>>>>>>>> control after the first recursion. To return, it must abort the
>>>>>>>>> simulation, which means the simulation fails.
>>>>>>>>>
>>>>>>>>>> void DDD()
>>>>>>>>>> {
>>>>>>>>>> HHH(DDD);
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>>>>> simulated by HHH then this correctly simulated
>>>>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>>>>
>>>>>>>> Any competent C programmer can see that
>>>>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>>>>> is equivalent to infinite recursion.
>>>>>>>>
>>>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>>>
>>>>>>>>> void DDD(void) {
>>>>>>>>> DDD();
>>>>>>>>> return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Then the return statement (which is unnecessary anyway) will
>>>>>>>>> never be
>>>>>>>>> reached. In practice, the program will likely crash due to a
>>>>>>>>> stack
>>>>>>>>> overflow, unless the compiler implements tail-call
>>>>>>>>> optimization, in
>>>>>>>>> which case the program might just run forever -- which also
>>>>>>>>> means the
>>>>>>>>> unnecessary return statement will never be reached.
>>>>>>>
>>>>>>> I had not intended to post again, but I feel the need to make
>>>>>>> a clarification.
>>>>>>>
>>>>>>> I acknowledged that the return statement would never be reached
>>>>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>>>>> that assumption, a call to DDD() should be equivalent to a call
>>>>>>> to HHH(DDD).
>>>>>>>
>>>>>>> I did not address whether the assumption is valid. I merely
>>>>>>> temporarily accepted it for the sake of discussion, just as I would
>>>>>>> accept that if I were ten feet tall I would bump my head against
>>>>>>> the ceiling in my house.
>>>>>>>
>>>>>>> The discussion I had with olcott did not reach the point of
>>>>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>>>>> would even be logically possible for it to do so. I also did not
>>>>>>> address any issues of partial simulation, where olcott claims that
>>>>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>>>>> than simulating its entire execution. I did not participate in
>>>>>>> any discussion that would require knowledge of x86 machine or
>>>>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>>>>> and assembly code reasonably well if motivated to do so, but I am
>>>>>>> not so motivated.)
>>>>>>>
>>>>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>>>>> prefer that olcott refrain from using my words to support any of
>>>>>>> his arguments beyond the scope of what he and I directly discussed.
>>>>>>
>>>>>> Don't know why you people stick on the 'simulation' stuff so long.
>>>>>> The HP simply asks for such an H (in function form. POOH does not
>>>>>> resemble TM):
>>>>>> H(D)=1 if D() halt.
>>>>>> H(D)=0 if D() not halt.
>>>>>
>>>>> My invention of a simulating termination
>>>>> analyzer shows exactly how to compute the
>>>>> mapping that the input that HHH(DD) specifies
>>>>> into a correct answer for the halting problem's
>>>>> otherwise impossible input.
>>>>>
>>>>> All rebuttals are based on failing to compute
>>>>> this mapping correctly.
>>>>>
>>>>
>>>> What is the correct mapping?
>>>>
>>>
>>> _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]
>>>
>>> Computing the mapping of DDD emulated by HHH
>>> according the the rules of the x86 language
>>> to its behavior by HHH actually emulating DDD.
>>
>> The above says you have no idea what the mapping is.
>>
>>>> If POOH are not talking about the mapping:
>>>>
>>>> H(D)=1 if D() halt.
>>>> H(D)=0 if D() not halt.
>>>>
>>>
>>> The way that simulating termination analyzers process
>>> their input by showing all of the steps of how the mapping
>>> must be computed refutes the above simplistic view.
>>
>> No (real) problem with that. But the HP asks:
>>
>> H(D)=1 if D() halt.
>> H(D)=0 if D() not halt.
>>
>> You still evade the question: Is POO H anything to do with the HP?
>>
>
> I have recently proven that the above requirements are incorrect.
> That people consistently ignore this proof with pure bluster
> is not actually any rebuttal at all.
No, you haven't, because that is not a thing that can be proven.
Sorry, all you are doing is proving that you idea of logic is just a big
lie full of contradictions and equivocations.
>
>>>> POOH is likely nothing to do with HP
>>>>
>>>
>>>
>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 08:53 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <d82cff7b25192671874aabc74989b7aaf75efb29@i2pn2.org> |
| In reply to | #118263 |
On 5/10/25 12:18 AM, olcott wrote:
> On 5/9/2025 10:43 PM, wij wrote:
>> On Fri, 2025-05-09 at 22:24 -0500, olcott wrote:
>>> On 5/9/2025 10:13 PM, wij wrote:
>>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>>> "return" instruction.
>>>>>>>>>
>>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>>> inside DDD).
>>>>>>>>
>>>>>>>> How the Hell did you twist my words to say that?
>>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>>> simulator.
>>>>>>> It's recursion without a base case - a rookie error.
>>>>>>> HHH cannot successfully complete its task, because it never regains
>>>>>>> control after the first recursion. To return, it must abort the
>>>>>>> simulation, which means the simulation fails.
>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>>> simulated by HHH then this correctly simulated
>>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>>
>>>>>> Any competent C programmer can see that
>>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>>> is equivalent to infinite recursion.
>>>>>>
>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>
>>>>>>> void DDD(void) {
>>>>>>> DDD();
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> Then the return statement (which is unnecessary anyway) will
>>>>>>> never be
>>>>>>> reached. In practice, the program will likely crash due to a stack
>>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>>> which case the program might just run forever -- which also means
>>>>>>> the
>>>>>>> unnecessary return statement will never be reached.
>>>>>
>>>>> I had not intended to post again, but I feel the need to make
>>>>> a clarification.
>>>>>
>>>>> I acknowledged that the return statement would never be reached
>>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>>> that assumption, a call to DDD() should be equivalent to a call
>>>>> to HHH(DDD).
>>>>>
>>>>> I did not address whether the assumption is valid. I merely
>>>>> temporarily accepted it for the sake of discussion, just as I would
>>>>> accept that if I were ten feet tall I would bump my head against
>>>>> the ceiling in my house.
>>>>>
>>>>> The discussion I had with olcott did not reach the point of
>>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>>> would even be logically possible for it to do so. I also did not
>>>>> address any issues of partial simulation, where olcott claims that
>>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>>> than simulating its entire execution. I did not participate in
>>>>> any discussion that would require knowledge of x86 machine or
>>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>>> and assembly code reasonably well if motivated to do so, but I am
>>>>> not so motivated.)
>>>>>
>>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>>> prefer that olcott refrain from using my words to support any of
>>>>> his arguments beyond the scope of what he and I directly discussed.
>>>>
>>>> Don't know why you people stick on the 'simulation' stuff so long.
>>>> The HP simply asks for such an H (in function form. POOH does not
>>>> resemble TM):
>>>> H(D)=1 if D() halt.
>>>> H(D)=0 if D() not halt.
>>>
>>> My invention of a simulating termination
>>> analyzer shows exactly how to compute the
>>> mapping that the input that HHH(DD) specifies
>>> into a correct answer for the halting problem's
>>> otherwise impossible input.
>>>
>>> All rebuttals are based on failing to compute
>>> this mapping correctly.
>>>
>>
>> What is the correct mapping?
>>
>
> _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]
>
> Computing the mapping of DDD emulated by HHH
> according the the rules of the x86 language
> to its behavior by HHH actually emulating DDD.
But HHH doesn't correctly emulate DDD by the rules, so you don't have a
mapping.
First, it can't emulate what it doesn't have, so can't go paste the call
to HHH, unless you are allowig unpure versions of HHH, at which point
your claim is just false.
The criteria of "DDD emulated by HHH" is just an bad criteria as it
isn't one being subjective not objective)
>
>> If POOH are not talking about the mapping:
>>
>> H(D)=1 if D() halt.
>> H(D)=0 if D() not halt.
>>
>
> The way that simulating termination analyzers process
> their input by showing all of the steps of how the mapping
> must be computed refutes the above simplistic view.
>
>> POOH is likely nothing to do with HP
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 23:53 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <5b613cbbf5464cced9768f517ff31c2b8bb34490@i2pn2.org> |
| In reply to | #118250 |
On 5/9/25 11:24 PM, olcott wrote:
> On 5/9/2025 10:13 PM, wij wrote:
>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>> We have not begun to get into any of those points.
>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>> "return" instruction.
>>>>>>>
>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>> inside DDD).
>>>>>>
>>>>>> How the Hell did you twist my words to say that?
>>>>> I haven't touched your words. What I have done is to observe that
>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>> simulator, there is nothing to simulate except a call to a
>>>>> simulator.
>>>>> It's recursion without a base case - a rookie error.
>>>>> HHH cannot successfully complete its task, because it never regains
>>>>> control after the first recursion. To return, it must abort the
>>>>> simulation, which means the simulation fails.
>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> When 1 or more statements of DDD are correctly
>>>>>> simulated by HHH then this correctly simulated
>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>> readership that HHH 'correctly simulated' DDD?
>>>>
>>>> Any competent C programmer can see that
>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>> is equivalent to infinite recursion.
>>>>
>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>> does nothing else, your code would be equivalent to this:
>>>>>
>>>>> void DDD(void) {
>>>>> DDD();
>>>>> return;
>>>>> }
>>>>>
>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>> reached. In practice, the program will likely crash due to a stack
>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>> which case the program might just run forever -- which also means the
>>>>> unnecessary return statement will never be reached.
>>>
>>> I had not intended to post again, but I feel the need to make
>>> a clarification.
>>>
>>> I acknowledged that the return statement would never be reached
>>> *given the assumption* that HHH correctly simulates DDD. Given
>>> that assumption, a call to DDD() should be equivalent to a call
>>> to HHH(DDD).
>>>
>>> I did not address whether the assumption is valid. I merely
>>> temporarily accepted it for the sake of discussion, just as I would
>>> accept that if I were ten feet tall I would bump my head against
>>> the ceiling in my house.
>>>
>>> The discussion I had with olcott did not reach the point of
>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>> would even be logically possible for it to do so. I also did not
>>> address any issues of partial simulation, where olcott claims that
>>> HHH can "accurately simulate" only a few x86 instructions rather
>>> than simulating its entire execution. I did not participate in
>>> any discussion that would require knowledge of x86 machine or
>>> assembly code. (I have no doubt that I could learn x86 machine
>>> and assembly code reasonably well if motivated to do so, but I am
>>> not so motivated.)
>>>
>>> What I acknowledged was barely more than "if HHH correctly simulates
>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>> is that HHH logically cannot accurately simulate DDD.) I would
>>> prefer that olcott refrain from using my words to support any of
>>> his arguments beyond the scope of what he and I directly discussed.
>>
>> Don't know why you people stick on the 'simulation' stuff so long.
>> The HP simply asks for such an H (in function form. POOH does not
>> resemble TM):
>> H(D)=1 if D() halt.
>> H(D)=0 if D() not halt.
>
> My invention of a simulating termination
> analyzer shows exactly how to compute the
> mapping that the input that HHH(DD) specifies
> into a correct answer for the halting problem's
> otherwise impossible input.
>
> All rebuttals are based on failing to compute
> this mapping correctly.
>
The problem is you don't compute the correct mapping, as you LIE by
changing the defined mapping with your strawman,
Termination Analyzer, BY THEIR DEFINITION, determine if the program
represented by their input will halt when run. PERIOD.
Until you can docuemnt a reliable source that gives your strawman, you
ar just proven to be a stupid liar that has proved his ignorance.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 23:13 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmjoh$3atmt$2@dont-email.me> |
| In reply to | #118257 |
On 5/9/2025 10:53 PM, Richard Damon wrote:
> On 5/9/25 11:24 PM, olcott wrote:
>> On 5/9/2025 10:13 PM, wij wrote:
>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>> "return" instruction.
>>>>>>>>
>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>> inside DDD).
>>>>>>>
>>>>>>> How the Hell did you twist my words to say that?
>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>> simulator.
>>>>>> It's recursion without a base case - a rookie error.
>>>>>> HHH cannot successfully complete its task, because it never regains
>>>>>> control after the first recursion. To return, it must abort the
>>>>>> simulation, which means the simulation fails.
>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>> simulated by HHH then this correctly simulated
>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>
>>>>> Any competent C programmer can see that
>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>> is equivalent to infinite recursion.
>>>>>
>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>
>>>>>> void DDD(void) {
>>>>>> DDD();
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>>> reached. In practice, the program will likely crash due to a stack
>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>> which case the program might just run forever -- which also means the
>>>>>> unnecessary return statement will never be reached.
>>>>
>>>> I had not intended to post again, but I feel the need to make
>>>> a clarification.
>>>>
>>>> I acknowledged that the return statement would never be reached
>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>> that assumption, a call to DDD() should be equivalent to a call
>>>> to HHH(DDD).
>>>>
>>>> I did not address whether the assumption is valid. I merely
>>>> temporarily accepted it for the sake of discussion, just as I would
>>>> accept that if I were ten feet tall I would bump my head against
>>>> the ceiling in my house.
>>>>
>>>> The discussion I had with olcott did not reach the point of
>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>> would even be logically possible for it to do so. I also did not
>>>> address any issues of partial simulation, where olcott claims that
>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>> than simulating its entire execution. I did not participate in
>>>> any discussion that would require knowledge of x86 machine or
>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>> and assembly code reasonably well if motivated to do so, but I am
>>>> not so motivated.)
>>>>
>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>> prefer that olcott refrain from using my words to support any of
>>>> his arguments beyond the scope of what he and I directly discussed.
>>>
>>> Don't know why you people stick on the 'simulation' stuff so long.
>>> The HP simply asks for such an H (in function form. POOH does not
>>> resemble TM):
>>> H(D)=1 if D() halt.
>>> H(D)=0 if D() not halt.
>>
>> My invention of a simulating termination
>> analyzer shows exactly how to compute the
>> mapping that the input that HHH(DD) specifies
>> into a correct answer for the halting problem's
>> otherwise impossible input.
>>
>> All rebuttals are based on failing to compute
>> this mapping correctly.
>>
>
> The problem is you don't compute the correct mapping, as you LIE by
> changing the defined mapping with your strawman,
>
> Termination Analyzer, BY THEIR DEFINITION, determine if the program
> represented by their input will halt when run. PERIOD.
>
When definitions contradict each other at
least one of them is wrong.
HHH(DDD) computes the mapping from its input finite
string according to the rules of the x86 language
thus obtains the actual behavior THAT THIS INPUT STRING SPECIFIES.
> Until you can docuemnt a reliable source that gives your strawman, you
> ar just proven to be a stupid liar that has proved his ignorance.
My reasoning itself is air tight. You usually only have weasel words.
--
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 00:18 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmk1p$35h7o$1@dont-email.me> |
| In reply to | #118261 |
On 5/10/2025 12:13 AM, olcott wrote:
> On 5/9/2025 10:53 PM, Richard Damon wrote:
>> On 5/9/25 11:24 PM, olcott wrote:
>>> On 5/9/2025 10:13 PM, wij wrote:
>>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>>> "return" instruction.
>>>>>>>>>
>>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>>> inside DDD).
>>>>>>>>
>>>>>>>> How the Hell did you twist my words to say that?
>>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>>> simulator.
>>>>>>> It's recursion without a base case - a rookie error.
>>>>>>> HHH cannot successfully complete its task, because it never regains
>>>>>>> control after the first recursion. To return, it must abort the
>>>>>>> simulation, which means the simulation fails.
>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>>> simulated by HHH then this correctly simulated
>>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>>
>>>>>> Any competent C programmer can see that
>>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>>> is equivalent to infinite recursion.
>>>>>>
>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>
>>>>>>> void DDD(void) {
>>>>>>> DDD();
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> Then the return statement (which is unnecessary anyway) will
>>>>>>> never be
>>>>>>> reached. In practice, the program will likely crash due to a stack
>>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>>> which case the program might just run forever -- which also means
>>>>>>> the
>>>>>>> unnecessary return statement will never be reached.
>>>>>
>>>>> I had not intended to post again, but I feel the need to make
>>>>> a clarification.
>>>>>
>>>>> I acknowledged that the return statement would never be reached
>>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>>> that assumption, a call to DDD() should be equivalent to a call
>>>>> to HHH(DDD).
>>>>>
>>>>> I did not address whether the assumption is valid. I merely
>>>>> temporarily accepted it for the sake of discussion, just as I would
>>>>> accept that if I were ten feet tall I would bump my head against
>>>>> the ceiling in my house.
>>>>>
>>>>> The discussion I had with olcott did not reach the point of
>>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>>> would even be logically possible for it to do so. I also did not
>>>>> address any issues of partial simulation, where olcott claims that
>>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>>> than simulating its entire execution. I did not participate in
>>>>> any discussion that would require knowledge of x86 machine or
>>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>>> and assembly code reasonably well if motivated to do so, but I am
>>>>> not so motivated.)
>>>>>
>>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>>> prefer that olcott refrain from using my words to support any of
>>>>> his arguments beyond the scope of what he and I directly discussed.
>>>>
>>>> Don't know why you people stick on the 'simulation' stuff so long.
>>>> The HP simply asks for such an H (in function form. POOH does not
>>>> resemble TM):
>>>> H(D)=1 if D() halt.
>>>> H(D)=0 if D() not halt.
>>>
>>> My invention of a simulating termination
>>> analyzer shows exactly how to compute the
>>> mapping that the input that HHH(DD) specifies
>>> into a correct answer for the halting problem's
>>> otherwise impossible input.
>>>
>>> All rebuttals are based on failing to compute
>>> this mapping correctly.
>>>
>>
>> The problem is you don't compute the correct mapping, as you LIE by
>> changing the defined mapping with your strawman,
>>
>> Termination Analyzer, BY THEIR DEFINITION, determine if the program
>> represented by their input will halt when run. PERIOD.
>>
>
> When definitions contradict each other at
> least one of them is wrong.
>
> HHH(DDD) computes the mapping from its input finite
> string
i.e. a description of the algorithm containing the fixed code of the
function DD, the fixed code of the function HHH, and the fixed code of
everything that HHH calls down to the OS level.
> according to the rules of the x86 language
Which is what happens when DD is actually run on an actual x86
processor, and that is halt.
> thus obtains the actual behavior THAT THIS INPUT STRING SPECIFIES.
i.e. halting.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 10:25 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn2hq$3dv8d$6@dont-email.me> |
| In reply to | #118261 |
Op 10.mei.2025 om 06:13 schreef olcott:
> On 5/9/2025 10:53 PM, Richard Damon wrote:
>> On 5/9/25 11:24 PM, olcott wrote:
>>> On 5/9/2025 10:13 PM, wij wrote:
>>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>>> "return" instruction.
>>>>>>>>>
>>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>>> inside DDD).
>>>>>>>>
>>>>>>>> How the Hell did you twist my words to say that?
>>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>>> simulator.
>>>>>>> It's recursion without a base case - a rookie error.
>>>>>>> HHH cannot successfully complete its task, because it never regains
>>>>>>> control after the first recursion. To return, it must abort the
>>>>>>> simulation, which means the simulation fails.
>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>>> simulated by HHH then this correctly simulated
>>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>>
>>>>>> Any competent C programmer can see that
>>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>>> is equivalent to infinite recursion.
>>>>>>
>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>
>>>>>>> void DDD(void) {
>>>>>>> DDD();
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> Then the return statement (which is unnecessary anyway) will
>>>>>>> never be
>>>>>>> reached. In practice, the program will likely crash due to a stack
>>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>>> which case the program might just run forever -- which also means
>>>>>>> the
>>>>>>> unnecessary return statement will never be reached.
>>>>>
>>>>> I had not intended to post again, but I feel the need to make
>>>>> a clarification.
>>>>>
>>>>> I acknowledged that the return statement would never be reached
>>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>>> that assumption, a call to DDD() should be equivalent to a call
>>>>> to HHH(DDD).
>>>>>
>>>>> I did not address whether the assumption is valid. I merely
>>>>> temporarily accepted it for the sake of discussion, just as I would
>>>>> accept that if I were ten feet tall I would bump my head against
>>>>> the ceiling in my house.
>>>>>
>>>>> The discussion I had with olcott did not reach the point of
>>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>>> would even be logically possible for it to do so. I also did not
>>>>> address any issues of partial simulation, where olcott claims that
>>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>>> than simulating its entire execution. I did not participate in
>>>>> any discussion that would require knowledge of x86 machine or
>>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>>> and assembly code reasonably well if motivated to do so, but I am
>>>>> not so motivated.)
>>>>>
>>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>>> prefer that olcott refrain from using my words to support any of
>>>>> his arguments beyond the scope of what he and I directly discussed.
>>>>
>>>> Don't know why you people stick on the 'simulation' stuff so long.
>>>> The HP simply asks for such an H (in function form. POOH does not
>>>> resemble TM):
>>>> H(D)=1 if D() halt.
>>>> H(D)=0 if D() not halt.
>>>
>>> My invention of a simulating termination
>>> analyzer shows exactly how to compute the
>>> mapping that the input that HHH(DD) specifies
>>> into a correct answer for the halting problem's
>>> otherwise impossible input.
>>>
>>> All rebuttals are based on failing to compute
>>> this mapping correctly.
>>>
>>
>> The problem is you don't compute the correct mapping, as you LIE by
>> changing the defined mapping with your strawman,
>>
>> Termination Analyzer, BY THEIR DEFINITION, determine if the program
>> represented by their input will halt when run. PERIOD.
>>
>
> When definitions contradict each other at
> least one of them is wrong.
>
> HHH(DDD) computes the mapping from its input finite
> string according to the rules of the x86 language
> thus obtains the actual behavior THAT THIS INPUT STRING SPECIFIES.
>
But ignores the most important part of the input that specifies that the
program aborts and halt. So, the mapping is incorrect. A correct mapping
uses the full input, not only an irrelevant part of the finite string.
It seems that you are unable to accept verifiable facts when they
disturb your dreams.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 08:59 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <2af97c95358d74754921dce8ec02f8b63809a4e4@i2pn2.org> |
| In reply to | #118261 |
On 5/10/25 12:13 AM, olcott wrote:
> On 5/9/2025 10:53 PM, Richard Damon wrote:
>> On 5/9/25 11:24 PM, olcott wrote:
>>> On 5/9/2025 10:13 PM, wij wrote:
>>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>>> "return" instruction.
>>>>>>>>>
>>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>>> inside DDD).
>>>>>>>>
>>>>>>>> How the Hell did you twist my words to say that?
>>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>>> simulator.
>>>>>>> It's recursion without a base case - a rookie error.
>>>>>>> HHH cannot successfully complete its task, because it never regains
>>>>>>> control after the first recursion. To return, it must abort the
>>>>>>> simulation, which means the simulation fails.
>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>>> simulated by HHH then this correctly simulated
>>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>>
>>>>>> Any competent C programmer can see that
>>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>>> is equivalent to infinite recursion.
>>>>>>
>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>
>>>>>>> void DDD(void) {
>>>>>>> DDD();
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> Then the return statement (which is unnecessary anyway) will
>>>>>>> never be
>>>>>>> reached. In practice, the program will likely crash due to a stack
>>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>>> which case the program might just run forever -- which also means
>>>>>>> the
>>>>>>> unnecessary return statement will never be reached.
>>>>>
>>>>> I had not intended to post again, but I feel the need to make
>>>>> a clarification.
>>>>>
>>>>> I acknowledged that the return statement would never be reached
>>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>>> that assumption, a call to DDD() should be equivalent to a call
>>>>> to HHH(DDD).
>>>>>
>>>>> I did not address whether the assumption is valid. I merely
>>>>> temporarily accepted it for the sake of discussion, just as I would
>>>>> accept that if I were ten feet tall I would bump my head against
>>>>> the ceiling in my house.
>>>>>
>>>>> The discussion I had with olcott did not reach the point of
>>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>>> would even be logically possible for it to do so. I also did not
>>>>> address any issues of partial simulation, where olcott claims that
>>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>>> than simulating its entire execution. I did not participate in
>>>>> any discussion that would require knowledge of x86 machine or
>>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>>> and assembly code reasonably well if motivated to do so, but I am
>>>>> not so motivated.)
>>>>>
>>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>>> prefer that olcott refrain from using my words to support any of
>>>>> his arguments beyond the scope of what he and I directly discussed.
>>>>
>>>> Don't know why you people stick on the 'simulation' stuff so long.
>>>> The HP simply asks for such an H (in function form. POOH does not
>>>> resemble TM):
>>>> H(D)=1 if D() halt.
>>>> H(D)=0 if D() not halt.
>>>
>>> My invention of a simulating termination
>>> analyzer shows exactly how to compute the
>>> mapping that the input that HHH(DD) specifies
>>> into a correct answer for the halting problem's
>>> otherwise impossible input.
>>>
>>> All rebuttals are based on failing to compute
>>> this mapping correctly.
>>>
>>
>> The problem is you don't compute the correct mapping, as you LIE by
>> changing the defined mapping with your strawman,
>>
>> Termination Analyzer, BY THEIR DEFINITION, determine if the program
>> represented by their input will halt when run. PERIOD.
>>
>
> When definitions contradict each other at
> least one of them is wrong.
And what is the contradiction? (as opposed to you just not understanding
what was said?)
>
> HHH(DDD) computes the mapping from its input finite
> string according to the rules of the x86 language
> thus obtains the actual behavior THAT THIS INPUT STRING SPECIFIES.
No, the behavior the input string specifies doesn't come from the
subjective stanadard of what HHH does, it comes from the objective
standard of the problem statement.
The results of the mapping that HHH computes, is what its answer is, If
that doesn't match the CORRECT answer from the DEFINED mapping from the
DEFINED behavior, it is just wrong.
It seems you logic just doens't understand the concept that you can be
wrong, which you are very often.
>
>> Until you can docuemnt a reliable source that gives your strawman, you
>> ar just proven to be a stupid liar that has proved his ignorance.
>
> My reasoning itself is air tight. You usually only have weasel words.
>
Like a screen door on a submarine, now sitting at the bottom of the lake
of fire.
You are just showing that you just fundamentally lack the understanding
of the words you are using.
What HHH computes does not define the right answer to the problem, it
defines what HHH computes. The answer comes from the problem, that
apparently is using words you don't understand, as they require looking
at what something actualy does when looked at objectively, something
that seems to be beyond your understanding.
Sorry, you are just proving how stupid you are.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 10:22 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn2cm$3dv8d$5@dont-email.me> |
| In reply to | #118250 |
Op 10.mei.2025 om 05:24 schreef olcott:
> On 5/9/2025 10:13 PM, wij wrote:
>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>> We have not begun to get into any of those points.
>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>> "return" instruction.
>>>>>>>
>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>> inside DDD).
>>>>>>
>>>>>> How the Hell did you twist my words to say that?
>>>>> I haven't touched your words. What I have done is to observe that
>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>> simulator, there is nothing to simulate except a call to a
>>>>> simulator.
>>>>> It's recursion without a base case - a rookie error.
>>>>> HHH cannot successfully complete its task, because it never regains
>>>>> control after the first recursion. To return, it must abort the
>>>>> simulation, which means the simulation fails.
>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> When 1 or more statements of DDD are correctly
>>>>>> simulated by HHH then this correctly simulated
>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>> readership that HHH 'correctly simulated' DDD?
>>>>
>>>> Any competent C programmer can see that
>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>> is equivalent to infinite recursion.
>>>>
>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>> does nothing else, your code would be equivalent to this:
>>>>>
>>>>> void DDD(void) {
>>>>> DDD();
>>>>> return;
>>>>> }
>>>>>
>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>> reached. In practice, the program will likely crash due to a stack
>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>> which case the program might just run forever -- which also means the
>>>>> unnecessary return statement will never be reached.
>>>
>>> I had not intended to post again, but I feel the need to make
>>> a clarification.
>>>
>>> I acknowledged that the return statement would never be reached
>>> *given the assumption* that HHH correctly simulates DDD. Given
>>> that assumption, a call to DDD() should be equivalent to a call
>>> to HHH(DDD).
>>>
>>> I did not address whether the assumption is valid. I merely
>>> temporarily accepted it for the sake of discussion, just as I would
>>> accept that if I were ten feet tall I would bump my head against
>>> the ceiling in my house.
>>>
>>> The discussion I had with olcott did not reach the point of
>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>> would even be logically possible for it to do so. I also did not
>>> address any issues of partial simulation, where olcott claims that
>>> HHH can "accurately simulate" only a few x86 instructions rather
>>> than simulating its entire execution. I did not participate in
>>> any discussion that would require knowledge of x86 machine or
>>> assembly code. (I have no doubt that I could learn x86 machine
>>> and assembly code reasonably well if motivated to do so, but I am
>>> not so motivated.)
>>>
>>> What I acknowledged was barely more than "if HHH correctly simulates
>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>> is that HHH logically cannot accurately simulate DDD.) I would
>>> prefer that olcott refrain from using my words to support any of
>>> his arguments beyond the scope of what he and I directly discussed.
>>
>> Don't know why you people stick on the 'simulation' stuff so long.
>> The HP simply asks for such an H (in function form. POOH does not
>> resemble TM):
>> H(D)=1 if D() halt.
>> H(D)=0 if D() not halt.
>
> My invention of a simulating termination
> analyzer shows exactly how to compute the
> mapping that the input that HHH(DD) specifies
> into a correct answer for the halting problem's
> otherwise impossible input.
And the input specifies a program that aborts and halts, but HHH ignores
that, so its mapping is incorrect.
It seems to difficult for you to accept verifiable facts hen they
disturb your dreams.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 23:31 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <c7aa10a6ad980ee2b7b66097a24c3a63e41a59a0@i2pn2.org> |
| In reply to | #118239 |
On 5/9/25 11:13 PM, wij wrote:
> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>> On 09/05/2025 21:15, olcott wrote:
>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>> We have not begun to get into any of those points.
>>>>>>> We are only asking can DDD correctly simulated
>>>>>>> by any HHH that can exist ever reach its own
>>>>>>> "return" instruction.
>>>>>>
>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>> what you're trying to do when you fire up the simulation from
>>>>>> inside DDD).
>>>>>
>>>>> How the Hell did you twist my words to say that?
>>>> I haven't touched your words. What I have done is to observe that
>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>> simulator, there is nothing to simulate except a call to a
>>>> simulator.
>>>> It's recursion without a base case - a rookie error.
>>>> HHH cannot successfully complete its task, because it never regains
>>>> control after the first recursion. To return, it must abort the
>>>> simulation, which means the simulation fails.
>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> When 1 or more statements of DDD are correctly
>>>>> simulated by HHH then this correctly simulated
>>>>> DDD cannot possibly reach its own “return statement”.
>>>> On what grounds can you persuade an extraordinarily sceptical
>>>> readership that HHH 'correctly simulated' DDD?
>>>
>>> Any competent C programmer can see that
>>> the call from DDD to HHH(DDD) (its own simulator)
>>> is equivalent to infinite recursion.
>>>
>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>> does nothing else, your code would be equivalent to this:
>>>>
>>>> void DDD(void) {
>>>> DDD();
>>>> return;
>>>> }
>>>>
>>>> Then the return statement (which is unnecessary anyway) will never be
>>>> reached. In practice, the program will likely crash due to a stack
>>>> overflow, unless the compiler implements tail-call optimization, in
>>>> which case the program might just run forever -- which also means the
>>>> unnecessary return statement will never be reached.
>>
>> I had not intended to post again, but I feel the need to make
>> a clarification.
>>
>> I acknowledged that the return statement would never be reached
>> *given the assumption* that HHH correctly simulates DDD. Given
>> that assumption, a call to DDD() should be equivalent to a call
>> to HHH(DDD).
>>
>> I did not address whether the assumption is valid. I merely
>> temporarily accepted it for the sake of discussion, just as I would
>> accept that if I were ten feet tall I would bump my head against
>> the ceiling in my house.
>>
>> The discussion I had with olcott did not reach the point of
>> discussing *how* HHH could correctly simulate DDD, or whether it
>> would even be logically possible for it to do so. I also did not
>> address any issues of partial simulation, where olcott claims that
>> HHH can "accurately simulate" only a few x86 instructions rather
>> than simulating its entire execution. I did not participate in
>> any discussion that would require knowledge of x86 machine or
>> assembly code. (I have no doubt that I could learn x86 machine
>> and assembly code reasonably well if motivated to do so, but I am
>> not so motivated.)
>>
>> What I acknowledged was barely more than "if HHH correctly simulates
>> DDD, then HHH correctly simulates DDD". (My understanding from
>> posts by others, whom I presume to be sufficiently knowledgeable,
>> is that HHH logically cannot accurately simulate DDD.) I would
>> prefer that olcott refrain from using my words to support any of
>> his arguments beyond the scope of what he and I directly discussed.
>
> Don't know why you people stick on the 'simulation' stuff so long.
> The HP simply asks for such an H (in function form. POOH does not
> resemble TM):
> H(D)=1 if D() halt.
> H(D)=0 if D() not halt.
>
>
The issue is Peter thinks that by making H a "simulating Halt Decider"
or a "Simulating Termination Analyzer" it can change the definition, by
trying to put out a lying definition of Halting by lying about the
definition of correct simulation and what is the input.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 23:21 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmk84$3atmt$4@dont-email.me> |
| In reply to | #118254 |
On 5/9/2025 10:31 PM, Richard Damon wrote:
> On 5/9/25 11:13 PM, wij wrote:
>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>> We have not begun to get into any of those points.
>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>> "return" instruction.
>>>>>>>
>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>> inside DDD).
>>>>>>
>>>>>> How the Hell did you twist my words to say that?
>>>>> I haven't touched your words. What I have done is to observe that
>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>> simulator, there is nothing to simulate except a call to a
>>>>> simulator.
>>>>> It's recursion without a base case - a rookie error.
>>>>> HHH cannot successfully complete its task, because it never regains
>>>>> control after the first recursion. To return, it must abort the
>>>>> simulation, which means the simulation fails.
>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> When 1 or more statements of DDD are correctly
>>>>>> simulated by HHH then this correctly simulated
>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>> readership that HHH 'correctly simulated' DDD?
>>>>
>>>> Any competent C programmer can see that
>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>> is equivalent to infinite recursion.
>>>>
>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>> does nothing else, your code would be equivalent to this:
>>>>>
>>>>> void DDD(void) {
>>>>> DDD();
>>>>> return;
>>>>> }
>>>>>
>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>> reached. In practice, the program will likely crash due to a stack
>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>> which case the program might just run forever -- which also means the
>>>>> unnecessary return statement will never be reached.
>>>
>>> I had not intended to post again, but I feel the need to make
>>> a clarification.
>>>
>>> I acknowledged that the return statement would never be reached
>>> *given the assumption* that HHH correctly simulates DDD. Given
>>> that assumption, a call to DDD() should be equivalent to a call
>>> to HHH(DDD).
>>>
>>> I did not address whether the assumption is valid. I merely
>>> temporarily accepted it for the sake of discussion, just as I would
>>> accept that if I were ten feet tall I would bump my head against
>>> the ceiling in my house.
>>>
>>> The discussion I had with olcott did not reach the point of
>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>> would even be logically possible for it to do so. I also did not
>>> address any issues of partial simulation, where olcott claims that
>>> HHH can "accurately simulate" only a few x86 instructions rather
>>> than simulating its entire execution. I did not participate in
>>> any discussion that would require knowledge of x86 machine or
>>> assembly code. (I have no doubt that I could learn x86 machine
>>> and assembly code reasonably well if motivated to do so, but I am
>>> not so motivated.)
>>>
>>> What I acknowledged was barely more than "if HHH correctly simulates
>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>> is that HHH logically cannot accurately simulate DDD.) I would
>>> prefer that olcott refrain from using my words to support any of
>>> his arguments beyond the scope of what he and I directly discussed.
>>
>> Don't know why you people stick on the 'simulation' stuff so long.
>> The HP simply asks for such an H (in function form. POOH does not
>> resemble TM):
>> H(D)=1 if D() halt.
>> H(D)=0 if D() not halt.
>>
>>
>
> The issue is Peter thinks that by making H a "simulating Halt Decider"
> or a "Simulating Termination Analyzer" it can change the definition, by
> trying to put out a lying definition of Halting by lying about the
> definition of correct simulation and what is the input.
It is a stupid idea that halt deciders must be either
infallible or wrong so I switched to termination analyzers.
A termination analyzer is correct if it can process a
single input that itself has no inputs.
--
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 | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 10:34 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn32n$3dv8d$8@dont-email.me> |
| In reply to | #118264 |
Op 10.mei.2025 om 06:21 schreef olcott:
> On 5/9/2025 10:31 PM, Richard Damon wrote:
>> On 5/9/25 11:13 PM, wij wrote:
>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>> "return" instruction.
>>>>>>>>
>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>> inside DDD).
>>>>>>>
>>>>>>> How the Hell did you twist my words to say that?
>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>> simulator.
>>>>>> It's recursion without a base case - a rookie error.
>>>>>> HHH cannot successfully complete its task, because it never regains
>>>>>> control after the first recursion. To return, it must abort the
>>>>>> simulation, which means the simulation fails.
>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>> simulated by HHH then this correctly simulated
>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>
>>>>> Any competent C programmer can see that
>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>> is equivalent to infinite recursion.
>>>>>
>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>
>>>>>> void DDD(void) {
>>>>>> DDD();
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>>> reached. In practice, the program will likely crash due to a stack
>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>> which case the program might just run forever -- which also means the
>>>>>> unnecessary return statement will never be reached.
>>>>
>>>> I had not intended to post again, but I feel the need to make
>>>> a clarification.
>>>>
>>>> I acknowledged that the return statement would never be reached
>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>> that assumption, a call to DDD() should be equivalent to a call
>>>> to HHH(DDD).
>>>>
>>>> I did not address whether the assumption is valid. I merely
>>>> temporarily accepted it for the sake of discussion, just as I would
>>>> accept that if I were ten feet tall I would bump my head against
>>>> the ceiling in my house.
>>>>
>>>> The discussion I had with olcott did not reach the point of
>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>> would even be logically possible for it to do so. I also did not
>>>> address any issues of partial simulation, where olcott claims that
>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>> than simulating its entire execution. I did not participate in
>>>> any discussion that would require knowledge of x86 machine or
>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>> and assembly code reasonably well if motivated to do so, but I am
>>>> not so motivated.)
>>>>
>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>> prefer that olcott refrain from using my words to support any of
>>>> his arguments beyond the scope of what he and I directly discussed.
>>>
>>> Don't know why you people stick on the 'simulation' stuff so long.
>>> The HP simply asks for such an H (in function form. POOH does not
>>> resemble TM):
>>> H(D)=1 if D() halt.
>>> H(D)=0 if D() not halt.
>>>
>>>
>>
>> The issue is Peter thinks that by making H a "simulating Halt Decider"
>> or a "Simulating Termination Analyzer" it can change the definition,
>> by trying to put out a lying definition of Halting by lying about the
>> definition of correct simulation and what is the input.
>
> It is a stupid idea that halt deciders must be either
> infallible or wrong so I switched to termination analyzers.
>
> A termination analyzer is correct if it can process a
> single input that itself has no inputs.
Not only that, but it must also return the correct answer. If makes a
wild guess, by ignoring the most important part of its input, it will
very probably be incorrect.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-10 09:42 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn3ie$3ej78$1@dont-email.me> |
| In reply to | #118264 |
On 10/05/2025 05:21, olcott wrote:
<snip>
> A termination analyzer is correct if it can process a
> single input that itself has no inputs.
Provided you get to choose the input, you mean? If so, the claim
is meaningless, because:
void input()
{
}
bool analyze(program *p)
{
return true;
}
int main()
{
analyze(input);
puts("Halts.";
}
processes a single input that can correct a single input that
itself has no inputs. Big deal.
You need a better definition.
--
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 | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 09:09 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <00980b06f9f5c48292c806da4e087c4d5f12e87a@i2pn2.org> |
| In reply to | #118264 |
On 5/10/25 12:21 AM, olcott wrote:
> On 5/9/2025 10:31 PM, Richard Damon wrote:
>> On 5/9/25 11:13 PM, wij wrote:
>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>>>> On 09/05/2025 21:15, olcott wrote:
>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>>>> We have not begun to get into any of those points.
>>>>>>>>> We are only asking can DDD correctly simulated
>>>>>>>>> by any HHH that can exist ever reach its own
>>>>>>>>> "return" instruction.
>>>>>>>>
>>>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>>>> what you're trying to do when you fire up the simulation from
>>>>>>>> inside DDD).
>>>>>>>
>>>>>>> How the Hell did you twist my words to say that?
>>>>>> I haven't touched your words. What I have done is to observe that
>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>>>> simulator, there is nothing to simulate except a call to a
>>>>>> simulator.
>>>>>> It's recursion without a base case - a rookie error.
>>>>>> HHH cannot successfully complete its task, because it never regains
>>>>>> control after the first recursion. To return, it must abort the
>>>>>> simulation, which means the simulation fails.
>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> When 1 or more statements of DDD are correctly
>>>>>>> simulated by HHH then this correctly simulated
>>>>>>> DDD cannot possibly reach its own “return statement”.
>>>>>> On what grounds can you persuade an extraordinarily sceptical
>>>>>> readership that HHH 'correctly simulated' DDD?
>>>>>
>>>>> Any competent C programmer can see that
>>>>> the call from DDD to HHH(DDD) (its own simulator)
>>>>> is equivalent to infinite recursion.
>>>>>
>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>
>>>>>> void DDD(void) {
>>>>>> DDD();
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>>> reached. In practice, the program will likely crash due to a stack
>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>> which case the program might just run forever -- which also means the
>>>>>> unnecessary return statement will never be reached.
>>>>
>>>> I had not intended to post again, but I feel the need to make
>>>> a clarification.
>>>>
>>>> I acknowledged that the return statement would never be reached
>>>> *given the assumption* that HHH correctly simulates DDD. Given
>>>> that assumption, a call to DDD() should be equivalent to a call
>>>> to HHH(DDD).
>>>>
>>>> I did not address whether the assumption is valid. I merely
>>>> temporarily accepted it for the sake of discussion, just as I would
>>>> accept that if I were ten feet tall I would bump my head against
>>>> the ceiling in my house.
>>>>
>>>> The discussion I had with olcott did not reach the point of
>>>> discussing *how* HHH could correctly simulate DDD, or whether it
>>>> would even be logically possible for it to do so. I also did not
>>>> address any issues of partial simulation, where olcott claims that
>>>> HHH can "accurately simulate" only a few x86 instructions rather
>>>> than simulating its entire execution. I did not participate in
>>>> any discussion that would require knowledge of x86 machine or
>>>> assembly code. (I have no doubt that I could learn x86 machine
>>>> and assembly code reasonably well if motivated to do so, but I am
>>>> not so motivated.)
>>>>
>>>> What I acknowledged was barely more than "if HHH correctly simulates
>>>> DDD, then HHH correctly simulates DDD". (My understanding from
>>>> posts by others, whom I presume to be sufficiently knowledgeable,
>>>> is that HHH logically cannot accurately simulate DDD.) I would
>>>> prefer that olcott refrain from using my words to support any of
>>>> his arguments beyond the scope of what he and I directly discussed.
>>>
>>> Don't know why you people stick on the 'simulation' stuff so long.
>>> The HP simply asks for such an H (in function form. POOH does not
>>> resemble TM):
>>> H(D)=1 if D() halt.
>>> H(D)=0 if D() not halt.
>>>
>>>
>>
>> The issue is Peter thinks that by making H a "simulating Halt Decider"
>> or a "Simulating Termination Analyzer" it can change the definition,
>> by trying to put out a lying definition of Halting by lying about the
>> definition of correct simulation and what is the input.
>
> It is a stupid idea that halt deciders must be either
> infallible or wrong so I switched to termination analyzers.
Which also must be infallible or wrong as a total program. Just like
halt deciders, PARTIAL deciders are possible, and effort goes into how
good we can do. It is perhaps more useful to know termination analysis,
as we rarely run a program on just a single input as the Halting Problem
answers so better to spend the effort to attempt termination analysis
where we hope to get a range of inputs that the program can be shown
that it will give an answer.
>
> A termination analyzer is correct if it can process a
> single input that itself has no inputs.
>
Nope. Show your definition.
The one I am using is experessed at:
https://en.wikipedia.org/wiki/Termination_analysis
In computer science, termination analysis is program analysis which
attempts to determine whether the evaluation of a given program halts
for each input. This means to determine whether the input program
computes a total function.
It is closely related to the halting problem, which is to determine
whether a given program halts for a given input and which is
undecidable. The termination analysis is even more difficult than the
halting problem: the termination analysis in the model of Turing
machines as the model of programs implementing computable functions
would have the goal of deciding whether a given Turing machine is a
total Turing machine,
Note, just like A Halt Decider, it needs to decide CORRECTLY (to be
correct) for whatever program is given. Not just for "a" input.
Perhaps you get confused because a lot of work goes on looking at
partial termination analyzers, where the goal is to see for what inputs
can the analyzer PROVE halting for all (or at least a defined set) of
inputs. The field admits it isn't solving the total problem, but accepts
partial answers so the common discussion doesn't talk about a analyzer
being a "correct decider" but being correct for certain inputs, or not
incorrect for others, as it allows the deciders to give an "i can't
tell" answer.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 22:13 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmg8i$3a34p$5@dont-email.me> |
| In reply to | #118232 |
On 5/9/2025 9:40 PM, Keith Thompson wrote:
> olcott <polcott333@gmail.com> writes:
>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>> On 09/05/2025 21:15, olcott wrote:
>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>> We have not begun to get into any of those points.
>>>>>> We are only asking can DDD correctly simulated
>>>>>> by any HHH that can exist ever reach its own
>>>>>> "return" instruction.
>>>>>
>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>> what you're trying to do when you fire up the simulation from
>>>>> inside DDD).
>>>>
>>>> How the Hell did you twist my words to say that?
>>> I haven't touched your words. What I have done is to observe that
>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>> simulator, there is nothing to simulate except a call to a
>>> simulator.
>>> It's recursion without a base case - a rookie error.
>>> HHH cannot successfully complete its task, because it never regains
>>> control after the first recursion. To return, it must abort the
>>> simulation, which means the simulation fails.
>>>
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return;
>>>> }
>>>>
>>>> When 1 or more statements of DDD are correctly
>>>> simulated by HHH then this correctly simulated
>>>> DDD cannot possibly reach its own “return statement”.
>>> On what grounds can you persuade an extraordinarily sceptical
>>> readership that HHH 'correctly simulated' DDD?
>>
>> Any competent C programmer can see that
>> the call from DDD to HHH(DDD) (its own simulator)
>> is equivalent to infinite recursion.
>>
>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>> does nothing else, your code would be equivalent to this:
>>>
>>> void DDD(void) {
>>> DDD();
>>> return;
>>> }
>>>
>>> Then the return statement (which is unnecessary anyway) will never be
>>> reached. In practice, the program will likely crash due to a stack
>>> overflow, unless the compiler implements tail-call optimization, in
>>> which case the program might just run forever -- which also means the
>>> unnecessary return statement will never be reached.
>
> I had not intended to post again, but I feel the need to make
> a clarification.
>
> I acknowledged that the return statement would never be reached
> *given the assumption* that HHH correctly simulates DDD. Given
> that assumption, a call to DDD() should be equivalent to a call
> to HHH(DDD).
>
Yes and then I moved on the next tiny incremental
step of my proof. Correctly simulated less than
an infinite number of instructions does not help
the simulated DDD to reach its "return statement"
final halt state.
> I did not address whether the assumption is valid. I merely
> temporarily accepted it for the sake of discussion, just as I would
> accept that if I were ten feet tall I would bump my head against
> the ceiling in my house.
>
> The discussion I had with olcott did not reach the point of
> discussing *how* HHH could correctly simulate DDD, or whether it
> would even be logically possible for it to do so.
Right this takes a glimmering of understanding of
the x86 language. The x86 language it needed to
get an exactly precise understanding of the control
flow of DDD as directed graph state transition
diagram.
> I also did not
> address any issues of partial simulation, where olcott claims that
> HHH can "accurately simulate" only a few x86 instructions rather
> than simulating its entire execution.
> I did not participate in
> any discussion that would require knowledge of x86 machine or
> assembly code. (I have no doubt that I could learn x86 machine
> and assembly code reasonably well if motivated to do so, but I am
> not so motivated.)
>
> What I acknowledged was barely more than "if HHH correctly simulates
> DDD, then HHH correctly simulates DDD".
No much more than this you acknowledged that
when DDD is correctly simulated by HHH that
the simulated DDD cannot possibly reach its
own "return statement" (final halt state)
This is very important to computer science because
non-termination is entirely measured by the impossibility
of reaching a final halt state.
From all of the we know that when HHH(DDD) reports
on the behavior of its correct simulation of its input
that it can correctly reject this input as not
specifying a sequence of configurations that halts.
> (My understanding from
> posts by others, whom I presume to be sufficiently knowledgeable,
> is that HHH logically cannot accurately simulate DDD.) I would
> prefer that olcott refrain from using my words to support any of
> his arguments beyond the scope of what he and I directly discussed.
>
Can we proceed to the next tiny increment of scope?
When one or more statements of DDD are correctly
simulated by HHH the correctly simulated DDD still
cannot possibly reach its own "return" statement.
This is trivial. When an infinite number of steps
of correct simulation are not enough we can conclude
that less than an infinite number of steps is also
insufficient.
That was the tiny increment of scope. Now I
show why that was important.
It is a fact that when HHH rejects its input
DDD as specifying a non-halting sequence of
configurations on the basis of the behavior
of DDD correctly simulated by HHH, that HHH
is necessary correct.
If you pay 100% complete attention and make
sure to totally ignore mere rhetoric as any
possible correct rebuttal you will find that
every "rebuttal" either commits the strawman
error changing my words and then rebutting the
changed words or simply dodges by attempting
to change the subject.
There has been no actual rebuttal of these
exact words:
It is a fact that when HHH rejects its input
DDD as specifying a non-halting sequence of
configurations on the basis of the behavior
of DDD correctly simulated by HHH, that HHH
is necessary correct.
They always either change the words or change
the subject.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 23:45 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <501aca4b1876b10285d8b629ddc9a0f44245f165@i2pn2.org> |
| In reply to | #118240 |
On 5/9/25 11:13 PM, olcott wrote:
> On 5/9/2025 9:40 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote:
>>>> On 09/05/2025 21:15, olcott wrote:
>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote:
>>>>>> On 09/05/2025 20:46, olcott wrote:
>>>>>>> We have not begun to get into any of those points.
>>>>>>> We are only asking can DDD correctly simulated
>>>>>>> by any HHH that can exist ever reach its own
>>>>>>> "return" instruction.
>>>>>>
>>>>>> DDD can't be correctly simulated by itself (which is effectively
>>>>>> what you're trying to do when you fire up the simulation from
>>>>>> inside DDD).
>>>>>
>>>>> How the Hell did you twist my words to say that?
>>>> I haven't touched your words. What I have done is to observe that
>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a
>>>> simulator, there is nothing to simulate except a call to a
>>>> simulator.
>>>> It's recursion without a base case - a rookie error.
>>>> HHH cannot successfully complete its task, because it never regains
>>>> control after the first recursion. To return, it must abort the
>>>> simulation, which means the simulation fails.
>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> When 1 or more statements of DDD are correctly
>>>>> simulated by HHH then this correctly simulated
>>>>> DDD cannot possibly reach its own “return statement”.
>>>> On what grounds can you persuade an extraordinarily sceptical
>>>> readership that HHH 'correctly simulated' DDD?
>>>
>>> Any competent C programmer can see that
>>> the call from DDD to HHH(DDD) (its own simulator)
>>> is equivalent to infinite recursion.
>>>
>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>> does nothing else, your code would be equivalent to this:
>>>>
>>>> void DDD(void) {
>>>> DDD();
>>>> return;
>>>> }
>>>>
>>>> Then the return statement (which is unnecessary anyway) will never be
>>>> reached. In practice, the program will likely crash due to a stack
>>>> overflow, unless the compiler implements tail-call optimization, in
>>>> which case the program might just run forever -- which also means the
>>>> unnecessary return statement will never be reached.
>>
>> I had not intended to post again, but I feel the need to make
>> a clarification.
>>
>> I acknowledged that the return statement would never be reached
>> *given the assumption* that HHH correctly simulates DDD. Given
>> that assumption, a call to DDD() should be equivalent to a call
>> to HHH(DDD).
>>
>
> Yes and then I moved on the next tiny incremental
> step of my proof. Correctly simulated less than
> an infinite number of instructions does not help
> the simulated DDD to reach its "return statement"
> final halt state.
Sure it does, as "the simulated DDD" has its behavior defined by
UTM(DDD) not the partial simulation done withing HHH(DDD).
Your attempt to redefine the behavior is just your lying by strawman,
>
>> I did not address whether the assumption is valid. I merely
>> temporarily accepted it for the sake of discussion, just as I would
>> accept that if I were ten feet tall I would bump my head against
>> the ceiling in my house.
>>
>> The discussion I had with olcott did not reach the point of
>> discussing *how* HHH could correctly simulate DDD, or whether it
>> would even be logically possible for it to do so.
>
> Right this takes a glimmering of understanding of
> the x86 language. The x86 language it needed to
> get an exactly precise understanding of the control
> flow of DDD as directed graph state transition
> diagram.
Right, and that says that DDD() will halt when correct simulated, as the
x86 langugage doesn't allow stopping that analysis until it reaches a
final state.
That HHH stops its emulation doesn't affect the behavior as defined by
the x86 language.
>
>> I also did not
>> address any issues of partial simulation, where olcott claims that
>> HHH can "accurately simulate" only a few x86 instructions rather
>> than simulating its entire execution.
>
>> I did not participate in
>> any discussion that would require knowledge of x86 machine or
>> assembly code. (I have no doubt that I could learn x86 machine
>> and assembly code reasonably well if motivated to do so, but I am
>> not so motivated.)
>>
>> What I acknowledged was barely more than "if HHH correctly simulates
>> DDD, then HHH correctly simulates DDD".
>
> No much more than this you acknowledged that
> when DDD is correctly simulated by HHH that
> the simulated DDD cannot possibly reach its
> own "return statement" (final halt state)
But it isn't.
No partial simulation is a "correct simulation" as that term is define
to mean the simulation of *ALL* the insturcitons of the program.
Stopping before getting to the end is not going to the end.
>
> This is very important to computer science because
> non-termination is entirely measured by the impossibility
> of reaching a final halt state.
Right, but only under the condition of unbounded running/simulating. Not
reaching the end after only a given finite number of steps is NOT the
definition of non-halting.
>
> From all of the we know that when HHH(DDD) reports
> on the behavior of its correct simulation of its input
> that it can correctly reject this input as not
> specifying a sequence of configurations that halts.
No, as has been shown, it doesn't do a "correct simulation" and thus
your premise is incorrect.
The fact that you have also admitted that neither your HHH or DDD are
actually programs as defined by the field but just "C functions" means
you have admttted that you whole arguement is one giant Caterogry error.
>
>> (My understanding from
>> posts by others, whom I presume to be sufficiently knowledgeable,
>> is that HHH logically cannot accurately simulate DDD.) I would
>> prefer that olcott refrain from using my words to support any of
>> his arguments beyond the scope of what he and I directly discussed.
>>
>
> Can we proceed to the next tiny increment of scope?
>
> When one or more statements of DDD are correctly
> simulated by HHH the correctly simulated DDD still
> cannot possibly reach its own "return" statement.
Which is irrelevent, and each DDD of that set is a different input, as
you can't actually emulate DDD past the call HHH until you have paired
it with the exact HHH it calls, and since each of your HHHs are
different partial emulators, and each of them is given the DDD that has
been complete by being paired with them, every one of your cases is
looking at a different input.
>
> This is trivial. When an infinite number of steps
> of correct simulation are not enough we can conclude
> that less than an infinite number of steps is also
> insufficient.
WHich agian is a different input, so say nothing about the behavior of
the input of the ones that did a finite simulation.
>
> That was the tiny increment of scope. Now I
> show why that was important.
>
Because it is built on a lie and unsound logic.
>
> It is a fact that when HHH rejects its input
> DDD as specifying a non-halting sequence of
> configurations on the basis of the behavior
> of DDD correctly simulated by HHH, that HHH
> is necessary correct.
Nope, it just shows you are a liar that ignores the errors pointed out
in your logic, apparently because either you know you are lying and
don't care, or ate just too stupid to understand the error or to be able
to learn how to do it better.
>
> If you pay 100% complete attention and make
> sure to totally ignore mere rhetoric as any
> possible correct rebuttal you will find that
>
> every "rebuttal" either commits the strawman
> error changing my words and then rebutting the
> changed words or simply dodges by attempting
> to change the subject.
No, if you would look, you would see that all you claims have been shown
to be in error, and you have no actual basis to make your claims.
>
> There has been no actual rebuttal of these
> exact words:
Sure there have been, you are just showing that you are just a
pathological liar that is incapable of understanding the truth.
>
> It is a fact that when HHH rejects its input
> DDD as specifying a non-halting sequence of
> configurations on the basis of the behavior
> of DDD correctly simulated by HHH, that HHH
> is necessary correct.
>
> They always either change the words or change
> the subject.
>
No, the problem is your words are just illogical gobbldy-gook based on
equivocation, contradictions and lies.
Until you actually handle the errors pointed out, it can be assumed that
you have no actual logical basis to make you claims, and just don't care
aobut that fact, as truth doesn't mean anything to you.
[toc] | [prev] | [next] | [standalone]
Page 9 of 32 — ← Prev page 1 … 7 8 [9] 10 11 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web