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 11 of 32 — ← Prev page 1 … 9 10 [11] 12 13 … 32 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 23:29 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <d07ca13226ecc137711110fd5cee56f39c2173a8@i2pn2.org> |
| In reply to | #118242 |
On 5/9/25 11:17 PM, olcott wrote:
> On 5/9/2025 10:12 PM, Keith Thompson wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>> On 09/05/2025 03:23, Keith Thompson wrote:
>>>> Richard Damon <richard@damon-family.org> writes:
>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>> We don't need to look at any of my code for me
>>>>>> to totally prove my point. For example when
>>>>>> the above DDD is correctly simulated by HHH
>>>>>> this simulated DDD cannot possibly reach its own
>>>>>> "return" instruction.
>>>>>
>>>>> And thus not correctly simulatd.
>>>>>
>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>> Perhaps I've missed something. I don't see anything in the above
>>>> that
>>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>> is
>>>> equivalent to:
>>>> void DDD()
>>>> {
>>>> DDD();
>>>> return;
>>>> }
>>>> which is a trivial case of infinite recursion. As far as I can
>>>> tell,
>>>> assuming that DDD() is actually called at some point, neither the
>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>> can reach the return statement. Infinite recursion might either
>>>> cause a stack overflow and a probable program crash, or an unending
>>>> loop if the compiler implements tail call optimization.
>>>> I see no contradiction, just an uninteresting case of infinite
>>>> recursion, something that's well understood by anyone with a
>>>> reasonable level of programming experience. (And it has nothing to
>>>> do with the halting problem as far as I can tell, though of course
>>>> olcott has discussed the halting problem elsewhere.)
>>>> Richard, what am I missing?
>>>
>>> Depends on what you've picked up on.
>>>
>>> Do you get that HHH's simulation is a /partial/ simulation? HHH is
>>> free to simulate a few x86 instructions of DDD, and then simply
>>> abandon the simulation and return. Since such a simulation is
>>> obviously NOT equivalent to a direct call to DDD, and above you argue
>>> that it is, I'd say you've missed that.
>>
>> I have not read the vast majority of olcott's post here. For most
>> of the recent discussion I had with him, there was no mention of
>> partial simulation. olcott finally said something about simulating
>> just a few instructions, but at the same time he finally indicated
>> that understanding his arguments would require an understanding of
>> x86 machine and/or assembly language. That's when I bailed out.
>>
>> A "correct simulation", as I understand the term, would require fully
>> simulate the execution of DDD. If DDD never halts, its simulation never
>> halts. olcott seems to think that he's found a way around this that's
>> relevant to the Halting Problem, but I withdrew before getting to that
>> point.
>>
>
> It only need be a correct simulation until HHH sees the
> repeating pattern that would cause itself to never terminate.
Right, but that pattern needs to be based on the fact that HHH is a
program that can abort its simulation, and in fact WILL.
>
> The best selling author of theory of computation textbooks
> agreed that I could quote his agreement with my words.
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its
> input D until H correctly determines that its simulated D
> would never stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
>
Which means that if H(D) can show that UTM(D), where that D is the exact
same input as given to H(D), and thus for the "pathoological program"
still calls the original H(D) since that is what the program at the
input dies, would never halt, it can abort.
Since it H(D) returns 0, then D() will halt, it is impossible for H(D)
to have made that proof since it is not true.
Your problem is your setup just violates the rules of computation theory
as used in the Halting Problem, and you have admitted that you H and D
are actually caterogry errors as they are C functions, which are not
program equivalents, and thus not even the right sort of thing to be
talked about in that context.
Thus, your interpretation is just a lie of gross misinterpretation, and
you whole theory a lie based on equivocation and false and contradictory
premises.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 23:27 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvmkiq$3bds9$1@dont-email.me> |
| In reply to | #118253 |
On 5/9/2025 10:29 PM, Richard Damon wrote:
> On 5/9/25 11:17 PM, olcott wrote:
>> On 5/9/2025 10:12 PM, Keith Thompson wrote:
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>> On 09/05/2025 03:23, Keith Thompson wrote:
>>>>> Richard Damon <richard@damon-family.org> writes:
>>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>>> [...]
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>> We don't need to look at any of my code for me
>>>>>>> to totally prove my point. For example when
>>>>>>> the above DDD is correctly simulated by HHH
>>>>>>> this simulated DDD cannot possibly reach its own
>>>>>>> "return" instruction.
>>>>>>
>>>>>> And thus not correctly simulatd.
>>>>>>
>>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>>> Perhaps I've missed something. I don't see anything in the above
>>>>> that
>>>>> implies that HHH does not correctly simulate DDD. Richard, you've
>>>>> read
>>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>>> is
>>>>> equivalent to:
>>>>> void DDD()
>>>>> {
>>>>> DDD();
>>>>> return;
>>>>> }
>>>>> which is a trivial case of infinite recursion. As far as I can
>>>>> tell,
>>>>> assuming that DDD() is actually called at some point, neither the
>>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>>> can reach the return statement. Infinite recursion might either
>>>>> cause a stack overflow and a probable program crash, or an unending
>>>>> loop if the compiler implements tail call optimization.
>>>>> I see no contradiction, just an uninteresting case of infinite
>>>>> recursion, something that's well understood by anyone with a
>>>>> reasonable level of programming experience. (And it has nothing to
>>>>> do with the halting problem as far as I can tell, though of course
>>>>> olcott has discussed the halting problem elsewhere.)
>>>>> Richard, what am I missing?
>>>>
>>>> Depends on what you've picked up on.
>>>>
>>>> Do you get that HHH's simulation is a /partial/ simulation? HHH is
>>>> free to simulate a few x86 instructions of DDD, and then simply
>>>> abandon the simulation and return. Since such a simulation is
>>>> obviously NOT equivalent to a direct call to DDD, and above you argue
>>>> that it is, I'd say you've missed that.
>>>
>>> I have not read the vast majority of olcott's post here. For most
>>> of the recent discussion I had with him, there was no mention of
>>> partial simulation. olcott finally said something about simulating
>>> just a few instructions, but at the same time he finally indicated
>>> that understanding his arguments would require an understanding of
>>> x86 machine and/or assembly language. That's when I bailed out.
>>>
>>> A "correct simulation", as I understand the term, would require fully
>>> simulate the execution of DDD. If DDD never halts, its simulation never
>>> halts. olcott seems to think that he's found a way around this that's
>>> relevant to the Halting Problem, but I withdrew before getting to that
>>> point.
>>>
>>
>> It only need be a correct simulation until HHH sees the
>> repeating pattern that would cause itself to never terminate.
>
> Right, but that pattern needs to be based on the fact that HHH is a
> program that can abort its simulation, and in fact WILL.
>
>>
>> The best selling author of theory of computation textbooks
>> agreed that I could quote his agreement with my words.
>>
>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>> If simulating halt decider H correctly simulates its
>> input D until H correctly determines that its simulated D
>> would never stop running unless aborted then
>>
>> H can abort its simulation of D and correctly report that D
>> specifies a non-halting sequence of configurations.
>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>
>>
>
*simulated D would never stop running unless aborted*
means determining what would happen if this H never aborted.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 10:44 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn3m8$3dv8d$11@dont-email.me> |
| In reply to | #118265 |
Op 10.mei.2025 om 06:27 schreef olcott:
> On 5/9/2025 10:29 PM, Richard Damon wrote:
>> On 5/9/25 11:17 PM, olcott wrote:
>>> On 5/9/2025 10:12 PM, Keith Thompson wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>> On 09/05/2025 03:23, Keith Thompson wrote:
>>>>>> Richard Damon <richard@damon-family.org> writes:
>>>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>>>> [...]
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>> We don't need to look at any of my code for me
>>>>>>>> to totally prove my point. For example when
>>>>>>>> the above DDD is correctly simulated by HHH
>>>>>>>> this simulated DDD cannot possibly reach its own
>>>>>>>> "return" instruction.
>>>>>>>
>>>>>>> And thus not correctly simulatd.
>>>>>>>
>>>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>>>> Perhaps I've missed something. I don't see anything in the above
>>>>>> that
>>>>>> implies that HHH does not correctly simulate DDD. Richard, you've
>>>>>> read
>>>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>>>> is
>>>>>> equivalent to:
>>>>>> void DDD()
>>>>>> {
>>>>>> DDD();
>>>>>> return;
>>>>>> }
>>>>>> which is a trivial case of infinite recursion. As far as I can
>>>>>> tell,
>>>>>> assuming that DDD() is actually called at some point, neither the
>>>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>>>> can reach the return statement. Infinite recursion might either
>>>>>> cause a stack overflow and a probable program crash, or an unending
>>>>>> loop if the compiler implements tail call optimization.
>>>>>> I see no contradiction, just an uninteresting case of infinite
>>>>>> recursion, something that's well understood by anyone with a
>>>>>> reasonable level of programming experience. (And it has nothing to
>>>>>> do with the halting problem as far as I can tell, though of course
>>>>>> olcott has discussed the halting problem elsewhere.)
>>>>>> Richard, what am I missing?
>>>>>
>>>>> Depends on what you've picked up on.
>>>>>
>>>>> Do you get that HHH's simulation is a /partial/ simulation? HHH is
>>>>> free to simulate a few x86 instructions of DDD, and then simply
>>>>> abandon the simulation and return. Since such a simulation is
>>>>> obviously NOT equivalent to a direct call to DDD, and above you argue
>>>>> that it is, I'd say you've missed that.
>>>>
>>>> I have not read the vast majority of olcott's post here. For most
>>>> of the recent discussion I had with him, there was no mention of
>>>> partial simulation. olcott finally said something about simulating
>>>> just a few instructions, but at the same time he finally indicated
>>>> that understanding his arguments would require an understanding of
>>>> x86 machine and/or assembly language. That's when I bailed out.
>>>>
>>>> A "correct simulation", as I understand the term, would require fully
>>>> simulate the execution of DDD. If DDD never halts, its simulation
>>>> never
>>>> halts. olcott seems to think that he's found a way around this that's
>>>> relevant to the Halting Problem, but I withdrew before getting to that
>>>> point.
>>>>
>>>
>>> It only need be a correct simulation until HHH sees the
>>> repeating pattern that would cause itself to never terminate.
>>
>> Right, but that pattern needs to be based on the fact that HHH is a
>> program that can abort its simulation, and in fact WILL.
>>
>>>
>>> The best selling author of theory of computation textbooks
>>> agreed that I could quote his agreement with my words.
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> If simulating halt decider H correctly simulates its
>>> input D until H correctly determines that its simulated D
>>> would never stop running unless aborted then
>>>
>>> H can abort its simulation of D and correctly report that D
>>> specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>>
>>
>
> *simulated D would never stop running unless aborted*
> means determining what would happen if this H never aborted.
But since D is aborted, this is a vacuous statement.
That is what H should take into account.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 09:15 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <3f89b8cbc1895f3572c2f986bd3ad3c5db4af1ee@i2pn2.org> |
| In reply to | #118265 |
On 5/10/25 12:27 AM, olcott wrote:
> On 5/9/2025 10:29 PM, Richard Damon wrote:
>> On 5/9/25 11:17 PM, olcott wrote:
>>> On 5/9/2025 10:12 PM, Keith Thompson wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>> On 09/05/2025 03:23, Keith Thompson wrote:
>>>>>> Richard Damon <richard@damon-family.org> writes:
>>>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>>>> [...]
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>> We don't need to look at any of my code for me
>>>>>>>> to totally prove my point. For example when
>>>>>>>> the above DDD is correctly simulated by HHH
>>>>>>>> this simulated DDD cannot possibly reach its own
>>>>>>>> "return" instruction.
>>>>>>>
>>>>>>> And thus not correctly simulatd.
>>>>>>>
>>>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>>>> Perhaps I've missed something. I don't see anything in the above
>>>>>> that
>>>>>> implies that HHH does not correctly simulate DDD. Richard, you've
>>>>>> read
>>>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>>>> is
>>>>>> equivalent to:
>>>>>> void DDD()
>>>>>> {
>>>>>> DDD();
>>>>>> return;
>>>>>> }
>>>>>> which is a trivial case of infinite recursion. As far as I can
>>>>>> tell,
>>>>>> assuming that DDD() is actually called at some point, neither the
>>>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>>>> can reach the return statement. Infinite recursion might either
>>>>>> cause a stack overflow and a probable program crash, or an unending
>>>>>> loop if the compiler implements tail call optimization.
>>>>>> I see no contradiction, just an uninteresting case of infinite
>>>>>> recursion, something that's well understood by anyone with a
>>>>>> reasonable level of programming experience. (And it has nothing to
>>>>>> do with the halting problem as far as I can tell, though of course
>>>>>> olcott has discussed the halting problem elsewhere.)
>>>>>> Richard, what am I missing?
>>>>>
>>>>> Depends on what you've picked up on.
>>>>>
>>>>> Do you get that HHH's simulation is a /partial/ simulation? HHH is
>>>>> free to simulate a few x86 instructions of DDD, and then simply
>>>>> abandon the simulation and return. Since such a simulation is
>>>>> obviously NOT equivalent to a direct call to DDD, and above you argue
>>>>> that it is, I'd say you've missed that.
>>>>
>>>> I have not read the vast majority of olcott's post here. For most
>>>> of the recent discussion I had with him, there was no mention of
>>>> partial simulation. olcott finally said something about simulating
>>>> just a few instructions, but at the same time he finally indicated
>>>> that understanding his arguments would require an understanding of
>>>> x86 machine and/or assembly language. That's when I bailed out.
>>>>
>>>> A "correct simulation", as I understand the term, would require fully
>>>> simulate the execution of DDD. If DDD never halts, its simulation
>>>> never
>>>> halts. olcott seems to think that he's found a way around this that's
>>>> relevant to the Halting Problem, but I withdrew before getting to that
>>>> point.
>>>>
>>>
>>> It only need be a correct simulation until HHH sees the
>>> repeating pattern that would cause itself to never terminate.
>>
>> Right, but that pattern needs to be based on the fact that HHH is a
>> program that can abort its simulation, and in fact WILL.
>>
>>>
>>> The best selling author of theory of computation textbooks
>>> agreed that I could quote his agreement with my words.
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> If simulating halt decider H correctly simulates its
>>> input D until H correctly determines that its simulated D
>>> would never stop running unless aborted then
>>>
>>> H can abort its simulation of D and correctly report that D
>>> specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>>
>>
>
> *simulated D would never stop running unless aborted*
> means determining what would happen if this H never aborted.
>
>
>
>
Right, and "simulated D" means the correct simulation of D, which of
coures does not abort.
It also means the actual program D that was given to the original H, and
thus calls that original H, which by your logic does abort its emulation
and returns 0, thus the simulation of this input, if not aborted (a
reqirement this H fails to meet) will reach that point where H aborts
and returns to D and D will halt, thus the condition isn't satisfied.
So, if you change the OUTER H, but not the H in the input (since that
would mean a different input) to not abort.
The fact that you stupidly made your system so you can't do that
operation, means you can't do it and thus can't use that logic.
Fundamentally, the problem is your input is not a "program" as you are
trying to exclude some of its code as part of the input, so your whole
arguement fails on a big category error.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-10 15:23 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <d2a7e4c4bccbac9dd4bd8dbca6c0dff98a747948@i2pn2.org> |
| In reply to | #118265 |
On 5/10/25 12:27 AM, olcott wrote:
> On 5/9/2025 10:29 PM, Richard Damon wrote:
>> On 5/9/25 11:17 PM, olcott wrote:
>>> On 5/9/2025 10:12 PM, Keith Thompson wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>> On 09/05/2025 03:23, Keith Thompson wrote:
>>>>>> Richard Damon <richard@damon-family.org> writes:
>>>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>>>> [...]
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> HHH(DDD);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>> We don't need to look at any of my code for me
>>>>>>>> to totally prove my point. For example when
>>>>>>>> the above DDD is correctly simulated by HHH
>>>>>>>> this simulated DDD cannot possibly reach its own
>>>>>>>> "return" instruction.
>>>>>>>
>>>>>>> And thus not correctly simulatd.
>>>>>>>
>>>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>>>> Perhaps I've missed something. I don't see anything in the above
>>>>>> that
>>>>>> implies that HHH does not correctly simulate DDD. Richard, you've
>>>>>> read
>>>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>>>> is
>>>>>> equivalent to:
>>>>>> void DDD()
>>>>>> {
>>>>>> DDD();
>>>>>> return;
>>>>>> }
>>>>>> which is a trivial case of infinite recursion. As far as I can
>>>>>> tell,
>>>>>> assuming that DDD() is actually called at some point, neither the
>>>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>>>> can reach the return statement. Infinite recursion might either
>>>>>> cause a stack overflow and a probable program crash, or an unending
>>>>>> loop if the compiler implements tail call optimization.
>>>>>> I see no contradiction, just an uninteresting case of infinite
>>>>>> recursion, something that's well understood by anyone with a
>>>>>> reasonable level of programming experience. (And it has nothing to
>>>>>> do with the halting problem as far as I can tell, though of course
>>>>>> olcott has discussed the halting problem elsewhere.)
>>>>>> Richard, what am I missing?
>>>>>
>>>>> Depends on what you've picked up on.
>>>>>
>>>>> Do you get that HHH's simulation is a /partial/ simulation? HHH is
>>>>> free to simulate a few x86 instructions of DDD, and then simply
>>>>> abandon the simulation and return. Since such a simulation is
>>>>> obviously NOT equivalent to a direct call to DDD, and above you argue
>>>>> that it is, I'd say you've missed that.
>>>>
>>>> I have not read the vast majority of olcott's post here. For most
>>>> of the recent discussion I had with him, there was no mention of
>>>> partial simulation. olcott finally said something about simulating
>>>> just a few instructions, but at the same time he finally indicated
>>>> that understanding his arguments would require an understanding of
>>>> x86 machine and/or assembly language. That's when I bailed out.
>>>>
>>>> A "correct simulation", as I understand the term, would require fully
>>>> simulate the execution of DDD. If DDD never halts, its simulation
>>>> never
>>>> halts. olcott seems to think that he's found a way around this that's
>>>> relevant to the Halting Problem, but I withdrew before getting to that
>>>> point.
>>>>
>>>
>>> It only need be a correct simulation until HHH sees the
>>> repeating pattern that would cause itself to never terminate.
>>
>> Right, but that pattern needs to be based on the fact that HHH is a
>> program that can abort its simulation, and in fact WILL.
>>
>>>
>>> The best selling author of theory of computation textbooks
>>> agreed that I could quote his agreement with my words.
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> If simulating halt decider H correctly simulates its
>>> input D until H correctly determines that its simulated D
>>> would never stop running unless aborted then
>>>
>>> H can abort its simulation of D and correctly report that D
>>> specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>>
>>
>
> *simulated D would never stop running unless aborted*
> means determining what would happen if this H never aborted.
>
But H is a fixed definition.
It isn't talking about changing the defintion of H, but of correctly
simulating the input to H.
I guess you don't understand that fundamental nature of a program.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 10:42 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn3i7$3dv8d$10@dont-email.me> |
| In reply to | #118242 |
Op 10.mei.2025 om 05:17 schreef olcott:
> On 5/9/2025 10:12 PM, Keith Thompson wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>> On 09/05/2025 03:23, Keith Thompson wrote:
>>>> Richard Damon <richard@damon-family.org> writes:
>>>>> On 5/8/25 7:53 PM, olcott wrote:
>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>> HHH(DDD);
>>>>>> return;
>>>>>> }
>>>>>> We don't need to look at any of my code for me
>>>>>> to totally prove my point. For example when
>>>>>> the above DDD is correctly simulated by HHH
>>>>>> this simulated DDD cannot possibly reach its own
>>>>>> "return" instruction.
>>>>>
>>>>> And thus not correctly simulatd.
>>>>>
>>>>> Sorry, there is no "OS Exemption" to correct simulaiton;.
>>>> Perhaps I've missed something. I don't see anything in the above
>>>> that
>>>> implies that HHH does not correctly simulate DDD. Richard, you've read
>>>> far more of olcott's posts than I have, so perhaps you can clarify.
>>>> If we assume that HHH correctly simulates DDD, then the above code
>>>> is
>>>> equivalent to:
>>>> void DDD()
>>>> {
>>>> DDD();
>>>> return;
>>>> }
>>>> which is a trivial case of infinite recursion. As far as I can
>>>> tell,
>>>> assuming that DDD() is actually called at some point, neither the
>>>> outer execution of DDD nor the nested (simulated) execution of DDD
>>>> can reach the return statement. Infinite recursion might either
>>>> cause a stack overflow and a probable program crash, or an unending
>>>> loop if the compiler implements tail call optimization.
>>>> I see no contradiction, just an uninteresting case of infinite
>>>> recursion, something that's well understood by anyone with a
>>>> reasonable level of programming experience. (And it has nothing to
>>>> do with the halting problem as far as I can tell, though of course
>>>> olcott has discussed the halting problem elsewhere.)
>>>> Richard, what am I missing?
>>>
>>> Depends on what you've picked up on.
>>>
>>> Do you get that HHH's simulation is a /partial/ simulation? HHH is
>>> free to simulate a few x86 instructions of DDD, and then simply
>>> abandon the simulation and return. Since such a simulation is
>>> obviously NOT equivalent to a direct call to DDD, and above you argue
>>> that it is, I'd say you've missed that.
>>
>> I have not read the vast majority of olcott's post here. For most
>> of the recent discussion I had with him, there was no mention of
>> partial simulation. olcott finally said something about simulating
>> just a few instructions, but at the same time he finally indicated
>> that understanding his arguments would require an understanding of
>> x86 machine and/or assembly language. That's when I bailed out.
>>
>> A "correct simulation", as I understand the term, would require fully
>> simulate the execution of DDD. If DDD never halts, its simulation never
>> halts. olcott seems to think that he's found a way around this that's
>> relevant to the Halting Problem, but I withdrew before getting to that
>> point.
>>
>
> It only need be a correct simulation until HHH sees the
> repeating pattern that would cause itself to never terminate.
Which it cannot see, because it is not there. It misses the part in the
input that aborts and halts.
It seems very difficult for you to accept verifiable facts when they
disturb your dreams.
>
> The best selling author of theory of computation textbooks
> agreed that I could quote his agreement with my words.
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its
> input D until H correctly determines that its simulated D
> would never stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
>
Why repaying this when it was explained that Sipser agreed to a vacuous
statement, as there is no correct simulation.
It seems very difficult for you to accept verifiable facts when they
disturb your dreams.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-09 05:35 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvk0na$2i1b0$1@dont-email.me> |
| In reply to | #118067 |
On 09/05/2025 00:53, olcott wrote: > On 5/8/2025 6:45 PM, Keith Thompson wrote: >> olcott <polcott333@gmail.com> writes: >>> On 5/8/2025 5:26 PM, Keith Thompson wrote: >> [...] >>>> I am more nearly an expert on C than on the Halting Problem. >>>> Watching olcott base his arguments on C *and getting C so badly >>>> wrong* leads me to think that he is largely ignorant of C >>>> (which is >>>> fine, most people are) and is unwilling to admit it. >>>> Watching the >>>> reactions of actual experts to his mathematical arguments >>>> leads me >>>> to the same conclusion about his knowledge of the relevant >>>> fields >>>> of mathematics. >>>> >>> >>> If Halt7.c is not compiled with the Microsoft >>> compiler then it will not produce the required >>> object file type. >>> >>> The rest of the system has compiled under >>> Linux. I haven't tried this in a few years. >> >> [...] >> >> So you normally compile your code using the 2017 version of >> Microsoft >> Visual Studio. >> >> I have no particular problem with that, but your failure to >> correct >> a number of C errors in your code is odd. > > As I already proved Microsoft reported no such errors. That's tantamount to a claim of a bug in your compiler. Conforming C compilers are /required/ to report syntax errors. >> I've pointed out several >> syntax errors and constraint violations; at least the syntax >> errors >> would be trivial to fix (even if your compiler is lax enough to >> fail to diagnose them). Richard Heathfield has pointed out code >> that dereferences a null pointer. >> > > Mike corrected Richard on this. No, Mike just pointed out that you don't call all the functions you posted. The fact remains that your code is broken. > Those are stub functions intercepted > by x86utm the operating system. They are nevertheless evidence of your poor grasp of the language. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 22:18 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87jz6qbbvr.fsf@nosuchdomain.example.com> |
| In reply to | #118103 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 09/05/2025 00:53, olcott wrote:
>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
[...]
>>> I have no particular problem with that, but your failure to correct
>>> a number of C errors in your code is odd.
>> As I already proved Microsoft reported no such errors.
>
> That's tantamount to a claim of a bug in your compiler. Conforming C
> compilers are /required/ to report syntax errors.
Meh. Most C compilers, certainly including gcc, clang, and
Microsoft's C compiler, are not conforming by default. In fact,
I don't know of any that are.
I consider this unfortunate, but it means that if you want a
conforming C compiler, you need to use apply additional options
("-std=cNN -pedantic" for gcc and clang, and something else for
Microsoft's compiler).
The problem, of course, is that different C compilers in their default
modes are lax in different ways, so an error that compiler X ignores by
default might become fatal when you use compiler Y.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-09 06:41 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvk4j4$2i1b1$3@dont-email.me> |
| In reply to | #118110 |
On 09/05/2025 06:18, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 09/05/2025 00:53, olcott wrote:
>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
> [...]
>>>> I have no particular problem with that, but your failure to correct
>>>> a number of C errors in your code is odd.
>>> As I already proved Microsoft reported no such errors.
>>
>> That's tantamount to a claim of a bug in your compiler. Conforming C
>> compilers are /required/ to report syntax errors.
>
> Meh. Most C compilers, certainly including gcc, clang, and
> Microsoft's C compiler, are not conforming by default. In fact,
> I don't know of any that are.
Indeed, although it's normally quite easy to kick them into
conforming mode if such a mode exists.
But when Mr Olcott directs the discussion towards the C language
(and even cross-posts to comp.lang.c from time to time), it is
reasonable to assume that he is talking about the C language. The
C language is defined by an international standard, not by a set
of command line switches.
> I consider this unfortunate, but it means that if you want a
> conforming C compiler, you need to use apply additional options
> ("-std=cNN -pedantic" for gcc and clang, and something else for
> Microsoft's compiler).
It's been a very long time since I used a Microsoft compiler, but
-W4 is worth a shot.
> The problem, of course, is that different C compilers in their default
> modes are lax in different ways, so an error that compiler X ignores by
> default might become fatal when you use compiler Y.
Yes, which is fine as long as the compiler X user restricts
himself to compiler X, but which can embarrass him if he starts
making general claims about the language itself.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-09 10:39 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvkev4$2m36t$2@dont-email.me> |
| In reply to | #118067 |
Op 09.mei.2025 om 01:53 schreef olcott:
> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>> [...]
>>>> I am more nearly an expert on C than on the Halting Problem.
>>>> Watching olcott base his arguments on C *and getting C so badly
>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>> reactions of actual experts to his mathematical arguments leads me
>>>> to the same conclusion about his knowledge of the relevant fields
>>>> of mathematics.
>>>>
>>>
>>> If Halt7.c is not compiled with the Microsoft
>>> compiler then it will not produce the required
>>> object file type.
>>>
>>> The rest of the system has compiled under
>>> Linux. I haven't tried this in a few years.
>>
>> [...]
>>
>> So you normally compile your code using the 2017 version of Microsoft
>> Visual Studio.
>>
>> I have no particular problem with that, but your failure to correct
>> a number of C errors in your code is odd.
>
> As I already proved Microsoft reported no such errors.
>
>> I've pointed out several
>> syntax errors and constraint violations; at least the syntax errors
>> would be trivial to fix (even if your compiler is lax enough to
>> fail to diagnose them). Richard Heathfield has pointed out code
>> that dereferences a null pointer.
>>
>
> Mike corrected Richard on this.
> Those are stub functions intercepted
> by x86utm the operating system.
>
>> You are using C, a language in which you appear to have little
>> apparent expertise or willingness to learn, to demonstrate claims
>> that, if true, would overturn ideas that have been generally accepted
>> for decades. Can you understand why I might decide that analyzing
>> your claims is not worth my time?
>>
>
> I learned C back when K & R was the standard.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> We don't need to look at any of my code for me
> to totally prove my point. For example when
> the above DDD is correctly simulated by HHH
> this simulated DDD cannot possibly reach its own
> "return" instruction.
>
>
A vacuous statement, because HHH cannot correctly simulate DDD, which
includes HHH itself.
A vacuous statement does not prove anything.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:33 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl787$2rl0l$7@dont-email.me> |
| In reply to | #118119 |
On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
> Op 09.mei.2025 om 01:53 schreef olcott:
>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>> [...]
>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>> of mathematics.
>>>>>
>>>>
>>>> If Halt7.c is not compiled with the Microsoft
>>>> compiler then it will not produce the required
>>>> object file type.
>>>>
>>>> The rest of the system has compiled under
>>>> Linux. I haven't tried this in a few years.
>>>
>>> [...]
>>>
>>> So you normally compile your code using the 2017 version of Microsoft
>>> Visual Studio.
>>>
>>> I have no particular problem with that, but your failure to correct
>>> a number of C errors in your code is odd.
>>
>> As I already proved Microsoft reported no such errors.
>>
>>> I've pointed out several
>>> syntax errors and constraint violations; at least the syntax errors
>>> would be trivial to fix (even if your compiler is lax enough to
>>> fail to diagnose them). Richard Heathfield has pointed out code
>>> that dereferences a null pointer.
>>>
>>
>> Mike corrected Richard on this.
>> Those are stub functions intercepted
>> by x86utm the operating system.
>>
>>> You are using C, a language in which you appear to have little
>>> apparent expertise or willingness to learn, to demonstrate claims
>>> that, if true, would overturn ideas that have been generally accepted
>>> for decades. Can you understand why I might decide that analyzing
>>> your claims is not worth my time?
>>>
>>
>> I learned C back when K & R was the standard.
>>
>> void DDD()
>> {
>> HHH(DDD);
>> return;
>> }
>>
>> We don't need to look at any of my code for me
>> to totally prove my point. For example when
>> the above DDD is correctly simulated by HHH
>> this simulated DDD cannot possibly reach its own
>> "return" instruction.
>>
>>
>
> A vacuous statement, because HHH cannot correctly simulate DDD, which
> includes HHH itself.
> A vacuous statement does not prove anything.
You are saying that the smartest genius (not me)
in the universe cannot possibly create an HHH
that simulates itself simulating DDD?
What is the evidence for this wild-eyed claim?
--
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 | joes <noreply@example.org> |
|---|---|
| Date | 2025-05-09 15:42 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <be8d55605630d1186883b581a6e7fe75d036da04@i2pn2.org> |
| In reply to | #118143 |
Am Fri, 09 May 2025 10:33:27 -0500 schrieb olcott: > On 5/9/2025 3:39 AM, Fred. Zwarts wrote: >> Op 09.mei.2025 om 01:53 schreef olcott: >>> On 5/8/2025 6:45 PM, Keith Thompson wrote: >>>> You are using C, a language in which you appear to have little >>>> apparent expertise or willingness to learn, to demonstrate claims >>>> that, if true, would overturn ideas that have been generally accepted >>>> for decades. Can you understand why I might decide that analyzing >>>> your claims is not worth my time? >>>> >>> I learned C back when K & R was the standard. >>> We don't need to look at any of my code for me to totally prove my >>> point. For example when the above DDD is correctly simulated by HHH >>> this simulated DDD cannot possibly reach its own "return" instruction. >>> >> A vacuous statement, because HHH cannot correctly simulate DDD, which >> includes HHH itself. >> A vacuous statement does not prove anything. > > You are saying that the smartest genius (not me) > in the universe cannot possibly create an HHH that simulates itself > simulating DDD? > What is the evidence for this wild-eyed claim? Because it runs forever, and a decider needs to return. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:53 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl8e2$2rl0l$11@dont-email.me> |
| In reply to | #118146 |
On 5/9/2025 10:42 AM, joes wrote:
> Am Fri, 09 May 2025 10:33:27 -0500 schrieb olcott:
>> On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
>>> Op 09.mei.2025 om 01:53 schreef olcott:
>>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>
>>>>> You are using C, a language in which you appear to have little
>>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>>> that, if true, would overturn ideas that have been generally accepted
>>>>> for decades. Can you understand why I might decide that analyzing
>>>>> your claims is not worth my time?
>>>>>
>>>> I learned C back when K & R was the standard.
>>>> We don't need to look at any of my code for me to totally prove my
>>>> point. For example when the above DDD is correctly simulated by HHH
>>>> this simulated DDD cannot possibly reach its own "return" instruction.
>>>>
>>> A vacuous statement, because HHH cannot correctly simulate DDD, which
>>> includes HHH itself.
>>> A vacuous statement does not prove anything.
>>
>> You are saying that the smartest genius (not me)
>> in the universe cannot possibly create an HHH that simulates itself
>> simulating DDD?
>> What is the evidence for this wild-eyed claim?
> Because it runs forever, and a decider needs to return.
>
In other words you are trying to change the subject
from this:
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 14:06 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <0263d9db087312cbf6f0737e3cbb54688b4a3c1c@i2pn2.org> |
| In reply to | #118149 |
On 5/9/25 11:53 AM, olcott wrote:
> On 5/9/2025 10:42 AM, joes wrote:
>> Am Fri, 09 May 2025 10:33:27 -0500 schrieb olcott:
>>> On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
>>>> Op 09.mei.2025 om 01:53 schreef olcott:
>>>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>
>>>>>> You are using C, a language in which you appear to have little
>>>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>>>> that, if true, would overturn ideas that have been generally accepted
>>>>>> for decades. Can you understand why I might decide that analyzing
>>>>>> your claims is not worth my time?
>>>>>>
>>>>> I learned C back when K & R was the standard.
>>>>> We don't need to look at any of my code for me to totally prove my
>>>>> point. For example when the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own "return" instruction.
>>>>>
>>>> A vacuous statement, because HHH cannot correctly simulate DDD, which
>>>> includes HHH itself.
>>>> A vacuous statement does not prove anything.
>>>
>>> You are saying that the smartest genius (not me)
>>> in the universe cannot possibly create an HHH that simulates itself
>>> simulating DDD?
>>> What is the evidence for this wild-eyed claim?
>> Because it runs forever, and a decider needs to return.
>>
>
> In other words you are trying to change the subject
> from this:
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> When 1 or more statements of DDD are correctly
> simulated by HHH then this correctly simulated
> DDD cannot possibly reach its own “return statement”.
>
No, because your statements are just nonsense lies.
The input you describe is just NOT A PROGRAM, and thus doesn't HAVE a
Halting Property.
Your Emulator just fails to be a correct emulator because it isn't a
pure function of its input, and it stops before it gets to the end.
Note doing only 1 or more steps is NOT a "Correct Simulation" if it
stops before reaching the final state.
Just like a polygon of n sides is not a circle.
Sorry, you are just proving that you are nothing but an ignorant
pathological liar that doesn't care about what is true.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 13:58 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <85f878d29f82159e61a687232ccf7f64046116a1@i2pn2.org> |
| In reply to | #118143 |
On 5/9/25 11:33 AM, olcott wrote:
> On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 01:53 schreef olcott:
>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>>> [...]
>>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>>> of mathematics.
>>>>>>
>>>>>
>>>>> If Halt7.c is not compiled with the Microsoft
>>>>> compiler then it will not produce the required
>>>>> object file type.
>>>>>
>>>>> The rest of the system has compiled under
>>>>> Linux. I haven't tried this in a few years.
>>>>
>>>> [...]
>>>>
>>>> So you normally compile your code using the 2017 version of Microsoft
>>>> Visual Studio.
>>>>
>>>> I have no particular problem with that, but your failure to correct
>>>> a number of C errors in your code is odd.
>>>
>>> As I already proved Microsoft reported no such errors.
>>>
>>>> I've pointed out several
>>>> syntax errors and constraint violations; at least the syntax errors
>>>> would be trivial to fix (even if your compiler is lax enough to
>>>> fail to diagnose them). Richard Heathfield has pointed out code
>>>> that dereferences a null pointer.
>>>>
>>>
>>> Mike corrected Richard on this.
>>> Those are stub functions intercepted
>>> by x86utm the operating system.
>>>
>>>> You are using C, a language in which you appear to have little
>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>> that, if true, would overturn ideas that have been generally accepted
>>>> for decades. Can you understand why I might decide that analyzing
>>>> your claims is not worth my time?
>>>>
>>>
>>> I learned C back when K & R was the standard.
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> We don't need to look at any of my code for me
>>> to totally prove my point. For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>>>
>>>
>>
>> A vacuous statement, because HHH cannot correctly simulate DDD, which
>> includes HHH itself.
>> A vacuous statement does not prove anything.
>
> You are saying that the smartest genius (not me)
> in the universe cannot possibly create an HHH
> that simulates itself simulating DDD?
>
> What is the evidence for this wild-eyed claim?
>
Not that can be a pure function and emulate the input that you are
giving it, as your setup commits a category error.
Make the input include all the code of the function is calls, and them
yes you can do it.
Of course such an HHH(DDD) will be non-halting, and thus not a decider.
And its DDD/HHH pairing of input will be different then the DDD/HHH
pairing given to your decider, so you logic to claim your decider
correct will just fail and be shown to be a lia.
There can not be a HHH decider smart enough to predict on the DDD built
on it, dues to that "pathological relationship", but each of those
DDD/HHH have a correct answer, just not the one that the deterministic
HHH returns,
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 10:46 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn3p3$3dv8d$12@dont-email.me> |
| In reply to | #118143 |
Op 09.mei.2025 om 17:33 schreef olcott:
> On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 01:53 schreef olcott:
>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>>> [...]
>>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>>> of mathematics.
>>>>>>
>>>>>
>>>>> If Halt7.c is not compiled with the Microsoft
>>>>> compiler then it will not produce the required
>>>>> object file type.
>>>>>
>>>>> The rest of the system has compiled under
>>>>> Linux. I haven't tried this in a few years.
>>>>
>>>> [...]
>>>>
>>>> So you normally compile your code using the 2017 version of Microsoft
>>>> Visual Studio.
>>>>
>>>> I have no particular problem with that, but your failure to correct
>>>> a number of C errors in your code is odd.
>>>
>>> As I already proved Microsoft reported no such errors.
>>>
>>>> I've pointed out several
>>>> syntax errors and constraint violations; at least the syntax errors
>>>> would be trivial to fix (even if your compiler is lax enough to
>>>> fail to diagnose them). Richard Heathfield has pointed out code
>>>> that dereferences a null pointer.
>>>>
>>>
>>> Mike corrected Richard on this.
>>> Those are stub functions intercepted
>>> by x86utm the operating system.
>>>
>>>> You are using C, a language in which you appear to have little
>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>> that, if true, would overturn ideas that have been generally accepted
>>>> for decades. Can you understand why I might decide that analyzing
>>>> your claims is not worth my time?
>>>>
>>>
>>> I learned C back when K & R was the standard.
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> We don't need to look at any of my code for me
>>> to totally prove my point. For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>>>
>>>
>>
>> A vacuous statement, because HHH cannot correctly simulate DDD, which
>> includes HHH itself.
>> A vacuous statement does not prove anything.
>
> You are saying that the smartest genius (not me)
> in the universe cannot possibly create an HHH
> that simulates itself simulating DDD?
>
> What is the evidence for this wild-eyed claim?
>
You don't need to be a genius to see that. Only fools deny it. Because
it has been proven by the halting theorem.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 10:41 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl7nv$2rl0l$9@dont-email.me> |
| In reply to | #118119 |
On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
> Op 09.mei.2025 om 01:53 schreef olcott:
>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>> [...]
>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>> of mathematics.
>>>>>
>>>>
>>>> If Halt7.c is not compiled with the Microsoft
>>>> compiler then it will not produce the required
>>>> object file type.
>>>>
>>>> The rest of the system has compiled under
>>>> Linux. I haven't tried this in a few years.
>>>
>>> [...]
>>>
>>> So you normally compile your code using the 2017 version of Microsoft
>>> Visual Studio.
>>>
>>> I have no particular problem with that, but your failure to correct
>>> a number of C errors in your code is odd.
>>
>> As I already proved Microsoft reported no such errors.
>>
>>> I've pointed out several
>>> syntax errors and constraint violations; at least the syntax errors
>>> would be trivial to fix (even if your compiler is lax enough to
>>> fail to diagnose them). Richard Heathfield has pointed out code
>>> that dereferences a null pointer.
>>>
>>
>> Mike corrected Richard on this.
>> Those are stub functions intercepted
>> by x86utm the operating system.
>>
>>> You are using C, a language in which you appear to have little
>>> apparent expertise or willingness to learn, to demonstrate claims
>>> that, if true, would overturn ideas that have been generally accepted
>>> for decades. Can you understand why I might decide that analyzing
>>> your claims is not worth my time?
>>>
>>
>> I learned C back when K & R was the standard.
>>
>> void DDD()
>> {
>> HHH(DDD);
>> return;
>> }
>>
>> We don't need to look at any of my code for me
>> to totally prove my point. For example when
>> the above DDD is correctly simulated by HHH
>> this simulated DDD cannot possibly reach its own
>> "return" instruction.
>>
>>
>
> A vacuous statement, because HHH cannot correctly simulate DDD, which
> includes HHH itself.
> A vacuous statement does not prove anything.
If you think it is impossible for HHH to emulate itself
emulating DDD then you don't have a clue about cooperative
multi-tasking with differing process contexts.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 14:08 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <9d27d8af36ca33ac9fbb6c30b880f4571c3c9cb8@i2pn2.org> |
| In reply to | #118145 |
On 5/9/25 11:41 AM, olcott wrote:
> On 5/9/2025 3:39 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 01:53 schreef olcott:
>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>>> [...]
>>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>>> of mathematics.
>>>>>>
>>>>>
>>>>> If Halt7.c is not compiled with the Microsoft
>>>>> compiler then it will not produce the required
>>>>> object file type.
>>>>>
>>>>> The rest of the system has compiled under
>>>>> Linux. I haven't tried this in a few years.
>>>>
>>>> [...]
>>>>
>>>> So you normally compile your code using the 2017 version of Microsoft
>>>> Visual Studio.
>>>>
>>>> I have no particular problem with that, but your failure to correct
>>>> a number of C errors in your code is odd.
>>>
>>> As I already proved Microsoft reported no such errors.
>>>
>>>> I've pointed out several
>>>> syntax errors and constraint violations; at least the syntax errors
>>>> would be trivial to fix (even if your compiler is lax enough to
>>>> fail to diagnose them). Richard Heathfield has pointed out code
>>>> that dereferences a null pointer.
>>>>
>>>
>>> Mike corrected Richard on this.
>>> Those are stub functions intercepted
>>> by x86utm the operating system.
>>>
>>>> You are using C, a language in which you appear to have little
>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>> that, if true, would overturn ideas that have been generally accepted
>>>> for decades. Can you understand why I might decide that analyzing
>>>> your claims is not worth my time?
>>>>
>>>
>>> I learned C back when K & R was the standard.
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> We don't need to look at any of my code for me
>>> to totally prove my point. For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>>>
>>>
>>
>> A vacuous statement, because HHH cannot correctly simulate DDD, which
>> includes HHH itself.
>> A vacuous statement does not prove anything.
>
> If you think it is impossible for HHH to emulate itself
> emulating DDD then you don't have a clue about cooperative
> multi-tasking with differing process contexts.
>
But your DDD isn't a program that can be emulated.
Are you changing your defintions again?
HHH shouldn't emulate itself if it isn't given a copy of itself to emulate.
It seems you just are too stupid to understand what you are saying.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 17:50 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjcge$27753$2@dont-email.me> |
| In reply to | #118056 |
On 5/8/2025 5:26 PM, Keith Thompson wrote:
> Mr Flibble <flibble@red-dwarf.jmc.corp> writes:
>> On Thu, 08 May 2025 21:01:42 +0100, Richard Heathfield wrote:
>>
>>> On 08/05/2025 20:42, olcott wrote:
>>>> On 5/8/2025 2:04 PM, Fred. Zwarts wrote:
>>>>> Op 08.mei.2025 om 19:00 schreef olcott:
>>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>> Does there exist an HHH such that DDD emulated by HHH according
>>>>>>>>>>> to the rules of the C programming language
>>>>>>>>>>
>>>>>>>>>> Let's take a look.
>>>>>>>>>>
>>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>>>> stop at HHH's first departure from the rules of the C programming
>>>>>>>>>> language (or at least the first departure I spot).
>>>>>>>>>>
>>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>>
>>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>>> {
>>>>>>>>>> u32 size;
>>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>>> ;
>>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>>> {
>>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>>> *destination[N] = source[N];
>>>>>>>>>> }
>>>>>>>>>> ((u32*)*destination)[-1] = size; Output("CopyMachineCode
>>>>>>>>>> destination[-1]: ",
>>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> deprecated.
>>>>>>>>
>>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>>
>>>>>>>> Everybody makes mistakes, and one slip would be all very well, but
>>>>>>>> you make essentially the same mistake --- writing to memory that
>>>>>>>> your program doesn't own --- no fewer than four times in a single
>>>>>>>> function.
>>>>>>>>
>>>>>>>>>> I'll ignore the syntax error (a null statement at file scope is a
>>>>>>>>>> rookie error).
>>>>>>>>>>
>>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>>
>>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>>
>>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>>
>>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>>
>>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>>>
>>>>>>>>>> We go on:
>>>>>>>>>>
>>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>>> {
>>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>>> *destination[N] = source[N];
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>>
>>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>>>> pity's sake.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> If you can't even understand what is essentially an infinite
>>>>>>>>> recursive relationship between two functions except that one
>>>>>>>>> function can terminate the other then you don't have a clue about
>>>>>>>>> the essence of my system.
>>>>>>>>
>>>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>>>> anyone anything about C.
>>>>>>>>
>>>>>>>> Your code is the work of a programmer so hideously incompetent that
>>>>>>>> 'programmer' is scarcely a fair word to use.
>>>>>>>>
>>>>>>>> When you publish code like that, to even *think* about denigrating
>>>>>>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>>>>>>
>>>>>>> One problem here is that you don't understand how PO's code works.
>>>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>>>> so that you understand. Instead he goes off on one of his rants, so
>>>>>>> blamewise it's really down to PO.
>>>>>>>
>>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>>>> execution environment. x87utm provides a number of primative calls
>>>>>>> that halt7.c code can make, such as Allocate(), used to allocate a
>>>>>>> block of memory for use in halt7.c. Within halt7.c code calls an
>>>>>>> Allocate() function, and x86utm intercepts that and performs the
>>>>>>> function internally, then jumps the calling code in halt7.c over the
>>>>>>> Allocate call where it continues as normal. The call never goes to
>>>>>>> the implementation of Allocate in halt7.c, so the null pointer
>>>>>>> dereferencing does not actually occur. There are a whole bunch of
>>>>>>> similar x86utm primitive operations that work in the same way.
>>>>>>>
>>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>>> interested in genuine communication.
>>>>>>>
>>>>>>> Mike.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Thanks for those details, they are correct.
>>>>>> I try to stay focused on the key essence gist of the issue and never
>>>>>> delve down into the weeds.
>>>>>>
>>>>>> int DD()
>>>>>> {
>>>>>> int Halt_Status = HHH(DD);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> The key gist of the issue (no weeds involved)
>>>>>> is that HHH emulated DD according to the rules of the x86 language
>>>>>>
>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>> *until H correctly determines that*
>>>>>> *its simulated D would never stop running unless aborted*
>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>> 10/13/2022>
>>>>>
>>>>> And since H does not correctly determine that its simulated D would
>>>>> never stop running unless aborted, it is a vacuous statement and
>>>>> Sipser's agreement does not tell anything.
>>>>>
>>>>>
>>>> That is counter factual as any fully qualified C programmer will tell
>>>> you.
>>>
>>> As any competent C programmer can tell you, your simulation is driven by
>>> assembly language, not C. Furthermore, neither halt7.c nor x86utm.cpp is
>>> syntactically correct C. Once you fix the syntax errors, that still
>>> leaves you with the undefined behaviour.
>>
>> I don't believe the C ISO Standard explictly states that stack overflow is
>> undefined behaviour however even if it did Flibble's Law applies: if a UTM
>> is allowed infinite tape then the simulating halt decider is allowed
>> infinite resources (stack space).
>
> How is that relevant? Nobody was talking about stack overflow.
>
> The standard does say that it does not specify "the size or
> complexity of a program and its data that will exceed the capacity of
> any specific data-processing system or the capacity of a particular
> processor". It doesn't explicitly say that a program that exceeds
> the system's capacity has undefined behavior, but "Undefined behavior
> is otherwise indicated in this document by the words "undefined
> behavior" **or by the omission of any explicit definition of
> behavior**" (emphasis added).
>
> But again, nobody was talking about stack overflow. I can imagine
> it might be theoretically useful to assume a C implementation with
> infinite capacity limits, though the fact that a pointer can only
> take on finitely many values is going to cause problems for that.
> Someone who wants to use C code to study the Halting Problem could
> handwave away those issues, but should do so explicitly. I have no
> idea whether olcott has addressed the fact that C pointers consist
> of a fixed number of bits and can therefore only take on any of a
> finite number of values. Turing machines are much simpler, have
> explicitly unlimited storage, and are better suited for proofs.
>
> No, the problem Richard was pointing out with olcott's Halt7.c is that
> *it's not valid C".
>
> I'm referring to <https://github.com/plolcott/x86utm/blob/master/Halt7.c>,
> commit 48b4cbf. I just tried compiling it and got a number of error
> messages. Just one example:
>
> Halt7.c: In function ‘D0’:
> Halt7.c:1258:24: warning: passing argument 1 of ‘H0’ from incompatible pointer type [-Wincompatible-pointer-types]
> 1258 | int Halt_Status = H0(D0);
> | ^~
> | |
> | int (*)()
>
> D0 is defined as "int D0() { ... }". (Unless olcott is using C23,
> there's no good reason not to use "int D0(void)", for reasons that
> I doubt olcott would understand or accept.) H0 is a function that
> takes an argument of type "ptr", which is defined as "typedef void
> (*ptr)();". So he's passing the address of a function that returns
> int as an argument that requires the address of a function that
> returns void.
>
> The fact that gcc by default issues a non-fatal warning for this is
> unfortunate, though the C standard does allow this laxity. gcc can
> be made more strict by using "-pedantic" or "-pedantic-errors",
> and by specifying which language standard you want to use (e.g.,
> "-std=c90" or "-std=c17").
>
> Another problem: there are stray semicolons on lines 87, 88, and 132.
> These are syntax errors (and gcc unfortunately does not diagnose
> them by default). These errors would be trivial to correct.
>
> I don't know whether olcott is using gcc or some other compiler.
> (It shouldn't matter.)
>
>>> Getting it right is tedious.
>>
>> Watching you continually getting it wrong is definitely tedious.
>
> I am more nearly an expert on C than on the Halting Problem.
> Watching olcott base his arguments on C *and getting C so badly
> wrong* leads me to think that he is largely ignorant of C (which is
> fine, most people are) and is unwilling to admit it. Watching the
> reactions of actual experts to his mathematical arguments leads me
> to the same conclusion about his knowledge of the relevant fields
> of mathematics.
>
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.
--
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-09 00:30 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjeqf$28555$1@dont-email.me> |
| In reply to | #118059 |
On 08/05/2025 23:50, olcott wrote:
> On 5/8/2025 5:26 PM, Keith Thompson wrote:
<snip>
>> No, the problem Richard was pointing out with olcott's Halt7.c
>> is that
>> *it's not valid C".
>>
<snip>
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> If you are a competent C programmer
Keith Thompson is a highly-respected and very competent C
programmer. You, however, are not.
> then you
> know that DDD correctly simulated by HHH cannot
> possibly each its own "return" instruction.
Assumes facts not in evidence. Whether HHH correctly simulates
DDD is disputed by a number of people. Your C code has a number
of issues, and Mike Terry has pointed out exactly how the
simulator fails to simulate.
What's left standing? Anything?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 11 of 32 — ← Prev page 1 … 9 10 [11] 12 13 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web