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 5 of 32 — ← Prev page 1 … 3 4 [5] 6 7 … 32 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 14:42 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvj1fp$22a62$1@dont-email.me> |
| In reply to | #118047 |
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.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by any HHH cannot
possibly reach its own simulated "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-08 21:01 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvj2j6$23gk7$1@dont-email.me> |
| In reply to | #118049 |
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.
Getting it right is tedious.
--
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 | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-05-08 21:35 +0000 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <as9TP.251456$lZjd.93653@fx05.ams4> |
| In reply to | #118050 |
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).
> Getting it right is tedious.
Watching you continually getting it wrong is definitely tedious.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-08 23:12 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvja8i$264u5$1@dont-email.me> |
| In reply to | #118051 |
On 08/05/2025 22:35, Mr Flibble wrote:
> 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:
<snip>
>>>>> 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
I will go one further and assure you that the standard doesn't
mention the word 'stack' at all. My claim of undefined behaviour
was not based on stack overflow but on illegal dereferencing.
6.5.3.2(4) says: "If an invalid value has been assigned to the
pointer, the behavior of the unary * operator is undefined."
For the purposes of that paragraph: "Among the invalid values for
dereferencing a pointer by the unary * operator are a null
pointer, an address inappropriately aligned for the type of
object pointed to, and the address of an object after the end of
its lifetime."
On the other hand, the standard's definition of undefined
behaviour is broad: "behavior, upon use of a nonportable or
erroneous program construct or of erroneous data, for which this
International Standard imposes no requirements".
Whether runaway recursion qualifies as nonportable or erroneous
is a judgement call. Suffice to say that wise programmers take
steps to ensure that their programs don't follow that path.
--
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 15:26 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87msbmeo3b.fsf@nosuchdomain.example.com> |
| In reply to | #118051 |
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.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 15:31 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87ikmaenv2.fsf@nosuchdomain.example.com> |
| In reply to | #118056 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> 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).
[...]
I misplaced a quotation mark and did not quote the entire relevant
paragraph. To be painfully clear, the following is Section 4,
Paragraph 2 of the N3096 draft of the ISO C23 standard:
If a "shall" or "shall not" requirement that appears outside of
a constraint or runtime-constraint is violated, the behavior is
undefined. Undefined behavior is otherwise indicated in this
document by the words "undefined behavior" or by the omission
of any explicit definition of behavior. There is no difference
in emphasis among these three; they all describe "behavior that
is undefined".
--
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 17:47 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjc9b$27753$1@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.
>
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.
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.67
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27051 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
x86utm.cpp
Generating Code...
Compiling...
api.c
decode.c
mem.c
ops.c
ops2.c
prim_ops.c
Generating Code...
Microsoft (R) Incremental Linker Version 14.16.27051.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:x86utm.exe
x86utm.obj
api.obj
decode.obj
mem.obj
ops.obj
ops2.obj
prim_ops.obj
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27051 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
Halt7.c
Press any key to continue . . .
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 16:45 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87ecwyekg2.fsf@nosuchdomain.example.com> |
| In reply to | #118058 |
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. 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.
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?
--
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 18:53 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjg6a$28g5i$3@dont-email.me> |
| In reply to | #118063 |
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.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 17:00 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <871psyejpl.fsf@nosuchdomain.example.com> |
| In reply to | #118067 |
olcott <polcott333@gmail.com> writes:
> 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.
Microsoft's compiler did not report certain errors that any conforming C
compiler is required by the standard to report.
Microsoft's compiler *can* be invoked in a way that causes it to
diagnose such errors, though it may or may not become fully conforming.
I haven't used it lately, but a web search should tell you how to do
that.
>> 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.
So did I. I've kept up with the language as it has changed.
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> We don't need to look at any of my code for me
> to totally prove my point.
Great. Then why do you keep posting code? Or is the above DDD()
function not included in "any of my code")?
> For example when
> the above DDD is correctly simulated by HHH
> this simulated DDD cannot possibly reach its own
> "return" instruction.
That's too vague for me to comment.
--
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 19:14 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjhcf$28g5i$6@dont-email.me> |
| In reply to | #118070 |
On 5/8/2025 7:00 PM, Keith Thompson wrote:
> olcott <polcott333@gmail.com> writes:
>> 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.
>
> Microsoft's compiler did not report certain errors that any conforming C
> compiler is required by the standard to report.
>
> Microsoft's compiler *can* be invoked in a way that causes it to
> diagnose such errors, though it may or may not become fully conforming.
> I haven't used it lately, but a web search should tell you how to do
> that.
>
>>> 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.
>
> So did I. I've kept up with the language as it has changed.
>
>> void DDD()
>> {
>> HHH(DDD);
>> return;
>> }
>>
>> We don't need to look at any of my code for me
>> to totally prove my point.
>
> Great. Then why do you keep posting code? Or is the above DDD()
> function not included in "any of my code")?
>
>> For example when
>> the above DDD is correctly simulated by HHH
>> this simulated DDD cannot possibly reach its own
>> "return" instruction.
>
> That's too vague for me to comment.
>
Do you know what a C language interpreter is?
I actually do this at the x86 machine code level
yet most people don't have a clue about that.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The above hypothetical HHH emulates the first four
instructions of DDD. This sequence repeats until a
OOM error.
--
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-08 21:07 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <7b1e0f52cf7461400371c5809cf93df0460d0358@i2pn2.org> |
| In reply to | #118072 |
On 5/8/25 8:14 PM, olcott wrote:
> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> 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.
>>
>> Microsoft's compiler did not report certain errors that any conforming C
>> compiler is required by the standard to report.
>>
>> Microsoft's compiler *can* be invoked in a way that causes it to
>> diagnose such errors, though it may or may not become fully conforming.
>> I haven't used it lately, but a web search should tell you how to do
>> that.
>>
>>>> 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.
>>
>> So did I. I've kept up with the language as it has changed.
>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> We don't need to look at any of my code for me
>>> to totally prove my point.
>>
>> Great. Then why do you keep posting code? Or is the above DDD()
>> function not included in "any of my code")?
>>
>>> For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>>
>> That's too vague for me to comment.
>>
>
> Do you know what a C language interpreter is?
> I actually do this at the x86 machine code level
> yet most people don't have a clue about that.
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> The above hypothetical HHH emulates the first four
> instructions of DDD. This sequence repeats until a
> OOM error.
>
Which is INVALID as in input to a halt decider as it isn't the code for
a PROGRAM, as it has a call to an address that isn't part of the program.
If that memory is supposed to be part of the program, it needs to be in
the input.
If it isn't part of the program, then it isn't a program.
And, when you define that your *ONE* HHH (as there can only be one at a
time in a C program) to abort and return 0 as it "claims" that its input
is non-halting, then the function, when called will return as it calls
the HHH that does just that, and then halts.
If you try to define your *ONE* HHH to not abort and actually do your
correct simulition, then it fails to be a decider, and thus you also fail.
Note, the function HHH that aborts can not be given the DD that calls
the HHH that doesn't as that violates the one definition rule.
Sorry, your "proof" is just proven to be a pathological lie.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 20:33 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjm10$28g5i$7@dont-email.me> |
| In reply to | #118075 |
On 5/8/2025 8:07 PM, Richard Damon wrote:
> On 5/8/25 8:14 PM, olcott wrote:
>> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> 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.
>>>
>>> Microsoft's compiler did not report certain errors that any conforming C
>>> compiler is required by the standard to report.
>>>
>>> Microsoft's compiler *can* be invoked in a way that causes it to
>>> diagnose such errors, though it may or may not become fully conforming.
>>> I haven't used it lately, but a web search should tell you how to do
>>> that.
>>>
>>>>> 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.
>>>
>>> So did I. I've kept up with the language as it has changed.
>>>
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return;
>>>> }
>>>>
>>>> We don't need to look at any of my code for me
>>>> to totally prove my point.
>>>
>>> Great. Then why do you keep posting code? Or is the above DDD()
>>> function not included in "any of my code")?
>>>
>>>> For example when
>>>> the above DDD is correctly simulated by HHH
>>>> this simulated DDD cannot possibly reach its own
>>>> "return" instruction.
>>>
>>> That's too vague for me to comment.
>>>
>>
>> Do you know what a C language interpreter is?
>> I actually do this at the x86 machine code level
>> yet most people don't have a clue about that.
>>
>> _DDD()
>> [00002172] 55 push ebp ; housekeeping
>> [00002173] 8bec mov ebp,esp ; housekeeping
>> [00002175] 6872210000 push 00002172 ; push DDD
>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>> [0000217f] 83c404 add esp,+04
>> [00002182] 5d pop ebp
>> [00002183] c3 ret
>> Size in bytes:(0018) [00002183]
>>
>> The above hypothetical HHH emulates the first four
>> instructions of DDD. This sequence repeats until a
>> OOM error.
>>
>
> Which is INVALID as in input to a halt decider
We aren't even talking about a halt decider yet.
We are only testing to see if the idea of recursive
simulation is understood to be equivalent to infinite
recursion.
--
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-08 22:11 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <29f5e2b5ff05046085fed0e88b40d083cdcd8ccc@i2pn2.org> |
| In reply to | #118080 |
On 5/8/25 9:33 PM, olcott wrote:
> On 5/8/2025 8:07 PM, Richard Damon wrote:
>> On 5/8/25 8:14 PM, olcott wrote:
>>> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> 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.
>>>>
>>>> Microsoft's compiler did not report certain errors that any
>>>> conforming C
>>>> compiler is required by the standard to report.
>>>>
>>>> Microsoft's compiler *can* be invoked in a way that causes it to
>>>> diagnose such errors, though it may or may not become fully conforming.
>>>> I haven't used it lately, but a web search should tell you how to do
>>>> that.
>>>>
>>>>>> 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.
>>>>
>>>> So did I. I've kept up with the language as it has changed.
>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point.
>>>>
>>>> Great. Then why do you keep posting code? Or is the above DDD()
>>>> function not included in "any of my code")?
>>>>
>>>>> For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> That's too vague for me to comment.
>>>>
>>>
>>> Do you know what a C language interpreter is?
>>> I actually do this at the x86 machine code level
>>> yet most people don't have a clue about that.
>>>
>>> _DDD()
>>> [00002172] 55 push ebp ; housekeeping
>>> [00002173] 8bec mov ebp,esp ; housekeeping
>>> [00002175] 6872210000 push 00002172 ; push DDD
>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>> [0000217f] 83c404 add esp,+04
>>> [00002182] 5d pop ebp
>>> [00002183] c3 ret
>>> Size in bytes:(0018) [00002183]
>>>
>>> The above hypothetical HHH emulates the first four
>>> instructions of DDD. This sequence repeats until a
>>> OOM error.
>>>
>>
>> Which is INVALID as in input to a halt decider
>
> We aren't even talking about a halt decider yet.
Sure we are, as we are discussing the behavior of what you will make the
input to one.
It also is an invalid input to a correct emulator for exactly the same
reason,
>
> We are only testing to see if the idea of recursive
> simulation is understood to be equivalent to infinite
> recursion.
>
And how do you emulate something that doesn't define all its code?
Remember, the DEFINITION of the emulation of the call HHH instruciton
include next emulating the first instruction of HHH, which izn't in the
input, and thus your emulator also isn't a pure function.
Sorry, you deceptions just doesn't work, and all you are doing is
proving your ignorance of what you are talkking about.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 18:54 -0700 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <87o6w2czvd.fsf@nosuchdomain.example.com> |
| In reply to | #118072 |
olcott <polcott333@gmail.com> writes:
> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> 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.
>> Microsoft's compiler did not report certain errors that any
>> conforming C
>> compiler is required by the standard to report.
>> Microsoft's compiler *can* be invoked in a way that causes it to
>> diagnose such errors, though it may or may not become fully conforming.
>> I haven't used it lately, but a web search should tell you how to do
>> that.
>>
>>>> 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.
>> So did I. I've kept up with the language as it has changed.
>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> We don't need to look at any of my code for me
>>> to totally prove my point.
>> Great. Then why do you keep posting code? Or is the above DDD()
>> function not included in "any of my code")?
>>
>>> For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>> That's too vague for me to comment.
>
> Do you know what a C language interpreter is?
Yes. Do you? I don't read most of your posts, but I've never seen you
post anything that could reasonably be called a C language interpreter.
Perhaps if you explain what you mean someone could suggest a more
accurate term for it.
> I actually do this at the x86 machine code level
> yet most people don't have a clue about that.
My knowledge of x86 machine code is minimal. I thought you were saying
someone only needs to be "sufficiently competent C programmer" was
enough to understand your arguments.
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
I see no interpretation of C code. All I see is a mix of x86 machine
code (in hexadecimal) and x86 assembly code.
> The above hypothetical HHH emulates the first four
> instructions of DDD. This sequence repeats until a
> OOM error.
If you say so.
A "C language interpreter" would take C *source code* as input and
execute it, presumably without first compiling it to machine code.
Let me warn you again that I expect I will tire of this discussion
very soon, so I suggest you make any coherent points quickly.
--
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 05:50 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvk1il$2i1b0$3@dont-email.me> |
| In reply to | #118072 |
On 09/05/2025 01:14, olcott wrote: > Do you know what a C language interpreter is? Of course he does. A C language interpreter is not absolved from the requirement to diagnose C syntax errors. If you think that your x86utm.cpp code qualifies as a C language interpreter, you are mistaken. You don't even grant it access to the C code. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 00:01 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvk27d$2ibbd$3@dont-email.me> |
| In reply to | #118106 |
On 5/8/2025 11:50 PM, Richard Heathfield wrote: > On 09/05/2025 01:14, olcott wrote: >> Do you know what a C language interpreter is? > > Of course he does. > > A C language interpreter is not absolved from the requirement to > diagnose C syntax errors. > > If you think that your x86utm.cpp code qualifies as a C language > interpreter, you are mistaken. You don't even grant it access to the C > code. > I am explaining is as a c language interpreter only because its actual x86 basis seems over everyone's head. -- 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 06:23 +0100 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvk3h8$2i1b1$2@dont-email.me> |
| In reply to | #118108 |
On 09/05/2025 06:01, olcott wrote: > On 5/8/2025 11:50 PM, Richard Heathfield wrote: >> On 09/05/2025 01:14, olcott wrote: >>> Do you know what a C language interpreter is? >> >> Of course he does. >> >> A C language interpreter is not absolved from the requirement >> to diagnose C syntax errors. >> >> If you think that your x86utm.cpp code qualifies as a C >> language interpreter, you are mistaken. You don't even grant it >> access to the C code. >> > > I am explaining is as a c language interpreter only > because its actual x86 basis seems over everyone's head. It doesn't interpret C. For that matter, it doesn't interpret x86 assembly language either. It just single-steps through machine instructions, like a debugger. There isn't any interpretation whatsoever. I'm not entirely sure you understand what an interpreter actually is. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 06:52 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <6f0deb80f1b373f9c1c4317bd2faaaa5c35622fb@i2pn2.org> |
| In reply to | #118108 |
On 5/9/25 1:01 AM, olcott wrote: > On 5/8/2025 11:50 PM, Richard Heathfield wrote: >> On 09/05/2025 01:14, olcott wrote: >>> Do you know what a C language interpreter is? >> >> Of course he does. >> >> A C language interpreter is not absolved from the requirement to >> diagnose C syntax errors. >> >> If you think that your x86utm.cpp code qualifies as a C language >> interpreter, you are mistaken. You don't even grant it access to the C >> code. >> > > I am explaining is as a c language interpreter only > because its actual x86 basis seems over everyone's head. > In other words, this is just your normal lying to try to cover up you don't know what you are talking about, and digging your hole deeper. Sorry, but all you are doing is showing you don't care about the truth of your statements, you just want to "trick" someone into agreeing with your lies.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-09 10:41 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvkf31$2m36t$3@dont-email.me> |
| In reply to | #118072 |
Op 09.mei.2025 om 02:14 schreef olcott:
> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>> olcott <polcott333@gmail.com> writes:
>>> 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.
>>
>> Microsoft's compiler did not report certain errors that any conforming C
>> compiler is required by the standard to report.
>>
>> Microsoft's compiler *can* be invoked in a way that causes it to
>> diagnose such errors, though it may or may not become fully conforming.
>> I haven't used it lately, but a web search should tell you how to do
>> that.
>>
>>>> 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.
>>
>> So did I. I've kept up with the language as it has changed.
>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> We don't need to look at any of my code for me
>>> to totally prove my point.
>>
>> Great. Then why do you keep posting code? Or is the above DDD()
>> function not included in "any of my code")?
>>
>>> For example when
>>> the above DDD is correctly simulated by HHH
>>> this simulated DDD cannot possibly reach its own
>>> "return" instruction.
>>
>> That's too vague for me to comment.
>>
>
> Do you know what a C language interpreter is?
> I actually do this at the x86 machine code level
> yet most people don't have a clue about that.
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> The above hypothetical HHH emulates the first four
> instructions of DDD. This sequence repeats until a
> OOM error.
>
Only in your dream, because HHH has code to abort and after that abort
the program halts without OOM error.
Every competent C programmer will understand that.
[toc] | [prev] | [next] | [standalone]
Page 5 of 32 — ← Prev page 1 … 3 4 [5] 6 7 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web