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 27 of 32 — ← Prev page 1 … 25 26 [27] 28 29 … 32 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 07:18 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <ec8feb08f58f456478059d7955c2f4a41fd97d33@i2pn2.org> |
| In reply to | #118112 |
On 5/9/25 1:31 AM, Keith Thompson wrote:
> olcott <polcott333@gmail.com> writes:
>
>> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> 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.
>>> I find that difficult to believe.
>>>
>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>> reached.
>>>>
>>>> It is only there to mark a final halt state.
>>> The closing "}" does that equally well.
>>>
>>>>> In practice, the program will likely crash due to a stack
>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>> which case the program might just run forever -- which also means the
>>>>> unnecessary return statement will never be reached.
>>>>>
>>>>
>>>> Yes you totally have this correctly.
>>>> None of the dozens of comp.theory people could
>>>> ever achieve that level of understanding even
>>>> after three years. That is why I needed to post
>>>> on comp.lang.c.
>>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>>> I never see anything you post in comp.lang.c.
>>>
>>>>> This conclusion relies on my understanding of what you've said about
>>>>> your code, which I consider to be unreliable.
>>>>
>>>> I am not even talking about my code. I am
>>>> talking about the purely hypothetical code
>>>> that you just agreed to.
>>> Do not overestimate what I've agreed to. I must still consider the
>>> possibility that I've been led into a logical trap of some sort,
>>> and that I've missed some subtle flaw.
>>>
>>>>> No doubt you believe that there is some significance to the
>>>>> apparent fact that the return statement will never be reached,
>>>>> assuming that's a correct and relevant conclusion. I don't know
>>>>> what that significance might be.
>>>>
>>>> I will tell you that later after you understand
>>>> some prerequisite ideas first.
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>> So now HHH returns an int result, and you store that result
>>> in a variable named "Halt_Status". You haven't said here what
>>> the meaning of that result might be, and I decline to make any
>>> assumptions based on what you've called it. You could rename
>>> "Halt_Status" to "Foo" and have effectively identical code.
>>> Previously DDD would "correctly simulate" the function whose address
>>> is
>>> passed to it. Now it does that and returns an int result.
>>> If you want to say anything about the meaning of the result returned
>>> by HHH, feel free to say it.
>>>
>>>> The same thing that applied to DDD equally
>>>> applies to the more complicated DD.
>>>>
>>>> When 1 or more instructions of DD are correctly
>>>> simulated by HHH the correctly simulated DD
>>>> cannot possibly get past its call to HHH(DD).
>>>> Thus DD also never reaches its "return" instruction.
>>> Now you're talking about simulating "1 or more instructions"
>>> of DD. I thought that HHH was supposed to "accurately simulate"
>>> the function whose argument is passed to it. Emulating just "1 or
>>> more instructions" is not accurate simulation.
>>> If HHH *fully* simulates the execution of DD, then your code above
>>> exhibits endless recursion,
>>
>> In computer science "halting" is not merely stopping running.
>> "Halting" is reaching a final halt state such as the "return"
>> instruction.
>
> I fail to see either the truth or the relevance of that statement.
>
> We weren't even talking about halting. You did use the C identifier
> "Halt_Status", but I already told you that the spelling of an
> identifier implies nothing about its meaning. I said that you
> hadn't said anything about the meaning of Halt_Status. You declined
> to explain.
>
> You continue to use the term "return instruction". There is no such
> thing in C. There is a return *statement*. Do you have some reason to
> insist on using incorrect terminology?
It is a common issue with him, because he refuses to learn the correct
terminology, as that then becomes too limiting for his equivocations.
Ultimately, he needs to relate his functios to the Turing machines of
the proof, but he requires them to do things that make this impossible.
>
>>> which is not particularly interesting,
>>> and it never reaches the "if (Halt_Status)". (DD calls HHH, which
>>> simulates DD; HHH, in simulating DD, must do the equivalent of
>>> calling HHH, and so on.)
>>
>> It turns out to be very interesting you merely need
>> to grok a few details first.
>
> It's unlikely I'll continue paying attention long enough for it to get
> interesting.
>
>>> You've introduced the idea of simulating only some finite number
>>> of instructions of the simulated functions, but you haven't really
>>> said how that happens (except perhaps in some x86 code that I
>>> don't understand). You've implied that a sufficient knowledge of C
>>> would let someone understand your arguments, but part of what you're
>>> saying seems to depend on x86 assembly and/or machine code (which I'm
>>> not going to learn for the sake of this discussion).
>>> If I would need to understand x86 code to understand your claims,
>>> then
>>> let's just stop here.
>>> [SNIP]
>
> You didn't respond to the above. I'll ask directly.
>
> Would I need to understand x86 code to understand your claims? Yes or no.
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 07:15 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <8903eb12be0c479064db4a0f13dafe89f15bb31e@i2pn2.org> |
| In reply to | #118105 |
On 5/9/25 12:49 AM, olcott wrote:
> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> 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.
>>
>> I find that difficult to believe.
>>
>>>> Then the return statement (which is unnecessary anyway) will never be
>>>> reached.
>>>
>>> It is only there to mark a final halt state.
>>
>> The closing "}" does that equally well.
>>
>>>> In practice, the program will likely crash due to a stack
>>>> overflow, unless the compiler implements tail-call optimization, in
>>>> which case the program might just run forever -- which also means the
>>>> unnecessary return statement will never be reached.
>>>>
>>>
>>> Yes you totally have this correctly.
>>> None of the dozens of comp.theory people could
>>> ever achieve that level of understanding even
>>> after three years. That is why I needed to post
>>> on comp.lang.c.
>>
>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>> I never see anything you post in comp.lang.c.
>>
>>>> This conclusion relies on my understanding of what you've said about
>>>> your code, which I consider to be unreliable.
>>>
>>> I am not even talking about my code. I am
>>> talking about the purely hypothetical code
>>> that you just agreed to.
>>
>> Do not overestimate what I've agreed to. I must still consider the
>> possibility that I've been led into a logical trap of some sort,
>> and that I've missed some subtle flaw.
>>
>>>> No doubt you believe that there is some significance to the
>>>> apparent fact that the return statement will never be reached,
>>>> assuming that's a correct and relevant conclusion. I don't know
>>>> what that significance might be.
>>>
>>> I will tell you that later after you understand
>>> some prerequisite ideas first.
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>
>> So now HHH returns an int result, and you store that result
>> in a variable named "Halt_Status". You haven't said here what
>> the meaning of that result might be, and I decline to make any
>> assumptions based on what you've called it. You could rename
>> "Halt_Status" to "Foo" and have effectively identical code.
>>
>> Previously DDD would "correctly simulate" the function whose address is
>> passed to it. Now it does that and returns an int result.
>>
>> If you want to say anything about the meaning of the result returned
>> by HHH, feel free to say it.
>>
>>> The same thing that applied to DDD equally
>>> applies to the more complicated DD.
>>>
>>> When 1 or more instructions of DD are correctly
>>> simulated by HHH the correctly simulated DD
>>> cannot possibly get past its call to HHH(DD).
>>> Thus DD also never reaches its "return" instruction.
>>
>> Now you're talking about simulating "1 or more instructions"
>> of DD. I thought that HHH was supposed to "accurately simulate"
>> the function whose argument is passed to it. Emulating just "1 or
>> more instructions" is not accurate simulation.
>>
>> If HHH *fully* simulates the execution of DD, then your code above
>> exhibits endless recursion,
>
> In computer science "halting" is not merely stopping running.
> "Halting" is reaching a final halt state such as the "return"
> instruction.
And "Non-Halting" isn't the program being aborted before reaching the
final state, but never reaching a final state even after an unbounded
number of instructions have been run.
>
>> which is not particularly interesting,
>> and it never reaches the "if (Halt_Status)". (DD calls HHH, which
>> simulates DD; HHH, in simulating DD, must do the equivalent of
>> calling HHH, and so on.)
>>
>
> It turns out to be very interesting you merely need
> to grok a few details first.
No, it isn't interesting, because it is based on errors. You need to fix
those errors, at which point you prove a statement you then can't use
for your next step, as it clearly applies to a different input then your
actual decider is given.
>
>> You've introduced the idea of simulating only some finite number
>> of instructions of the simulated functions, but you haven't really
>> said how that happens (except perhaps in some x86 code that I
>> don't understand). You've implied that a sufficient knowledge of C
>> would let someone understand your arguments, but part of what you're
>> saying seems to depend on x86 assembly and/or machine code (which I'm
>> not going to learn for the sake of this discussion).
>>
>> If I would need to understand x86 code to understand your claims, then
>> let's just stop here.
>>
>> [SNIP]
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 18:02 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvm1ih$33907$1@dont-email.me> |
| In reply to | #118100 |
On 5/8/2025 11:11 PM, Keith Thompson wrote:
> olcott <polcott333@gmail.com> writes:
>> 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.
>
> I find that difficult to believe.
>
>>> Then the return statement (which is unnecessary anyway) will never be
>>> reached.
>>
>> It is only there to mark a final halt state.
>
> The closing "}" does that equally well.
>
>>> In practice, the program will likely crash due to a stack
>>> overflow, unless the compiler implements tail-call optimization, in
>>> which case the program might just run forever -- which also means the
>>> unnecessary return statement will never be reached.
>>>
>>
>> Yes you totally have this correctly.
>> None of the dozens of comp.theory people could
>> ever achieve that level of understanding even
>> after three years. That is why I needed to post
>> on comp.lang.c.
>
> I'll note that I've posted in comp.theory, not in comp.lang.c.
> I never see anything you post in comp.lang.c.
>
>>> This conclusion relies on my understanding of what you've said about
>>> your code, which I consider to be unreliable.
>>
>> I am not even talking about my code. I am
>> talking about the purely hypothetical code
>> that you just agreed to.
>
> Do not overestimate what I've agreed to. I must still consider the
> possibility that I've been led into a logical trap of some sort,
> and that I've missed some subtle flaw.
>
>>> No doubt you believe that there is some significance to the
>>> apparent fact that the return statement will never be reached,
>>> assuming that's a correct and relevant conclusion. I don't know
>>> what that significance might be.
>>
>> I will tell you that later after you understand
>> some prerequisite ideas first.
>>
>> int DD()
>> {
>> int Halt_Status = HHH(DD);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>
> So now HHH returns an int result, and you store that result
> in a variable named "Halt_Status". You haven't said here what
> the meaning of that result might be, and I decline to make any
> assumptions based on what you've called it. You could rename
> "Halt_Status" to "Foo" and have effectively identical code.
>
> Previously DDD would "correctly simulate" the function whose address is
> passed to it. Now it does that and returns an int result.
>
> If you want to say anything about the meaning of the result returned
> by HHH, feel free to say it.
>
>> The same thing that applied to DDD equally
>> applies to the more complicated DD.
>>
>> When 1 or more instructions of DD are correctly
>> simulated by HHH the correctly simulated DD
>> cannot possibly get past its call to HHH(DD).
>> Thus DD also never reaches its "return" instruction.
>
> Now you're talking about simulating "1 or more instructions"
> of DD. I thought that HHH was supposed to "accurately simulate"
> the function whose argument is passed to it. Emulating just "1 or
> more instructions" is not accurate simulation.
>
Correctly emulating one or more instructions <is>
the correct emulation of 1 or more instructions
of DD. This is a truism.
When 1 or more instructions of DD are correctly
emulated by HHH the correctly emulated DD cannot
possibly get past its call to HHH(DD).
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 19:36 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <b88ec9161c701a2d7a4dfd1954aaeb221b427e45@i2pn2.org> |
| In reply to | #118192 |
On 5/9/25 7:02 PM, olcott wrote:
> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> 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.
>>
>> I find that difficult to believe.
>>
>>>> Then the return statement (which is unnecessary anyway) will never be
>>>> reached.
>>>
>>> It is only there to mark a final halt state.
>>
>> The closing "}" does that equally well.
>>
>>>> In practice, the program will likely crash due to a stack
>>>> overflow, unless the compiler implements tail-call optimization, in
>>>> which case the program might just run forever -- which also means the
>>>> unnecessary return statement will never be reached.
>>>>
>>>
>>> Yes you totally have this correctly.
>>> None of the dozens of comp.theory people could
>>> ever achieve that level of understanding even
>>> after three years. That is why I needed to post
>>> on comp.lang.c.
>>
>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>> I never see anything you post in comp.lang.c.
>>
>>>> This conclusion relies on my understanding of what you've said about
>>>> your code, which I consider to be unreliable.
>>>
>>> I am not even talking about my code. I am
>>> talking about the purely hypothetical code
>>> that you just agreed to.
>>
>> Do not overestimate what I've agreed to. I must still consider the
>> possibility that I've been led into a logical trap of some sort,
>> and that I've missed some subtle flaw.
>>
>>>> No doubt you believe that there is some significance to the
>>>> apparent fact that the return statement will never be reached,
>>>> assuming that's a correct and relevant conclusion. I don't know
>>>> what that significance might be.
>>>
>>> I will tell you that later after you understand
>>> some prerequisite ideas first.
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>
>> So now HHH returns an int result, and you store that result
>> in a variable named "Halt_Status". You haven't said here what
>> the meaning of that result might be, and I decline to make any
>> assumptions based on what you've called it. You could rename
>> "Halt_Status" to "Foo" and have effectively identical code.
>>
>> Previously DDD would "correctly simulate" the function whose address is
>> passed to it. Now it does that and returns an int result.
>>
>> If you want to say anything about the meaning of the result returned
>> by HHH, feel free to say it.
>>
>>> The same thing that applied to DDD equally
>>> applies to the more complicated DD.
>>>
>>> When 1 or more instructions of DD are correctly
>>> simulated by HHH the correctly simulated DD
>>> cannot possibly get past its call to HHH(DD).
>>> Thus DD also never reaches its "return" instruction.
>>
>> Now you're talking about simulating "1 or more instructions"
>> of DD. I thought that HHH was supposed to "accurately simulate"
>> the function whose argument is passed to it. Emulating just "1 or
>> more instructions" is not accurate simulation.
>>
>
> Correctly emulating one or more instructions <is>
> the correct emulation of 1 or more instructions
> of DD. This is a truism.
No, Correctly Emulating *ALL* of the instructions is the definition of
correct emulation.
or is "e" the correct spelling of the word emulation?
By your definition, a simulating halt decider can just declare ALL
non-trivial programs as non-halting by emulting 1 instruction, and if it
wasn't the terminal instruction, just say non-halting.
Sorry, you are just proving how stupid you are.
>
> When 1 or more instructions of DD are correctly
> emulated by HHH the correctly emulated DD cannot
> possibly get past its call to HHH(DD).
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 18:43 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvm3vr$340f4$1@dont-email.me> |
| In reply to | #118194 |
On 5/9/2025 6:36 PM, Richard Damon wrote:
> On 5/9/25 7:02 PM, olcott wrote:
>> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> 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.
>>>
>>> I find that difficult to believe.
>>>
>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>> reached.
>>>>
>>>> It is only there to mark a final halt state.
>>>
>>> The closing "}" does that equally well.
>>>
>>>>> In practice, the program will likely crash due to a stack
>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>> which case the program might just run forever -- which also means the
>>>>> unnecessary return statement will never be reached.
>>>>>
>>>>
>>>> Yes you totally have this correctly.
>>>> None of the dozens of comp.theory people could
>>>> ever achieve that level of understanding even
>>>> after three years. That is why I needed to post
>>>> on comp.lang.c.
>>>
>>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>>> I never see anything you post in comp.lang.c.
>>>
>>>>> This conclusion relies on my understanding of what you've said about
>>>>> your code, which I consider to be unreliable.
>>>>
>>>> I am not even talking about my code. I am
>>>> talking about the purely hypothetical code
>>>> that you just agreed to.
>>>
>>> Do not overestimate what I've agreed to. I must still consider the
>>> possibility that I've been led into a logical trap of some sort,
>>> and that I've missed some subtle flaw.
>>>
>>>>> No doubt you believe that there is some significance to the
>>>>> apparent fact that the return statement will never be reached,
>>>>> assuming that's a correct and relevant conclusion. I don't know
>>>>> what that significance might be.
>>>>
>>>> I will tell you that later after you understand
>>>> some prerequisite ideas first.
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>
>>> So now HHH returns an int result, and you store that result
>>> in a variable named "Halt_Status". You haven't said here what
>>> the meaning of that result might be, and I decline to make any
>>> assumptions based on what you've called it. You could rename
>>> "Halt_Status" to "Foo" and have effectively identical code.
>>>
>>> Previously DDD would "correctly simulate" the function whose address is
>>> passed to it. Now it does that and returns an int result.
>>>
>>> If you want to say anything about the meaning of the result returned
>>> by HHH, feel free to say it.
>>>
>>>> The same thing that applied to DDD equally
>>>> applies to the more complicated DD.
>>>>
>>>> When 1 or more instructions of DD are correctly
>>>> simulated by HHH the correctly simulated DD
>>>> cannot possibly get past its call to HHH(DD).
>>>> Thus DD also never reaches its "return" instruction.
>>>
>>> Now you're talking about simulating "1 or more instructions"
>>> of DD. I thought that HHH was supposed to "accurately simulate"
>>> the function whose argument is passed to it. Emulating just "1 or
>>> more instructions" is not accurate simulation.
>>>
>>
>> Correctly emulating one or more instructions <is>
>> the correct emulation of 1 or more instructions
>> of DD. This is a truism.
>
> No, Correctly Emulating *ALL* of the instructions is the definition of
> correct emulation.
>
In other words it is waaayyy over your head that
when correctly emulating an infinite number of
instructions of DD is not enough for DD correctly
emulated by HHH to reach its own final halt
state that fewer than infinity might be enough?
--
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 20:37 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <44bfe9bb90212d712a457394821652e18a81cb62@i2pn2.org> |
| In reply to | #118195 |
On 5/9/25 7:43 PM, olcott wrote:
> On 5/9/2025 6:36 PM, Richard Damon wrote:
>> On 5/9/25 7:02 PM, olcott wrote:
>>> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> 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.
>>>>
>>>> I find that difficult to believe.
>>>>
>>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>>> reached.
>>>>>
>>>>> It is only there to mark a final halt state.
>>>>
>>>> The closing "}" does that equally well.
>>>>
>>>>>> In practice, the program will likely crash due to a stack
>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>> which case the program might just run forever -- which also means the
>>>>>> unnecessary return statement will never be reached.
>>>>>>
>>>>>
>>>>> Yes you totally have this correctly.
>>>>> None of the dozens of comp.theory people could
>>>>> ever achieve that level of understanding even
>>>>> after three years. That is why I needed to post
>>>>> on comp.lang.c.
>>>>
>>>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>>>> I never see anything you post in comp.lang.c.
>>>>
>>>>>> This conclusion relies on my understanding of what you've said about
>>>>>> your code, which I consider to be unreliable.
>>>>>
>>>>> I am not even talking about my code. I am
>>>>> talking about the purely hypothetical code
>>>>> that you just agreed to.
>>>>
>>>> Do not overestimate what I've agreed to. I must still consider the
>>>> possibility that I've been led into a logical trap of some sort,
>>>> and that I've missed some subtle flaw.
>>>>
>>>>>> No doubt you believe that there is some significance to the
>>>>>> apparent fact that the return statement will never be reached,
>>>>>> assuming that's a correct and relevant conclusion. I don't know
>>>>>> what that significance might be.
>>>>>
>>>>> I will tell you that later after you understand
>>>>> some prerequisite ideas first.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>
>>>> So now HHH returns an int result, and you store that result
>>>> in a variable named "Halt_Status". You haven't said here what
>>>> the meaning of that result might be, and I decline to make any
>>>> assumptions based on what you've called it. You could rename
>>>> "Halt_Status" to "Foo" and have effectively identical code.
>>>>
>>>> Previously DDD would "correctly simulate" the function whose address is
>>>> passed to it. Now it does that and returns an int result.
>>>>
>>>> If you want to say anything about the meaning of the result returned
>>>> by HHH, feel free to say it.
>>>>
>>>>> The same thing that applied to DDD equally
>>>>> applies to the more complicated DD.
>>>>>
>>>>> When 1 or more instructions of DD are correctly
>>>>> simulated by HHH the correctly simulated DD
>>>>> cannot possibly get past its call to HHH(DD).
>>>>> Thus DD also never reaches its "return" instruction.
>>>>
>>>> Now you're talking about simulating "1 or more instructions"
>>>> of DD. I thought that HHH was supposed to "accurately simulate"
>>>> the function whose argument is passed to it. Emulating just "1 or
>>>> more instructions" is not accurate simulation.
>>>>
>>>
>>> Correctly emulating one or more instructions <is>
>>> the correct emulation of 1 or more instructions
>>> of DD. This is a truism.
>>
>> No, Correctly Emulating *ALL* of the instructions is the definition of
>> correct emulation.
>>
>
> In other words it is waaayyy over your head that
> when correctly emulating an infinite number of
> instructions of DD is not enough for DD correctly
> emulated by HHH to reach its own final halt
> state that fewer than infinity might be enough?
>
>
No, it seems over your head that you are talking about violating your
own stipulations.
How can HHH correctly emulate code that it isn't allowed to see without
breaking its rules?
It seems "rules" and "requirements" are just foreign concepts to you,
because you think you can just imagine anyting you want as possible.
This shows in all your "logica;" arguments, where you just don't
understand the rules of the sytsem you are talking in, and thus end up
just making stupid errors and lying out of reckless stupidity.
Your failure to answer the questions put to you are just the proof that
everyone looking at this will see and understand how you have absolutely
no basis for your claims, because you are just a pathological liar that
doesn't understand that there needs to be actual facts behind claims.
It seems you are just cementing your position in that lake of fire
unless you can somehow break the brainwashing you have done to yourself
and find a way to repent from your lying ways.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 15:28 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvnka6$3hcgj$4@dont-email.me> |
| In reply to | #118195 |
Op 10.mei.2025 om 01:43 schreef olcott:
> On 5/9/2025 6:36 PM, Richard Damon wrote:
>> On 5/9/25 7:02 PM, olcott wrote:
>>> On 5/8/2025 11:11 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> 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.
>>>>
>>>> I find that difficult to believe.
>>>>
>>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>>> reached.
>>>>>
>>>>> It is only there to mark a final halt state.
>>>>
>>>> The closing "}" does that equally well.
>>>>
>>>>>> In practice, the program will likely crash due to a stack
>>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>>> which case the program might just run forever -- which also means the
>>>>>> unnecessary return statement will never be reached.
>>>>>>
>>>>>
>>>>> Yes you totally have this correctly.
>>>>> None of the dozens of comp.theory people could
>>>>> ever achieve that level of understanding even
>>>>> after three years. That is why I needed to post
>>>>> on comp.lang.c.
>>>>
>>>> I'll note that I've posted in comp.theory, not in comp.lang.c.
>>>> I never see anything you post in comp.lang.c.
>>>>
>>>>>> This conclusion relies on my understanding of what you've said about
>>>>>> your code, which I consider to be unreliable.
>>>>>
>>>>> I am not even talking about my code. I am
>>>>> talking about the purely hypothetical code
>>>>> that you just agreed to.
>>>>
>>>> Do not overestimate what I've agreed to. I must still consider the
>>>> possibility that I've been led into a logical trap of some sort,
>>>> and that I've missed some subtle flaw.
>>>>
>>>>>> No doubt you believe that there is some significance to the
>>>>>> apparent fact that the return statement will never be reached,
>>>>>> assuming that's a correct and relevant conclusion. I don't know
>>>>>> what that significance might be.
>>>>>
>>>>> I will tell you that later after you understand
>>>>> some prerequisite ideas first.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>
>>>> So now HHH returns an int result, and you store that result
>>>> in a variable named "Halt_Status". You haven't said here what
>>>> the meaning of that result might be, and I decline to make any
>>>> assumptions based on what you've called it. You could rename
>>>> "Halt_Status" to "Foo" and have effectively identical code.
>>>>
>>>> Previously DDD would "correctly simulate" the function whose address is
>>>> passed to it. Now it does that and returns an int result.
>>>>
>>>> If you want to say anything about the meaning of the result returned
>>>> by HHH, feel free to say it.
>>>>
>>>>> The same thing that applied to DDD equally
>>>>> applies to the more complicated DD.
>>>>>
>>>>> When 1 or more instructions of DD are correctly
>>>>> simulated by HHH the correctly simulated DD
>>>>> cannot possibly get past its call to HHH(DD).
>>>>> Thus DD also never reaches its "return" instruction.
>>>>
>>>> Now you're talking about simulating "1 or more instructions"
>>>> of DD. I thought that HHH was supposed to "accurately simulate"
>>>> the function whose argument is passed to it. Emulating just "1 or
>>>> more instructions" is not accurate simulation.
>>>>
>>>
>>> Correctly emulating one or more instructions <is>
>>> the correct emulation of 1 or more instructions
>>> of DD. This is a truism.
>>
>> No, Correctly Emulating *ALL* of the instructions is the definition of
>> correct emulation.
>>
>
> In other words it is waaayyy over your head that
> when correctly emulating an infinite number of
> instructions of DD is not enough for DD correctly
> emulated by HHH to reach its own final halt
> state that fewer than infinity might be enough?
>
>
I am surprised that a experienced programmer as you claim to be, does
not see that ending an incomplete simulation does not make it correct.
If a calculation does not converge, we cannot just finish the
calculation and claim that all previous steps were correct and therefore
the result obtained so far must be correct as well. The only conclusion
is that this way to do the calculation fails.
So the conclusion must be: a simulation is not the correct way to solve
this problem. Try another tool.
But the proven halting theorem shows that no tool exists to solve all
halting problems.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-10 01:29 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvm6ku$34h6f$2@dont-email.me> |
| In reply to | #118192 |
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. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 20:38 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <f843cd85133177b7ab5e33c46ca7352f4f50e851@i2pn2.org> |
| In reply to | #118198 |
On 5/9/25 8: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. > This is just typical Olcottian behavior, Actual definitons don't matter to him, which is what makes so much of what he says just turn out to be lies when they are interpreted (as they must be) with the actual definitions.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-10 01:48 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvm7ob$34h6g$1@dont-email.me> |
| In reply to | #118200 |
On 10/05/2025 01:38, Richard Damon wrote: > On 5/9/25 8: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. >> > This is just typical Olcottian behavior, Actual definitons > don't matter to him, which is what makes so much of what he says > just turn out to be lies when they are interpreted (as they must > be) with the actual definitions. I have a thought experiment to propose, but... I think a new thread, don't you? -- 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-09 19:54 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvm846$34mm4$3@dont-email.me> |
| In reply to | #118200 |
On 5/9/2025 7:38 PM, Richard Damon wrote: > On 5/9/25 8: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. >> > This is just typical Olcottian behavior, Actual definitons don't > matter to him, which is what makes so much of what he says just turn out > to be lies when they are interpreted (as they must be) with the actual > definitions. _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] Try to show how DDD simulated by HHH according to the rules of the x86 language reaches its own "ret" instruction final state and you already know that you will fail. You dodge this question so that you can remain disagreeable. -- 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 22:25 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <fe53b01c25165237b6537ea7efd9d3b39593352e@i2pn2.org> |
| In reply to | #118204 |
On 5/9/25 8:54 PM, olcott wrote: > On 5/9/2025 7:38 PM, Richard Damon wrote: >> On 5/9/25 8: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. >>> >> This is just typical Olcottian behavior, Actual definitons don't >> matter to him, which is what makes so much of what he says just turn >> out to be lies when they are interpreted (as they must be) with the >> actual definitions. > > _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] > > Try to show how DDD simulated by HHH according to the > rules of the x86 language reaches its own "ret" > instruction final state and you already know that > you will fail. You dodge this question so that > you can remain disagreeable. The problem is that HHH can not emulate this input past the call 000015d2 instruction, as that isn't part of the input, and you need to restrict HHH to be a pure function (and thus can't use memory not derived from the input) or my static variable hack lets us create an HHH that can emulate that input to the return instruciton as I have shown. Sorry, you are just caught in your lies and shown that you can't actually prove what you claim, and you seem to know it at some level as you just refuse to respond to the errors, thus accpeting them as valid.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 21:43 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmeh2$3a34p$2@dont-email.me> |
| In reply to | #118227 |
On 5/9/2025 9:25 PM, Richard Damon wrote: > On 5/9/25 8:54 PM, olcott wrote: >> On 5/9/2025 7:38 PM, Richard Damon wrote: >>> On 5/9/25 8: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. >>>> >>> This is just typical Olcottian behavior, Actual definitons don't >>> matter to him, which is what makes so much of what he says just turn >>> out to be lies when they are interpreted (as they must be) with the >>> actual definitions. >> >> _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] >> >> Try to show how DDD simulated by HHH according to the >> rules of the x86 language reaches its own "ret" >> instruction final state and you already know that >> you will fail. You dodge this question so that >> you can remain disagreeable. > > The problem is that HHH can not emulate this input past the call > 000015d2 instruction, Do I have to repeat this 1000 times !!! HHH is in the same memory space as DDD HHH is in the same memory space as DDD HHH is in the same memory space as DDD HHH is in the same memory space as DDD HHH is in the same memory space as DDD so when DDD calls HHH(DDD) then HHH must emulate itself emulating DDD OR IT IS WRONG -- 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:08 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <d8ddf638f2cdaa304ad9920471f4dd294f5e904b@i2pn2.org> |
| In reply to | #118234 |
On 5/9/25 10:43 PM, olcott wrote: > On 5/9/2025 9:25 PM, Richard Damon wrote: >> On 5/9/25 8:54 PM, olcott wrote: >>> On 5/9/2025 7:38 PM, Richard Damon wrote: >>>> On 5/9/25 8: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. >>>>> >>>> This is just typical Olcottian behavior, Actual definitons don't >>>> matter to him, which is what makes so much of what he says just turn >>>> out to be lies when they are interpreted (as they must be) with the >>>> actual definitions. >>> >>> _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] >>> >>> Try to show how DDD simulated by HHH according to the >>> rules of the x86 language reaches its own "ret" >>> instruction final state and you already know that >>> you will fail. You dodge this question so that >>> you can remain disagreeable. >> >> The problem is that HHH can not emulate this input past the call >> 000015d2 instruction, > > Do I have to repeat this 1000 times !!! > HHH is in the same memory space as DDD > HHH is in the same memory space as DDD > HHH is in the same memory space as DDD > HHH is in the same memory space as DDD > HHH is in the same memory space as DDD > > so when DDD calls HHH(DDD) then HHH must > emulate itself emulating DDD OR IT IS WRONG > > Which is irrelevent since it wasn't part of the input. I guess you are admitting you lied when you said that HHH must be a pure function, and thus my HHH that uses the static local variable is valid, and it CAN correctly emulate EVERY instruciton of the program DDD to the emd. Sorry, you are just checkmating your self and proving that you are just a stupid liar. Your whole logic system seems to be build on lies, equivocations, and the assumption of contradictions.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 19:51 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvm7tl$34mm4$2@dont-email.me> |
| In reply to | #118198 |
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. -- 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-10 02:15 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvm9bv$34h6f$3@dont-email.me> |
| In reply to | #118203 |
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'. -- 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-09 20:29 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvma5d$34vcu$2@dont-email.me> |
| In reply to | #118206 |
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. -- 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-10 02:32 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmabo$34h6g$3@dont-email.me> |
| In reply to | #118208 |
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? -- 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-09 20:50 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmbcm$35i7r$1@dont-email.me> |
| In reply to | #118210 |
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. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 20:48 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmb9d$35ds5$2@dont-email.me> |
| In reply to | #118210 |
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. -- 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 27 of 32 — ← Prev page 1 … 25 26 [27] 28 29 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web