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 29 of 32 — ← Prev page 1 … 27 28 [29] 30 31 32 Next page →
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 14:55 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnib9$3hcgj$1@dont-email.me> |
| In reply to | #118214 |
Op 10.mei.2025 om 03:50 schreef olcott: > On 5/9/2025 8:32 PM, Richard Heathfield wrote: >> On 10/05/2025 02:29, olcott wrote: >>> On 5/9/2025 8:15 PM, Richard Heathfield wrote: >>>> On 10/05/2025 01:51, olcott wrote: >>>>> On 5/9/2025 7:29 PM, Richard Heathfield wrote: >>>>>> On 10/05/2025 00:02, olcott wrote: >>>>>>> Correctly emulating one or more instructions <is> >>>>>>> the correct emulation of 1 or more instructions >>>>>>> of DD. This is a truism. >>>>>> >>>>>> No, it's not. Correct emulation would entail accurately simulating >>>>>> the whole of DDD's behaviour. >>>>> >>>>> It is stupidly wrong to require the complete >>>>> emulation of a non-terminating input. >>>> >>>> It is touchingly naive to think you can persuade people to accept >>>> incomplete emulation as 'correct'. >>>> >>> >>> If one instruction is emulated correctly >>> then is is dishonest to say that zero >>> instructions were emulated correctly. >> >> Which instruction do you think is emulated correctly? >> > > _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] > > The entire sequence of the first four instructions > of DDD is emulated correctly. This sequence also > includes HHH emulating itself emulating DDD. This > results in a whole other sequence of first three > instructions of DDD being correctly emulated. And, when correctly simulated, it will simulate the abort by the simulated HHH, which then returns to DDD, so that the simulation reaches the end of DDD. But HHH fails to simulate that last part correctly, because it aborts too soon. Therefore, it does not reach the reachable end of the simulation. This makes HHH's simulation incorrect.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 22:32 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <7ae0bd991a1b0b6e509c81203e403abf6d7d98e7@i2pn2.org> |
| In reply to | #118208 |
On 5/9/25 9:29 PM, olcott wrote: > On 5/9/2025 8:15 PM, Richard Heathfield wrote: >> On 10/05/2025 01:51, olcott wrote: >>> On 5/9/2025 7:29 PM, Richard Heathfield wrote: >>>> On 10/05/2025 00:02, olcott wrote: >>>>> Correctly emulating one or more instructions <is> >>>>> the correct emulation of 1 or more instructions >>>>> of DD. This is a truism. >>>> >>>> No, it's not. Correct emulation would entail accurately simulating >>>> the whole of DDD's behaviour. >>> >>> It is stupidly wrong to require the complete >>> emulation of a non-terminating input. >> >> It is touchingly naive to think you can persuade people to accept >> incomplete emulation as 'correct'. >> > > If one instruction is emulated correctly > then is is dishonest to say that zero > instructions were emulated correctly. > But no one is saying that zero instruction were emulated correctly, the claim is that not-all instrucitons were emulated correctly. You are just showing you ignorance of how the logic of qualifiers work. "Correct Emulation" is the correct emulation of *ALL* the instructions. What you are trying to talk about is a correct PARTIAL emulation, which is something different, and doesn't prove your point. Sorry, you are just proving your ignorance.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 22:30 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <333c8b6f6e812540c009a5e10118b00c57adb3c6@i2pn2.org> |
| In reply to | #118203 |
On 5/9/25 8:51 PM, olcott wrote: > On 5/9/2025 7:29 PM, Richard Heathfield wrote: >> On 10/05/2025 00:02, olcott wrote: >>> Correctly emulating one or more instructions <is> >>> the correct emulation of 1 or more instructions >>> of DD. This is a truism. >> >> No, it's not. Correct emulation would entail accurately simulating the >> whole of DDD's behaviour. >> > > It is stupidly wrong to require the complete > emulation of a non-terminating input. > Nope, as that *IS* the definition of a correct emulation of a non-halting input, as the definition of "correcdt emulation" is to exactly reproduce the behavior of that program, so if the program won't halt, neither can the emulation. The key point is that the decider isn't required to do such a correct simulation (except in your brokne theory) but just answer about what such a emulation would do if done. basicaly, one fundamental that you should have seen from your work that it is impossible for one program to be both a correct decider and a correct emulator, and thus the definition of the correct answer can not be based on the correct emulation by itself. That is just invoking a logical contradiction, and your system is basically built on the acceptance of the liar's paradox as a valid statement.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 21:45 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmek5$3a34p$3@dont-email.me> |
| In reply to | #118228 |
On 5/9/2025 9:30 PM, Richard Damon wrote: > On 5/9/25 8:51 PM, olcott wrote: >> On 5/9/2025 7:29 PM, Richard Heathfield wrote: >>> On 10/05/2025 00:02, olcott wrote: >>>> Correctly emulating one or more instructions <is> >>>> the correct emulation of 1 or more instructions >>>> of DD. This is a truism. >>> >>> No, it's not. Correct emulation would entail accurately simulating >>> the whole of DDD's behaviour. >>> >> >> It is stupidly wrong to require the complete >> emulation of a non-terminating input. >> > > Nope, as that *IS* the definition of a correct emulation of a non- > halting input, as the definition of "correcdt emulation" is to exactly > reproduce the behavior of that program, so if the program won't halt, > neither can the emulation. > That a psychotic way to define a simulating termination analyzer. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 23:22 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <a083337ef078c04f5c549b5c3e98b4c65593c957@i2pn2.org> |
| In reply to | #118235 |
On 5/9/25 10:45 PM, olcott wrote: > On 5/9/2025 9:30 PM, Richard Damon wrote: >> On 5/9/25 8:51 PM, olcott wrote: >>> On 5/9/2025 7:29 PM, Richard Heathfield wrote: >>>> On 10/05/2025 00:02, olcott wrote: >>>>> Correctly emulating one or more instructions <is> >>>>> the correct emulation of 1 or more instructions >>>>> of DD. This is a truism. >>>> >>>> No, it's not. Correct emulation would entail accurately simulating >>>> the whole of DDD's behaviour. >>>> >>> >>> It is stupidly wrong to require the complete >>> emulation of a non-terminating input. >>> >> >> Nope, as that *IS* the definition of a correct emulation of a non- >> halting input, as the definition of "correcdt emulation" is to exactly >> reproduce the behavior of that program, so if the program won't halt, >> neither can the emulation. >> > > That a psychotic way to define a simulating termination analyzer. > What, psychotic to define a termination analyZer by the actual definition of a termination analyzer? Where do you get your version of the definition? It seems you just like to invent your own fantasy world which doesn't actually correlate to reality, and then lie about your fantasy being what is real. Sorry, you don't get to redefine the terms, and any attempt just becomes a blantant lie.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-09 11:14 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvkh14$2m36t$7@dont-email.me> |
| In reply to | #118086 |
Op 09.mei.2025 om 04:13 schreef olcott:
> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>> [...]
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> If you are a competent C programmer then you
>>>>> know that DDD correctly simulated by HHH cannot
>>>>> possibly each its own "return" instruction.
>>>> "cannot possibly each"?
>>>> I am a competent C programmer (and I don't believe you can make
>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>> me nothing about what it's supposed to do. Without knowing what
>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>
>>>
>>> For the purpose of this discussion HHH is exactly
>>> what I said it is. It correctly simulates DDD.
>>
>> Does HHH correctly simulate DDD *and do nothing else*?
>>
>> Does HHH correctly simulate *every* function whose address is passed
>> to it? Must the passed function be one that takes no arguments
>> and does not return a value?
>>
>> Can HHH just *call* the function whose address is passed to it?
>> If it's a correct simulation, there should be no difference between
>> calling the function and "correctly simulating" it.
>>
>> My knowledge of C tells me nothing about *how* HHH might simulate
>> DDD.
>>
>
> HHH can only simulate a function that take no arguments
> and has no return value. HHH also simulates the entire
> chain of functions that this function calls. These can
> take arguments or not and have return values or not.
>
> Thus HHH ends up simulating itself (and everything
> that HHH calls) simulating DDD in an infinite
> sequence of recursive emulation until OOM error.
>
>>> We need not know anything else about HHH to
>>> know that DDD correctly simulated by HHH cannot
>>> possibly REACH its own "return" instruction.
>>
>> 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;
>> }
>>
>
> Exactly. None of these people on comp.theory could
> get that even after three years.
>
Only if you forget that your proposed HHH aborts and returns.
The whole discussion is about that proposed HHH, not the hypothetical
HHH that does not abort.
You try to get people to agree with you by using the same name for very
different things.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 11:04 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl91t$2rl0l$16@dont-email.me> |
| In reply to | #118124 |
On 5/9/2025 4:14 AM, Fred. Zwarts wrote:
> Op 09.mei.2025 om 04:13 schreef olcott:
>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> If you are a competent C programmer then you
>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>> possibly each its own "return" instruction.
>>>>> "cannot possibly each"?
>>>>> I am a competent C programmer (and I don't believe you can make
>>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>>> me nothing about what it's supposed to do. Without knowing what
>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>
>>>>
>>>> For the purpose of this discussion HHH is exactly
>>>> what I said it is. It correctly simulates DDD.
>>>
>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>
>>> Does HHH correctly simulate *every* function whose address is passed
>>> to it? Must the passed function be one that takes no arguments
>>> and does not return a value?
>>>
>>> Can HHH just *call* the function whose address is passed to it?
>>> If it's a correct simulation, there should be no difference between
>>> calling the function and "correctly simulating" it.
>>>
>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>> DDD.
>>>
>>
>> HHH can only simulate a function that take no arguments
>> and has no return value. HHH also simulates the entire
>> chain of functions that this function calls. These can
>> take arguments or not and have return values or not.
>>
>> Thus HHH ends up simulating itself (and everything
>> that HHH calls) simulating DDD in an infinite
>> sequence of recursive emulation until OOM error.
>>
>>>> We need not know anything else about HHH to
>>>> know that DDD correctly simulated by HHH cannot
>>>> possibly REACH its own "return" instruction.
>>>
>>> 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;
>>> }
>>>
>>
>> Exactly. None of these people on comp.theory could
>> get that even after three years.
>>
> Only if you forget that your proposed HHH aborts and returns.
*This slight augmentation takes that into account*
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”.
--
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 14:25 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <e0da7c27ea598ccd9529a738c097df1c41cdfe09@i2pn2.org> |
| In reply to | #118154 |
On 5/9/25 12:04 PM, olcott wrote:
> On 5/9/2025 4:14 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 04:13 schreef olcott:
>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> [...]
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> If you are a competent C programmer then you
>>>>>>> know that DDD correctly simulated by HHH cannot
>>>>>>> possibly each its own "return" instruction.
>>>>>> "cannot possibly each"?
>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>> the same claim). I don't know what HHH is. The name "HHH" tells
>>>>>> me nothing about what it's supposed to do. Without knowing what
>>>>>> HHH is, I can't say much about your code (or is it pseudo-code?).
>>>>>>
>>>>>
>>>>> For the purpose of this discussion HHH is exactly
>>>>> what I said it is. It correctly simulates DDD.
>>>>
>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>
>>>> Does HHH correctly simulate *every* function whose address is passed
>>>> to it? Must the passed function be one that takes no arguments
>>>> and does not return a value?
>>>>
>>>> Can HHH just *call* the function whose address is passed to it?
>>>> If it's a correct simulation, there should be no difference between
>>>> calling the function and "correctly simulating" it.
>>>>
>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>> DDD.
>>>>
>>>
>>> HHH can only simulate a function that take no arguments
>>> and has no return value. HHH also simulates the entire
>>> chain of functions that this function calls. These can
>>> take arguments or not and have return values or not.
>>>
>>> Thus HHH ends up simulating itself (and everything
>>> that HHH calls) simulating DDD in an infinite
>>> sequence of recursive emulation until OOM error.
>>>
>>>>> We need not know anything else about HHH to
>>>>> know that DDD correctly simulated by HHH cannot
>>>>> possibly REACH its own "return" instruction.
>>>>
>>>> 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;
>>>> }
>>>>
>>>
>>> Exactly. None of these people on comp.theory could
>>> get that even after three years.
>>>
>> Only if you forget that your proposed HHH aborts and returns.
>
> *This slight augmentation takes that into account*
>
> 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”.
>
>
>
But it can't simulate past the call to HHH, as it doesn't have the code
for that as part of its input.
And partial simulation not reaching a final state is not "Non-Halting".
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 16:41 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvj8ev$25s8h$1@dont-email.me> |
| In reply to | #118050 |
On 5/8/2025 3:01 PM, Richard Heathfield wrote:
> On 08/05/2025 20:42, olcott wrote:
>> On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
>>> Op 08.mei.2025 om 19:00 schreef olcott:>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> The key gist of the issue (no weeds involved)
>>>> is that HHH emulated DD according to the rules
>>>> of the x86 language
>>>>
>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>> *until H correctly determines that*
>>>> *its simulated D would never stop running unless aborted*
>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>> And since H does not correctly determine that its simulated D would
>>> never stop running unless aborted, it is a vacuous statement and
>>> Sipser's agreement does not tell anything.
>>>
>>
>> That is counter factual as any fully qualified
>> C programmer will tell you.
>
> As any competent C programmer can tell you, your simulation is driven by
> assembly language, not C. Furthermore, neither halt7.c nor x86utm.cpp is
> syntactically correct C. Once you fix the syntax errors, that still
> leaves you with the undefined behaviour.
>
> Getting it right is tedious.
>
void DDD()
{
HHH(DDD);
return;
}
What my code actually does is totally irrelevant.
The relevant point is that no function that
unconditionally calls its own simulator can possibly
reach its own final state.
_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]
The exact same thing goes for any function
that calls its own emulator.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-08 23:13 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvja9j$264u5$2@dont-email.me> |
| In reply to | #118052 |
On 08/05/2025 22:41, olcott wrote: > What my code actually does is totally irrelevant. On that, at least, we can agree. -- 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 17:20 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjan5$26heg$1@dont-email.me> |
| In reply to | #118054 |
On 5/8/2025 5:13 PM, Richard Heathfield wrote:
> On 08/05/2025 22:41, olcott wrote:
>> What my code actually does is totally irrelevant.
>
> On that, at least, we can agree.
>
That an HHH can be created that does correctly
determine the halt status of this input is the
whole point.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
--
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 07:25 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <6228e8821a203853e0f9e752b276177146d86d21@i2pn2.org> |
| In reply to | #118055 |
On 5/8/25 6:20 PM, olcott wrote:
> On 5/8/2025 5:13 PM, Richard Heathfield wrote:
>> On 08/05/2025 22:41, olcott wrote:
>>> What my code actually does is totally irrelevant.
>>
>> On that, at least, we can agree.
>>
>
> That an HHH can be created that does correctly
> determine the halt status of this input is the
> whole point.
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
Except that it doesn't, as your "input", being just that function,
doesn't HAVE a halting status. It only gets that once it is paired with
a specific version of HHH.
If that HHH aborts its simulation and returns 0, then it halts, and that
HHH wasn't a correct halt decider.
Since you claim that is what you HHH does, and that would be the DD that
it is given, it is thus clear that when we fix your input to be what you
intend, your claim is false.
That you keep making your "clearly false due to the category error in
it" claim just shows your stupidity.
You just don't understand the basic meaning of the terms you use,
because you decided it would be better to be ignorant, then to know you
are wrong.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:55 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl8hg$2rl0l$12@dont-email.me> |
| In reply to | #118136 |
On 5/9/2025 6:25 AM, Richard Damon wrote:
> On 5/8/25 6:20 PM, olcott wrote:
>> On 5/8/2025 5:13 PM, Richard Heathfield wrote:
>>> On 08/05/2025 22:41, olcott wrote:
>>>> What my code actually does is totally irrelevant.
>>>
>>> On that, at least, we can agree.
>>>
>>
>> That an HHH can be created that does correctly
>> determine the halt status of this input is the
>> whole point.
>>
>> int DD()
>> {
>> int Halt_Status = HHH(DD);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>
> Except that it doesn't, as your "input", being just that function,
> doesn't HAVE a halting status. It only gets that once it is paired with
> a specific version of HHH.
>
> If that HHH aborts its simulation and returns 0, then it halts, and that
> HHH wasn't a correct halt decider.
>
> Since you claim that is what you HHH does, and that would be the DD that
> it is given, it is thus clear that when we fix your input to be what you
> intend, your claim is false.
>
> That you keep making your "clearly false due to the category error in
> it" claim just shows your stupidity.
>
> You just don't understand the basic meaning of the terms you use,
> because you decided it would be better to be ignorant, then to know you
> are wrong.
You try to get away with changing the subject from this:
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”.
--
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 14:29 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <cd4cc99a86b4328bc3c189f14fe1a97758568bb3@i2pn2.org> |
| In reply to | #118150 |
On 5/9/25 11:55 AM, olcott wrote:
> On 5/9/2025 6:25 AM, Richard Damon wrote:
>> On 5/8/25 6:20 PM, olcott wrote:
>>> On 5/8/2025 5:13 PM, Richard Heathfield wrote:
>>>> On 08/05/2025 22:41, olcott wrote:
>>>>> What my code actually does is totally irrelevant.
>>>>
>>>> On that, at least, we can agree.
>>>>
>>>
>>> That an HHH can be created that does correctly
>>> determine the halt status of this input is the
>>> whole point.
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>
>> Except that it doesn't, as your "input", being just that function,
>> doesn't HAVE a halting status. It only gets that once it is paired
>> with a specific version of HHH.
>>
>> If that HHH aborts its simulation and returns 0, then it halts, and
>> that HHH wasn't a correct halt decider.
>>
>> Since you claim that is what you HHH does, and that would be the DD
>> that it is given, it is thus clear that when we fix your input to be
>> what you intend, your claim is false.
>>
>> That you keep making your "clearly false due to the category error in
>> it" claim just shows your stupidity.
>>
>> You just don't understand the basic meaning of the terms you use,
>> because you decided it would be better to be ignorant, then to know
>> you are wrong.
>
> You try to get away with changing the subject from this:
>
> 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”.
>
No, I am giving you the opertunity to correct the errors in your statements.
I guess you are just so stuck in your lies that you have given up any
hope of actually being able to prove anything, and are content with just
leetting the whole world see you are an utter luntic and an ingornat
pathological lying idiot that just doens't care what is actually true.
Your world is just a world of make-believe where you just trust that the
magical Truth Fairy can make you fantasies real.
Maybe we should contact the athorities and see if you can be committed
to a faciltiy as mentally unsound.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-09 10:33 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvkel2$2m36t$1@dont-email.me> |
| In reply to | #118049 |
Op 08.mei.2025 om 21:42 schreef olcott:
> On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
>> Op 08.mei.2025 om 19:00 schreef olcott:
>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>
>>>>>>> Let's take a look.
>>>>>>>
>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>> stop at HHH's first departure from the rules of the C programming
>>>>>>> language (or at least the first departure I spot).
>>>>>>>
>>>>>>> Turn in your songbook if you will to:
>>>>>>>
>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>> {
>>>>>>> u32 size;
>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>> ;
>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>> {
>>>>>>> Output("source[N]: ", source[N]);
>>>>>>> *destination[N] = source[N];
>>>>>>> }
>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>> ((u32*)*destination) [-1]);
>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>> ((u32*)*destination) [-2]);
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> deprecated.
>>>>>
>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>
>>>>> Everybody makes mistakes, and one slip would be all very well, but
>>>>> you make essentially the same mistake --- writing to memory that
>>>>> your program doesn't own --- no fewer than four times in a single
>>>>> function.
>>>>>
>>>>>>> I'll ignore the syntax error (a null statement at file scope is a
>>>>>>> rookie error).
>>>>>>>
>>>>>>> Instead, let's jump straight to this line:
>>>>>>>
>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>
>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>
>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>
>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>> deref it. So now *destination is NULL.
>>>>>>>
>>>>>>> We go on:
>>>>>>>
>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>> {
>>>>>>> Output("source[N]: ", source[N]);
>>>>>>> *destination[N] = source[N];
>>>>>>> }
>>>>>>>
>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>> destination[N] derefs a null pointer.
>>>>>>>
>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>> pity's sake.
>>>>>>>
>>>>>>
>>>>>> If you can't even understand what is essentially
>>>>>> an infinite recursive relationship between two functions
>>>>>> except that one function can terminate the other then
>>>>>> you don't have a clue about the essence of my system.
>>>>>
>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>> dereference a null pointer, you have no business trying to teach
>>>>> anyone anything about C.
>>>>>
>>>>> Your code is the work of a programmer so hideously incompetent that
>>>>> 'programmer' is scarcely a fair word to use.
>>>>>
>>>>> When you publish code like that, to even *think* about denigrating
>>>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>>>
>>>> One problem here is that you don't understand how PO's code works.
>>>> That's to be expected, and PO's response ought to be to explain it
>>>> so that you understand. Instead he goes off on one of his rants, so
>>>> blamewise it's really down to PO.
>>>>
>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>> execution environment. x87utm provides a number of primative calls
>>>> that halt7.c code can make, such as Allocate(), used to allocate a
>>>> block of memory for use in halt7.c. Within halt7.c code calls an
>>>> Allocate() function, and x86utm intercepts that and performs the
>>>> function internally, then jumps the calling code in halt7.c over the
>>>> Allocate call where it continues as normal. The call never goes to
>>>> the implementation of Allocate in halt7.c, so the null pointer
>>>> dereferencing does not actually occur. There are a whole bunch of
>>>> similar x86utm primitive operations that work in the same way.
>>>>
>>>> PO should have said all that, not me, but it seems he's not
>>>> interested in genuine communication.
>>>>
>>>> Mike.
>>>>
>>>>
>>>
>>> Thanks for those details, they are correct.
>>> I try to stay focused on the key essence gist
>>> of the issue and never delve down into the weeds.
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> The key gist of the issue (no weeds involved)
>>> is that HHH emulated DD according to the rules
>>> of the x86 language
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> *until H correctly determines that*
>>> *its simulated D would never stop running unless aborted*
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>
>> And since H does not correctly determine that its simulated D would
>> never stop running unless aborted, it is a vacuous statement and
>> Sipser's agreement does not tell anything.
>>
>
> That is counter factual as any fully qualified
> C programmer will tell you.
All fully qualified C programmers told me that it is not
counter-factual. But I suppose in your language counter-factual means
'not in my dreams'.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> DDD correctly simulated by any HHH cannot
> possibly reach its own simulated "return"
> instruction.
>
Another vacuous statement, as HHH cannot correctly simulate DDD which
includes HHH itself.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:29 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl707$2rl0l$6@dont-email.me> |
| In reply to | #118118 |
On 5/9/2025 3:33 AM, Fred. Zwarts wrote:
> Op 08.mei.2025 om 21:42 schreef olcott:
>> On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
>>> Op 08.mei.2025 om 19:00 schreef olcott:
>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>
>>>>>>>> Let's take a look.
>>>>>>>>
>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>
>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>
>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>> {
>>>>>>>> u32 size;
>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>> ;
>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>> {
>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>> *destination[N] = source[N];
>>>>>>>> }
>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>> };
>>>>>>>>
>>>>>>>
>>>>>>> deprecated.
>>>>>>
>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>
>>>>>> Everybody makes mistakes, and one slip would be all very well, but
>>>>>> you make essentially the same mistake --- writing to memory that
>>>>>> your program doesn't own --- no fewer than four times in a single
>>>>>> function.
>>>>>>
>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>> a rookie error).
>>>>>>>>
>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>
>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>
>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>
>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>
>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>
>>>>>>>> We go on:
>>>>>>>>
>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>> {
>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>> *destination[N] = source[N];
>>>>>>>> }
>>>>>>>>
>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>
>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>> pity's sake.
>>>>>>>>
>>>>>>>
>>>>>>> If you can't even understand what is essentially
>>>>>>> an infinite recursive relationship between two functions
>>>>>>> except that one function can terminate the other then
>>>>>>> you don't have a clue about the essence of my system.
>>>>>>
>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>> anyone anything about C.
>>>>>>
>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>
>>>>>> When you publish code like that, to even *think* about denigrating
>>>>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>>>>
>>>>> One problem here is that you don't understand how PO's code works.
>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>> so blamewise it's really down to PO.
>>>>>
>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>> execution environment. x87utm provides a number of primative calls
>>>>> that halt7.c code can make, such as Allocate(), used to allocate a
>>>>> block of memory for use in halt7.c. Within halt7.c code calls an
>>>>> Allocate() function, and x86utm intercepts that and performs the
>>>>> function internally, then jumps the calling code in halt7.c over
>>>>> the Allocate call where it continues as normal. The call never
>>>>> goes to the implementation of Allocate in halt7.c, so the null
>>>>> pointer dereferencing does not actually occur. There are a whole
>>>>> bunch of similar x86utm primitive operations that work in the same
>>>>> way.
>>>>>
>>>>> PO should have said all that, not me, but it seems he's not
>>>>> interested in genuine communication.
>>>>>
>>>>> Mike.
>>>>>
>>>>>
>>>>
>>>> Thanks for those details, they are correct.
>>>> I try to stay focused on the key essence gist
>>>> of the issue and never delve down into the weeds.
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> The key gist of the issue (no weeds involved)
>>>> is that HHH emulated DD according to the rules
>>>> of the x86 language
>>>>
>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>> *until H correctly determines that*
>>>> *its simulated D would never stop running unless aborted*
>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>> And since H does not correctly determine that its simulated D would
>>> never stop running unless aborted, it is a vacuous statement and
>>> Sipser's agreement does not tell anything.
>>>
>>
>> That is counter factual as any fully qualified
>> C programmer will tell you.
>
> All fully qualified C programmers told me that it is not counter-
> factual. But I suppose in your language counter-factual means 'not in my
> dreams'.
>
>>
>> void DDD()
>> {
>> HHH(DDD);
>> return;
>> }
>>
>> DDD correctly simulated by any HHH cannot
>> possibly reach its own simulated "return"
>> instruction.
>>
>
> Another vacuous statement, as HHH cannot correctly simulate DDD which
> includes HHH itself.
It is stipulated that HHH does simulate itself
simulating DDD. It is also conclusively proven in
code that you cannot understand.
--
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 14:32 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <405ad7ae1dc8cde901cc8333d1b4a0faaa61fd23@i2pn2.org> |
| In reply to | #118142 |
On 5/9/25 11:29 AM, olcott wrote:
> On 5/9/2025 3:33 AM, Fred. Zwarts wrote:
>> Op 08.mei.2025 om 21:42 schreef olcott:
>>> On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
>>>> Op 08.mei.2025 om 19:00 schreef olcott:
>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>>
>>>>>>>>> Let's take a look.
>>>>>>>>>
>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>>
>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>
>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>> {
>>>>>>>>> u32 size;
>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>> ;
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> deprecated.
>>>>>>>
>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>
>>>>>>> Everybody makes mistakes, and one slip would be all very well,
>>>>>>> but you make essentially the same mistake --- writing to memory
>>>>>>> that your program doesn't own --- no fewer than four times in a
>>>>>>> single function.
>>>>>>>
>>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>>> a rookie error).
>>>>>>>>>
>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>
>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>
>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>
>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>>
>>>>>>>>> We go on:
>>>>>>>>>
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>
>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>>> pity's sake.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you can't even understand what is essentially
>>>>>>>> an infinite recursive relationship between two functions
>>>>>>>> except that one function can terminate the other then
>>>>>>>> you don't have a clue about the essence of my system.
>>>>>>>
>>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>>> anyone anything about C.
>>>>>>>
>>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>>
>>>>>>> When you publish code like that, to even *think* about
>>>>>>> denigrating other people's C knowledge is the height of arrogant
>>>>>>> hypocrisy.
>>>>>>>
>>>>>> One problem here is that you don't understand how PO's code works.
>>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>>> so blamewise it's really down to PO.
>>>>>>
>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>>> execution environment. x87utm provides a number of primative
>>>>>> calls that halt7.c code can make, such as Allocate(), used to
>>>>>> allocate a block of memory for use in halt7.c. Within halt7.c
>>>>>> code calls an Allocate() function, and x86utm intercepts that and
>>>>>> performs the function internally, then jumps the calling code in
>>>>>> halt7.c over the Allocate call where it continues as normal. The
>>>>>> call never goes to the implementation of Allocate in halt7.c, so
>>>>>> the null pointer dereferencing does not actually occur. There are
>>>>>> a whole bunch of similar x86utm primitive operations that work in
>>>>>> the same way.
>>>>>>
>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>> interested in genuine communication.
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks for those details, they are correct.
>>>>> I try to stay focused on the key essence gist
>>>>> of the issue and never delve down into the weeds.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> The key gist of the issue (no weeds involved)
>>>>> is that HHH emulated DD according to the rules
>>>>> of the x86 language
>>>>>
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> *until H correctly determines that*
>>>>> *its simulated D would never stop running unless aborted*
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>
>>>> And since H does not correctly determine that its simulated D would
>>>> never stop running unless aborted, it is a vacuous statement and
>>>> Sipser's agreement does not tell anything.
>>>>
>>>
>>> That is counter factual as any fully qualified
>>> C programmer will tell you.
>>
>> All fully qualified C programmers told me that it is not counter-
>> factual. But I suppose in your language counter-factual means 'not in
>> my dreams'.
>>
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> DDD correctly simulated by any HHH cannot
>>> possibly reach its own simulated "return"
>>> instruction.
>>>
>>
>> Another vacuous statement, as HHH cannot correctly simulate DDD which
>> includes HHH itself.
>
>
> It is stipulated that HHH does simulate itself
> simulating DDD. It is also conclusively proven in
> code that you cannot understand.
>
But it can't, so your logic is just based on errors. HHH can not
correctly simulate code that it has been forbidden to look at by the
requirment to be a pure function.
(If you remove that requirment, I have shown an HHH that can do what you
say is impossible)
You need to change your stipulation that the "input" is just the
function "DDD"
All you are doing is proving that your mind is in a fantasy world that
doesn't match reality, and you believe your own lies.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 09:37 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmvom$3d8ic$3@dont-email.me> |
| In reply to | #118142 |
Op 09.mei.2025 om 17:29 schreef olcott:
> On 5/9/2025 3:33 AM, Fred. Zwarts wrote:
>> Op 08.mei.2025 om 21:42 schreef olcott:
>>> On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
>>>> Op 08.mei.2025 om 19:00 schreef olcott:
>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>>
>>>>>>>>> Let's take a look.
>>>>>>>>>
>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>>
>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>
>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>> {
>>>>>>>>> u32 size;
>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>> ;
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> deprecated.
>>>>>>>
>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>
>>>>>>> Everybody makes mistakes, and one slip would be all very well,
>>>>>>> but you make essentially the same mistake --- writing to memory
>>>>>>> that your program doesn't own --- no fewer than four times in a
>>>>>>> single function.
>>>>>>>
>>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>>> a rookie error).
>>>>>>>>>
>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>
>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>
>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>
>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>>
>>>>>>>>> We go on:
>>>>>>>>>
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>
>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>>> pity's sake.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you can't even understand what is essentially
>>>>>>>> an infinite recursive relationship between two functions
>>>>>>>> except that one function can terminate the other then
>>>>>>>> you don't have a clue about the essence of my system.
>>>>>>>
>>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>>> anyone anything about C.
>>>>>>>
>>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>>
>>>>>>> When you publish code like that, to even *think* about
>>>>>>> denigrating other people's C knowledge is the height of arrogant
>>>>>>> hypocrisy.
>>>>>>>
>>>>>> One problem here is that you don't understand how PO's code works.
>>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>>> so blamewise it's really down to PO.
>>>>>>
>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>>> execution environment. x87utm provides a number of primative
>>>>>> calls that halt7.c code can make, such as Allocate(), used to
>>>>>> allocate a block of memory for use in halt7.c. Within halt7.c
>>>>>> code calls an Allocate() function, and x86utm intercepts that and
>>>>>> performs the function internally, then jumps the calling code in
>>>>>> halt7.c over the Allocate call where it continues as normal. The
>>>>>> call never goes to the implementation of Allocate in halt7.c, so
>>>>>> the null pointer dereferencing does not actually occur. There are
>>>>>> a whole bunch of similar x86utm primitive operations that work in
>>>>>> the same way.
>>>>>>
>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>> interested in genuine communication.
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks for those details, they are correct.
>>>>> I try to stay focused on the key essence gist
>>>>> of the issue and never delve down into the weeds.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> The key gist of the issue (no weeds involved)
>>>>> is that HHH emulated DD according to the rules
>>>>> of the x86 language
>>>>>
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> *until H correctly determines that*
>>>>> *its simulated D would never stop running unless aborted*
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>
>>>> And since H does not correctly determine that its simulated D would
>>>> never stop running unless aborted, it is a vacuous statement and
>>>> Sipser's agreement does not tell anything.
>>>>
>>>
>>> That is counter factual as any fully qualified
>>> C programmer will tell you.
>>
>> All fully qualified C programmers told me that it is not counter-
>> factual. But I suppose in your language counter-factual means 'not in
>> my dreams'.
>>
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> DDD correctly simulated by any HHH cannot
>>> possibly reach its own simulated "return"
>>> instruction.
>>>
>>
>> Another vacuous statement, as HHH cannot correctly simulate DDD which
>> includes HHH itself.
>
>
> It is stipulated that HHH does simulate itself
> simulating DDD. It is also conclusively proven in
> code that you cannot understand.
>
Ad hminem attack. No rebuttal. It still stands: vacuous statement. No
correct simulation is possible.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-08 19:35 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <3a92e4a1d264964f8ff5d4de64385a84c7505aaf@i2pn2.org> |
| In reply to | #118045 |
On 5/8/25 1:00 PM, olcott wrote:
> On 5/8/2025 11:14 AM, Mike Terry wrote:
>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>> On 08/05/2025 06:22, olcott wrote:
>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>> HHH according to the rules of the C programming language
>>>>>
>>>>> Let's take a look.
>>>>>
>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>> stop at HHH's first departure from the rules of the C programming
>>>>> language (or at least the first departure I spot).
>>>>>
>>>>> Turn in your songbook if you will to:
>>>>>
>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>> {
>>>>> u32 size;
>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>> ;
>>>>> *destination = (u8*) Allocate(size);
>>>>> for (u32 N = 0; N < size; N++)
>>>>> {
>>>>> Output("source[N]: ", source[N]);
>>>>> *destination[N] = source[N];
>>>>> }
>>>>> ((u32*)*destination)[-1] = size;
>>>>> Output("CopyMachineCode destination[-1]: ", ((u32*)*destination)
>>>>> [-1]);
>>>>> Output("CopyMachineCode destination[-2]: ", ((u32*)*destination)
>>>>> [-2]);
>>>>> };
>>>>>
>>>>
>>>> deprecated.
>>>
>>> It's not just deprecated. It's hopelessly broken.
>>>
>>> Everybody makes mistakes, and one slip would be all very well, but
>>> you make essentially the same mistake --- writing to memory that your
>>> program doesn't own --- no fewer than four times in a single function.
>>>
>>>>> I'll ignore the syntax error (a null statement at file scope is a
>>>>> rookie error).
>>>>>
>>>>> Instead, let's jump straight to this line:
>>>>>
>>>>> *destination = (u8*) Allocate(size);
>>>>>
>>>>> On line 79 of my copy of the code, we find:
>>>>>
>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>
>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>> pointer constant... which is fine as long as you don't try to deref
>>>>> it. So now *destination is NULL.
>>>>>
>>>>> We go on:
>>>>>
>>>>> for (u32 N = 0; N < size; N++)
>>>>> {
>>>>> Output("source[N]: ", source[N]);
>>>>> *destination[N] = source[N];
>>>>> }
>>>>>
>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>> errors, remember). destination is a null pointer, so destination[N]
>>>>> derefs a null pointer.
>>>>>
>>>>> That's a fail. 0/10, D-, go away and write it again. And you /dare/
>>>>> to impugn other people's C knowledge! Crack a book, for pity's sake.
>>>>>
>>>>
>>>> If you can't even understand what is essentially
>>>> an infinite recursive relationship between two functions
>>>> except that one function can terminate the other then
>>>> you don't have a clue about the essence of my system.
>>>
>>> If you can't even understand why it's a stupendously bad idea to
>>> dereference a null pointer, you have no business trying to teach
>>> anyone anything about C.
>>>
>>> Your code is the work of a programmer so hideously incompetent that
>>> 'programmer' is scarcely a fair word to use.
>>>
>>> When you publish code like that, to even *think* about denigrating
>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>
>> One problem here is that you don't understand how PO's code works.
>> That's to be expected, and PO's response ought to be to explain it so
>> that you understand. Instead he goes off on one of his rants, so
>> blamewise it's really down to PO.
>>
>> PO's halt7.c is compiled (it is not linked), then the obj file is fed
>> as input to his x87utm.exe which is a kind of x86 obj code execution
>> environment. x87utm provides a number of primative calls that halt7.c
>> code can make, such as Allocate(), used to allocate a block of memory
>> for use in halt7.c. Within halt7.c code calls an Allocate() function,
>> and x86utm intercepts that and performs the function internally, then
>> jumps the calling code in halt7.c over the Allocate call where it
>> continues as normal. The call never goes to the implementation of
>> Allocate in halt7.c, so the null pointer dereferencing does not
>> actually occur. There are a whole bunch of similar x86utm primitive
>> operations that work in the same way.
>>
>> PO should have said all that, not me, but it seems he's not interested
>> in genuine communication.
>>
>> Mike.
>>
>>
>
> Thanks for those details, they are correct.
> I try to stay focused on the key essence gist
> of the issue and never delve down into the weeds.
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> The key gist of the issue (no weeds involved)
> is that HHH emulated DD according to the rules
> of the x86 language
Excpet, as you have admitted, your DD isn't a program (just a C
funciton), and thus not a proper input for a halt decider, which by
definiton must be a program.
Your C function can't be a program, as you have specifically said that
the function, and only the funciton is the input, and programs must
include in them all their code, so since the code of HHH isn't included
in DD or the input representing it, it isn't a program, and thus not a
proper input
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> *until H correctly determines that*
> *its simulated D would never stop running unless aborted*
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
But that statement implies, as required that H be a halt decider and D
to be a proper input to one, neither of which are satisfied, as you have
admitte
> When HHH(DD) computes the actual mapping from
> its actual input to the actual behavior this
> it specifies it must be according to the rules
> of the x86 language.
But it doesn't, as it doesn't correctly follow the behavior of the x86
language, as that requires HHH to follow the call instruction, which it
can not do as the required (and accepted by your) condition that the
decider is a pure function, which means it can only look at its input,
which does not include the code which the call points to.
>
> int sum(int x, int y) { return x + y; }
> sum is required to compute the mapping
> from its input into its return value
> according to the rules of arithmetic.
Right, and a halt decider is required to (try to) compute the mapping
from the input (which needs to be the representation of a program) to
the results of running that program (since that is the DEFINITION of
Halt Deciding).
>
> This means that requiring sum(3,2) to return
> the sum of 5 + 7 is an incorrect requirement.
Right, just as HHH trying to claim that its answer is based on the fact
that it can't reach the end of its simulation of the input isn't the
correct requirement for HHH.
>
> Like sum(3,2) HHH(DD) is only allowed to report
> on the behavior that its input actually specifies.
>
Right, which is Halting, since that behavior is DEFINED to be the
behavior of running the program the input represents.
Your arguement is just like sum(2, 3) returning 2 + 7.
Sorry, but you are just showing that you are just a pathological liar
that doesn't understand what he is talking about.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 18:48 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjfrn$28g5i$2@dont-email.me> |
| In reply to | #118061 |
On 5/8/2025 6:35 PM, Richard Damon wrote:
> On 5/8/25 1:00 PM, olcott wrote:
>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>> On 08/05/2025 06:22, olcott wrote:
>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>> HHH according to the rules of the C programming language
>>>>>>
>>>>>> Let's take a look.
>>>>>>
>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>> stop at HHH's first departure from the rules of the C programming
>>>>>> language (or at least the first departure I spot).
>>>>>>
>>>>>> Turn in your songbook if you will to:
>>>>>>
>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>> {
>>>>>> u32 size;
>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>> ;
>>>>>> *destination = (u8*) Allocate(size);
>>>>>> for (u32 N = 0; N < size; N++)
>>>>>> {
>>>>>> Output("source[N]: ", source[N]);
>>>>>> *destination[N] = source[N];
>>>>>> }
>>>>>> ((u32*)*destination)[-1] = size;
>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>> ((u32*)*destination) [-1]);
>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>> ((u32*)*destination) [-2]);
>>>>>> };
>>>>>>
>>>>>
>>>>> deprecated.
>>>>
>>>> It's not just deprecated. It's hopelessly broken.
>>>>
>>>> Everybody makes mistakes, and one slip would be all very well, but
>>>> you make essentially the same mistake --- writing to memory that
>>>> your program doesn't own --- no fewer than four times in a single
>>>> function.
>>>>
>>>>>> I'll ignore the syntax error (a null statement at file scope is a
>>>>>> rookie error).
>>>>>>
>>>>>> Instead, let's jump straight to this line:
>>>>>>
>>>>>> *destination = (u8*) Allocate(size);
>>>>>>
>>>>>> On line 79 of my copy of the code, we find:
>>>>>>
>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>
>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>> deref it. So now *destination is NULL.
>>>>>>
>>>>>> We go on:
>>>>>>
>>>>>> for (u32 N = 0; N < size; N++)
>>>>>> {
>>>>>> Output("source[N]: ", source[N]);
>>>>>> *destination[N] = source[N];
>>>>>> }
>>>>>>
>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>> errors, remember). destination is a null pointer, so
>>>>>> destination[N] derefs a null pointer.
>>>>>>
>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>> pity's sake.
>>>>>>
>>>>>
>>>>> If you can't even understand what is essentially
>>>>> an infinite recursive relationship between two functions
>>>>> except that one function can terminate the other then
>>>>> you don't have a clue about the essence of my system.
>>>>
>>>> If you can't even understand why it's a stupendously bad idea to
>>>> dereference a null pointer, you have no business trying to teach
>>>> anyone anything about C.
>>>>
>>>> Your code is the work of a programmer so hideously incompetent that
>>>> 'programmer' is scarcely a fair word to use.
>>>>
>>>> When you publish code like that, to even *think* about denigrating
>>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>>
>>> One problem here is that you don't understand how PO's code works.
>>> That's to be expected, and PO's response ought to be to explain it so
>>> that you understand. Instead he goes off on one of his rants, so
>>> blamewise it's really down to PO.
>>>
>>> PO's halt7.c is compiled (it is not linked), then the obj file is fed
>>> as input to his x87utm.exe which is a kind of x86 obj code execution
>>> environment. x87utm provides a number of primative calls that
>>> halt7.c code can make, such as Allocate(), used to allocate a block
>>> of memory for use in halt7.c. Within halt7.c code calls an
>>> Allocate() function, and x86utm intercepts that and performs the
>>> function internally, then jumps the calling code in halt7.c over the
>>> Allocate call where it continues as normal. The call never goes to
>>> the implementation of Allocate in halt7.c, so the null pointer
>>> dereferencing does not actually occur. There are a whole bunch of
>>> similar x86utm primitive operations that work in the same way.
>>>
>>> PO should have said all that, not me, but it seems he's not
>>> interested in genuine communication.
>>>
>>> Mike.
>>>
>>>
>>
>> Thanks for those details, they are correct.
>> I try to stay focused on the key essence gist
>> of the issue and never delve down into the weeds.
>>
>> int DD()
>> {
>> int Halt_Status = HHH(DD);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> The key gist of the issue (no weeds involved)
>> is that HHH emulated DD according to the rules
>> of the x86 language
>
> Excpet, as you have admitted, your DD isn't a program (just a C
> funciton), and thus not a proper input for a halt decider, which by
> definiton must be a program.
>
> Your C function can't be a program, as you have specifically said that
> the function, and only the funciton is the input, and programs must
> include in them all their code, so since the code of HHH isn't included
> in DD or the input representing it, it isn't a program, and thus not a
> proper input
>
>>
>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>> *until H correctly determines that*
>> *its simulated D would never stop running unless aborted*
>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>
>
> But that statement implies, as required that H be a halt decider and D
> to be a proper input to one, neither of which are satisfied, as you have
> admitte
>
>> When HHH(DD) computes the actual mapping from
>> its actual input to the actual behavior this
>> it specifies it must be according to the rules
>> of the x86 language.
>
> But it doesn't, as it doesn't correctly follow the behavior of the x86
> language, as that requires HHH to follow the call instruction, which it
> can not do as the required (and accepted by your) condition that the
> decider is a pure function, which means it can only look at its input,
> which does not include the code which the call points to.
>
>>
>> int sum(int x, int y) { return x + y; }
>> sum is required to compute the mapping
>> from its input into its return value
>> according to the rules of arithmetic.
>
> Right, and a halt decider is required to (try to) compute the mapping
> from the input (which needs to be the representation of a program) to
> the results of running that program (since that is the DEFINITION of
> Halt Deciding).
>
>>
>> This means that requiring sum(3,2) to return
>> the sum of 5 + 7 is an incorrect requirement.
>
> Right, just as HHH trying to claim that its answer is based on the fact
> that it can't reach the end of its simulation of the input isn't the
> correct requirement for HHH.
>
>>
>> Like sum(3,2) HHH(DD) is only allowed to report
>> on the behavior that its input actually specifies.
>>
>
> Right, which is Halting, since that behavior is DEFINED to be the
> behavior of running the program the input represents.
>
Just like requiring sum(3,2) to report on the sum of 5 + 7
a value other than its input specifies HHH IS NOT ALLOWED
to report on anything other than the behavior that its input
specifies.
Its input specifies that it calls HHH(DD) in recursive
emulation. THIS CANNOT BE IGNORED.
--
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]
Page 29 of 32 — ← Prev page 1 … 27 28 [29] 30 31 32 Next page →
Back to top | Article view | comp.theory
csiph-web