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 4 of 32 — ← Prev page 1 2 3 [4] 5 6 … 32 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 18:16 -0500 |
| Message-ID | <vvgpk6$1a47o$4@dont-email.me> |
| In reply to | #117953 |
On 5/7/2025 6:10 PM, dbush wrote: > On 5/7/2025 7:05 PM, olcott wrote: >> On 5/7/2025 5:05 PM, dbush wrote: >>> On 5/7/2025 5:56 PM, olcott wrote: >>>> On 5/7/2025 4:47 PM, dbush wrote: >>>>> On 5/7/2025 5:46 PM, olcott wrote: >>>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>>>>>> On 07/05/2025 20:35, olcott wrote: >>>>>>>> On 5/7/2025 1:59 PM, Richard Heathfield wrote: >>>>>>>>> On 07/05/2025 19:31, olcott wrote: >>>>>>> >>>>>>> <snip> >>>>>>> >>>>>>>>>> >>>>>>>>>> I already know that the contradictory part of the >>>>>>>>>> counter-example input has always been unreachable code. >>>>>>>>> >>>>>>>>> If the code is unreachable, it can't be part of a working >>>>>>>>> program, so simply remove it. >>>>>>>> >>>>>>>> It is unreachable by the Halting Problem counter-example >>>>>>>> input D when correctly simulated by the simulating >>>>>>>> termination analyzer H that it has been defined to thwart. >>>>>>> >>>>>>> If the simulation can't reach code that the directly executed >>>>>>> program reaches, then it's not a faithful simulation. >>>>>>> >>>>>> >>>>>> If is was true that it is not a faithful simulation >>>>>> then you would be able to show exactly what sequence >>>>>> of instructions would be a faithful simulation. >>>>> >>>>> >>>>> The sequence executed by HHH1, as you are on record as admitting is >>>>> correct: >>>>> >>>> >>>> What exact sequence of the following machine addresses >>>> of DD emulated by HHH >>> >>> Which it does incorrectly as you have admitted on the record: >>> >> >> Liar > > And *yet again* you lie about having made such an admission when the > evidence is right there below in black and white for all to see. > > Your dishonesty knows no bounds. > > And the fact that you trimmed the below in your reply in an attempt to > hide the fact that you lied further shows your dishonesty. > >> >> Yet you cannot show how to do it correctly > > Like HHH1 does, as you have admitted on the record: > > > On 5/6/2025 5:17 PM, dbush wrote: > > On 5/6/2025 5:03 PM, olcott wrote: > >> On 5/6/2025 3:51 PM, dbush wrote: > >>> On 5/6/2025 4:46 PM, olcott wrote: > >>>> On 5/6/2025 3:31 PM, dbush wrote: > >>>>> Then what is the first instruction emulated by HHH that differs > >>>>> from the emulation performed by UTM? > >>>>> > >>>> > >>>> HHH1 is exactly the same as HHH except that DD > >>>> does not call HHH1. This IS the UTM emulator. > >>>> It does not abort. > >>> > >>> Last chance: > >>> > >>> What is the first instruction emulated by HHH that differs from the > >>> emulation performed by HHH1? > >> > >> Go back and read the part you ignored moron. > > > > Let the record show that Peter Olcott has neglected to identify an > > instruction that HHH emulates differently from HHH1. > > > >>> Failure to provide this in your next message or within one hour of > >>> your next post in this newsgroup will be taken as your official on- > >>> the-record admission that the emulations performed by HHH and HHH1 > >>> are in fact exactly the same up until the point that HHH aborts, at > >>> which point HHH did not correctly simulate the last instruction it > >>> simulated as you are previously on record as admitting. > > > > Therefore, as per the above requirements: > > > > LET THE RECORD SHOW > > > > That Peter Olcott > > > > Has *officially* admitted > > > > That the emulations performed by HHH and HHH1 are in fact exactly the > > same up until the point that HHH aborts, at which point HHH did not > > correctly simulate the last instruction it simulated as he is previously > > on record as admitting. > > >>> On 5/5/2025 8:24 AM, dbush wrote: >>> > On 5/4/2025 11:03 PM, dbush wrote: >>> >> On 5/4/2025 10:05 PM, olcott wrote: >>> >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >>> >>>> But HHH doesn't correct emulated DD by those rules, as those rules >>> >>>> do not allow HHH to stop its emulation, >>> >>> >>> >>> Sure they do you freaking moron... >>> >> >>> >> Then show where in the Intel instruction manual that the >>> execution of >>> >> any instruction other than a HLT is allowed to stop instead of >>> >> executing the next instruction. >>> >> >>> >> Failure to do so in your next reply, or within one hour of your next >>> >> post on this newsgroup, will be taken as you official on-the-record >>> >> admission that there is no such allowance and that HHH does NOT >>> >> correctly simulate DD. >>> > >>> > Let the record show that Peter Olcott made the following post in this >>> > newsgroup after the above message: >>> > >>> > On 5/4/2025 11:04 PM, olcott wrote: >>> > > D *WOULD NEVER STOP RUNNING UNLESS* >>> > > indicates that professor Sipser was agreeing >>> > > to hypotheticals AS *NOT CHANGING THE INPUT* >>> > > >>> > > You are taking >>> > > *WOULD NEVER STOP RUNNING UNLESS* >>> > > to mean *NEVER STOPS RUNNING* that is incorrect. >>> > >>> > And has made no attempt after over 9 hours to show where in the Intel >>> > instruction manual that execution is allowed to stop after any >>> > instruction other than HLT. >>> > stupidly moronic -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 19:18 -0400 |
| Message-ID | <vvgpo7$15i5e$26@dont-email.me> |
| In reply to | #117954 |
On 5/7/2025 7:16 PM, olcott wrote: > On 5/7/2025 6:10 PM, dbush wrote: >> On 5/7/2025 7:05 PM, olcott wrote: >>> On 5/7/2025 5:05 PM, dbush wrote: >>>> On 5/7/2025 5:56 PM, olcott wrote: >>>>> On 5/7/2025 4:47 PM, dbush wrote: >>>>>> On 5/7/2025 5:46 PM, olcott wrote: >>>>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>>>>>>> On 07/05/2025 20:35, olcott wrote: >>>>>>>>> On 5/7/2025 1:59 PM, Richard Heathfield wrote: >>>>>>>>>> On 07/05/2025 19:31, olcott wrote: >>>>>>>> >>>>>>>> <snip> >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I already know that the contradictory part of the >>>>>>>>>>> counter-example input has always been unreachable code. >>>>>>>>>> >>>>>>>>>> If the code is unreachable, it can't be part of a working >>>>>>>>>> program, so simply remove it. >>>>>>>>> >>>>>>>>> It is unreachable by the Halting Problem counter-example >>>>>>>>> input D when correctly simulated by the simulating >>>>>>>>> termination analyzer H that it has been defined to thwart. >>>>>>>> >>>>>>>> If the simulation can't reach code that the directly executed >>>>>>>> program reaches, then it's not a faithful simulation. >>>>>>>> >>>>>>> >>>>>>> If is was true that it is not a faithful simulation >>>>>>> then you would be able to show exactly what sequence >>>>>>> of instructions would be a faithful simulation. >>>>>> >>>>>> >>>>>> The sequence executed by HHH1, as you are on record as admitting >>>>>> is correct: >>>>>> >>>>> >>>>> What exact sequence of the following machine addresses >>>>> of DD emulated by HHH >>>> >>>> Which it does incorrectly as you have admitted on the record: >>>> >>> >>> Liar >> >> And *yet again* you lie about having made such an admission when the >> evidence is right there below in black and white for all to see. >> >> Your dishonesty knows no bounds. >> >> And the fact that you trimmed the below in your reply in an attempt to >> hide the fact that you lied further shows your dishonesty. >> >>> >>> Yet you cannot show how to do it correctly >> >> Like HHH1 does, as you have admitted on the record: >> >> >> On 5/6/2025 5:17 PM, dbush wrote: >> > On 5/6/2025 5:03 PM, olcott wrote: >> >> On 5/6/2025 3:51 PM, dbush wrote: >> >>> On 5/6/2025 4:46 PM, olcott wrote: >> >>>> On 5/6/2025 3:31 PM, dbush wrote: >> >>>>> Then what is the first instruction emulated by HHH that differs >> >>>>> from the emulation performed by UTM? >> >>>>> >> >>>> >> >>>> HHH1 is exactly the same as HHH except that DD >> >>>> does not call HHH1. This IS the UTM emulator. >> >>>> It does not abort. >> >>> >> >>> Last chance: >> >>> >> >>> What is the first instruction emulated by HHH that differs from the >> >>> emulation performed by HHH1? >> >> >> >> Go back and read the part you ignored moron. >> > >> > Let the record show that Peter Olcott has neglected to identify an >> > instruction that HHH emulates differently from HHH1. >> > >> >>> Failure to provide this in your next message or within one hour of >> >>> your next post in this newsgroup will be taken as your official on- >> >>> the-record admission that the emulations performed by HHH and HHH1 >> >>> are in fact exactly the same up until the point that HHH aborts, at >> >>> which point HHH did not correctly simulate the last instruction it >> >>> simulated as you are previously on record as admitting. >> > >> > Therefore, as per the above requirements: >> > >> > LET THE RECORD SHOW >> > >> > That Peter Olcott >> > >> > Has *officially* admitted >> > >> > That the emulations performed by HHH and HHH1 are in fact exactly the >> > same up until the point that HHH aborts, at which point HHH did not >> > correctly simulate the last instruction it simulated as he is >> previously >> > on record as admitting. >> >> >>>> On 5/5/2025 8:24 AM, dbush wrote: >>>> > On 5/4/2025 11:03 PM, dbush wrote: >>>> >> On 5/4/2025 10:05 PM, olcott wrote: >>>> >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >>>> >>>> But HHH doesn't correct emulated DD by those rules, as those >>>> rules >>>> >>>> do not allow HHH to stop its emulation, >>>> >>> >>>> >>> Sure they do you freaking moron... >>>> >> >>>> >> Then show where in the Intel instruction manual that the >>>> execution of >>>> >> any instruction other than a HLT is allowed to stop instead of >>>> >> executing the next instruction. >>>> >> >>>> >> Failure to do so in your next reply, or within one hour of your >>>> next >>>> >> post on this newsgroup, will be taken as you official on-the-record >>>> >> admission that there is no such allowance and that HHH does NOT >>>> >> correctly simulate DD. >>>> > >>>> > Let the record show that Peter Olcott made the following post in >>>> this >>>> > newsgroup after the above message: >>>> > >>>> > On 5/4/2025 11:04 PM, olcott wrote: >>>> > > D *WOULD NEVER STOP RUNNING UNLESS* >>>> > > indicates that professor Sipser was agreeing >>>> > > to hypotheticals AS *NOT CHANGING THE INPUT* >>>> > > >>>> > > You are taking >>>> > > *WOULD NEVER STOP RUNNING UNLESS* >>>> > > to mean *NEVER STOPS RUNNING* that is incorrect. >>>> > >>>> > And has made no attempt after over 9 hours to show where in the >>>> Intel >>>> > instruction manual that execution is allowed to stop after any >>>> > instruction other than HLT. >>>> > > > stupidly moronic > If you don't want to be called out lying, don't lie.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 18:26 -0500 |
| Message-ID | <vvgq6o$1acph$1@dont-email.me> |
| In reply to | #117955 |
On 5/7/2025 6:18 PM, dbush wrote: > On 5/7/2025 7:16 PM, olcott wrote: >> On 5/7/2025 6:10 PM, dbush wrote: >>> On 5/7/2025 7:05 PM, olcott wrote: >>>> On 5/7/2025 5:05 PM, dbush wrote: >>>>> On 5/7/2025 5:56 PM, olcott wrote: >>>>>> On 5/7/2025 4:47 PM, dbush wrote: >>>>>>> On 5/7/2025 5:46 PM, olcott wrote: >>>>>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>>>>>>>> On 07/05/2025 20:35, olcott wrote: >>>>>>>>>> On 5/7/2025 1:59 PM, Richard Heathfield wrote: >>>>>>>>>>> On 07/05/2025 19:31, olcott wrote: >>>>>>>>> >>>>>>>>> <snip> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I already know that the contradictory part of the >>>>>>>>>>>> counter-example input has always been unreachable code. >>>>>>>>>>> >>>>>>>>>>> If the code is unreachable, it can't be part of a working >>>>>>>>>>> program, so simply remove it. >>>>>>>>>> >>>>>>>>>> It is unreachable by the Halting Problem counter-example >>>>>>>>>> input D when correctly simulated by the simulating >>>>>>>>>> termination analyzer H that it has been defined to thwart. >>>>>>>>> >>>>>>>>> If the simulation can't reach code that the directly executed >>>>>>>>> program reaches, then it's not a faithful simulation. >>>>>>>>> >>>>>>>> >>>>>>>> If is was true that it is not a faithful simulation >>>>>>>> then you would be able to show exactly what sequence >>>>>>>> of instructions would be a faithful simulation. >>>>>>> >>>>>>> >>>>>>> The sequence executed by HHH1, as you are on record as admitting >>>>>>> is correct: >>>>>>> >>>>>> >>>>>> What exact sequence of the following machine addresses >>>>>> of DD emulated by HHH >>>>> >>>>> Which it does incorrectly as you have admitted on the record: >>>>> >>>> >>>> Liar >>> >>> And *yet again* you lie about having made such an admission when the >>> evidence is right there below in black and white for all to see. >>> >>> Your dishonesty knows no bounds. >>> >>> And the fact that you trimmed the below in your reply in an attempt >>> to hide the fact that you lied further shows your dishonesty. >>> >>>> >>>> Yet you cannot show how to do it correctly >>> >>> Like HHH1 does, as you have admitted on the record: >>> >>> >>> On 5/6/2025 5:17 PM, dbush wrote: >>> > On 5/6/2025 5:03 PM, olcott wrote: >>> >> On 5/6/2025 3:51 PM, dbush wrote: >>> >>> On 5/6/2025 4:46 PM, olcott wrote: >>> >>>> On 5/6/2025 3:31 PM, dbush wrote: >>> >>>>> Then what is the first instruction emulated by HHH that differs >>> >>>>> from the emulation performed by UTM? >>> >>>>> >>> >>>> >>> >>>> HHH1 is exactly the same as HHH except that DD >>> >>>> does not call HHH1. This IS the UTM emulator. >>> >>>> It does not abort. >>> >>> >>> >>> Last chance: >>> >>> >>> >>> What is the first instruction emulated by HHH that differs from the >>> >>> emulation performed by HHH1? >>> >> >>> >> Go back and read the part you ignored moron. >>> > >>> > Let the record show that Peter Olcott has neglected to identify an >>> > instruction that HHH emulates differently from HHH1. >>> > >>> >>> Failure to provide this in your next message or within one hour of >>> >>> your next post in this newsgroup will be taken as your official on- >>> >>> the-record admission that the emulations performed by HHH and HHH1 >>> >>> are in fact exactly the same up until the point that HHH aborts, at >>> >>> which point HHH did not correctly simulate the last instruction it >>> >>> simulated as you are previously on record as admitting. >>> > >>> > Therefore, as per the above requirements: >>> > >>> > LET THE RECORD SHOW >>> > >>> > That Peter Olcott >>> > >>> > Has *officially* admitted >>> > >>> > That the emulations performed by HHH and HHH1 are in fact exactly the >>> > same up until the point that HHH aborts, at which point HHH did not >>> > correctly simulate the last instruction it simulated as he is >>> previously >>> > on record as admitting. >>> >>> >>>>> On 5/5/2025 8:24 AM, dbush wrote: >>>>> > On 5/4/2025 11:03 PM, dbush wrote: >>>>> >> On 5/4/2025 10:05 PM, olcott wrote: >>>>> >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >>>>> >>>> But HHH doesn't correct emulated DD by those rules, as those >>>>> rules >>>>> >>>> do not allow HHH to stop its emulation, >>>>> >>> >>>>> >>> Sure they do you freaking moron... >>>>> >> >>>>> >> Then show where in the Intel instruction manual that the >>>>> execution of >>>>> >> any instruction other than a HLT is allowed to stop instead of >>>>> >> executing the next instruction. >>>>> >> >>>>> >> Failure to do so in your next reply, or within one hour of your >>>>> next >>>>> >> post on this newsgroup, will be taken as you official on-the- >>>>> record >>>>> >> admission that there is no such allowance and that HHH does NOT >>>>> >> correctly simulate DD. >>>>> > >>>>> > Let the record show that Peter Olcott made the following post in >>>>> this >>>>> > newsgroup after the above message: >>>>> > >>>>> > On 5/4/2025 11:04 PM, olcott wrote: >>>>> > > D *WOULD NEVER STOP RUNNING UNLESS* >>>>> > > indicates that professor Sipser was agreeing >>>>> > > to hypotheticals AS *NOT CHANGING THE INPUT* >>>>> > > >>>>> > > You are taking >>>>> > > *WOULD NEVER STOP RUNNING UNLESS* >>>>> > > to mean *NEVER STOPS RUNNING* that is incorrect. >>>>> > >>>>> > And has made no attempt after over 9 hours to show where in the >>>>> Intel >>>>> > instruction manual that execution is allowed to stop after any >>>>> > instruction other than HLT. >>>>> > >> >> stupidly moronic >> > > > If you don't want to be called out lying, don't lie. When N instructions of DD are emulated by HHH according to the rules of the x86 language then N instructions of DD have been correctly emulated by HHH. You are Richard try to get away with saying that unless infinity instructions of DD are emulated by HHH according to the rules of the x86 language that the emulation is incorrect. THAT IS STUPIDLY MORONIC. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 19:31 -0400 |
| Message-ID | <vvgqgl$15i5e$27@dont-email.me> |
| In reply to | #117956 |
On 5/7/2025 7:26 PM, olcott wrote: > On 5/7/2025 6:18 PM, dbush wrote: >> On 5/7/2025 7:16 PM, olcott wrote: >>> On 5/7/2025 6:10 PM, dbush wrote: >>>> On 5/7/2025 7:05 PM, olcott wrote: >>>>> On 5/7/2025 5:05 PM, dbush wrote: >>>>>> On 5/7/2025 5:56 PM, olcott wrote: >>>>>>> On 5/7/2025 4:47 PM, dbush wrote: >>>>>>>> On 5/7/2025 5:46 PM, olcott wrote: >>>>>>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>>>>>>>>> On 07/05/2025 20:35, olcott wrote: >>>>>>>>>>> On 5/7/2025 1:59 PM, Richard Heathfield wrote: >>>>>>>>>>>> On 07/05/2025 19:31, olcott wrote: >>>>>>>>>> >>>>>>>>>> <snip> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I already know that the contradictory part of the >>>>>>>>>>>>> counter-example input has always been unreachable code. >>>>>>>>>>>> >>>>>>>>>>>> If the code is unreachable, it can't be part of a working >>>>>>>>>>>> program, so simply remove it. >>>>>>>>>>> >>>>>>>>>>> It is unreachable by the Halting Problem counter-example >>>>>>>>>>> input D when correctly simulated by the simulating >>>>>>>>>>> termination analyzer H that it has been defined to thwart. >>>>>>>>>> >>>>>>>>>> If the simulation can't reach code that the directly executed >>>>>>>>>> program reaches, then it's not a faithful simulation. >>>>>>>>>> >>>>>>>>> >>>>>>>>> If is was true that it is not a faithful simulation >>>>>>>>> then you would be able to show exactly what sequence >>>>>>>>> of instructions would be a faithful simulation. >>>>>>>> >>>>>>>> >>>>>>>> The sequence executed by HHH1, as you are on record as admitting >>>>>>>> is correct: >>>>>>>> >>>>>>> >>>>>>> What exact sequence of the following machine addresses >>>>>>> of DD emulated by HHH >>>>>> >>>>>> Which it does incorrectly as you have admitted on the record: >>>>>> >>>>> >>>>> Liar >>>> >>>> And *yet again* you lie about having made such an admission when the >>>> evidence is right there below in black and white for all to see. >>>> >>>> Your dishonesty knows no bounds. >>>> >>>> And the fact that you trimmed the below in your reply in an attempt >>>> to hide the fact that you lied further shows your dishonesty. >>>> >>>>> >>>>> Yet you cannot show how to do it correctly >>>> >>>> Like HHH1 does, as you have admitted on the record: >>>> >>>> >>>> On 5/6/2025 5:17 PM, dbush wrote: >>>> > On 5/6/2025 5:03 PM, olcott wrote: >>>> >> On 5/6/2025 3:51 PM, dbush wrote: >>>> >>> On 5/6/2025 4:46 PM, olcott wrote: >>>> >>>> On 5/6/2025 3:31 PM, dbush wrote: >>>> >>>>> Then what is the first instruction emulated by HHH that differs >>>> >>>>> from the emulation performed by UTM? >>>> >>>>> >>>> >>>> >>>> >>>> HHH1 is exactly the same as HHH except that DD >>>> >>>> does not call HHH1. This IS the UTM emulator. >>>> >>>> It does not abort. >>>> >>> >>>> >>> Last chance: >>>> >>> >>>> >>> What is the first instruction emulated by HHH that differs from >>>> the >>>> >>> emulation performed by HHH1? >>>> >> >>>> >> Go back and read the part you ignored moron. >>>> > >>>> > Let the record show that Peter Olcott has neglected to identify an >>>> > instruction that HHH emulates differently from HHH1. >>>> > >>>> >>> Failure to provide this in your next message or within one hour of >>>> >>> your next post in this newsgroup will be taken as your official >>>> on- >>>> >>> the-record admission that the emulations performed by HHH and HHH1 >>>> >>> are in fact exactly the same up until the point that HHH >>>> aborts, at >>>> >>> which point HHH did not correctly simulate the last instruction it >>>> >>> simulated as you are previously on record as admitting. >>>> > >>>> > Therefore, as per the above requirements: >>>> > >>>> > LET THE RECORD SHOW >>>> > >>>> > That Peter Olcott >>>> > >>>> > Has *officially* admitted >>>> > >>>> > That the emulations performed by HHH and HHH1 are in fact exactly >>>> the >>>> > same up until the point that HHH aborts, at which point HHH did not >>>> > correctly simulate the last instruction it simulated as he is >>>> previously >>>> > on record as admitting. >>>> >>>> >>>>>> On 5/5/2025 8:24 AM, dbush wrote: >>>>>> > On 5/4/2025 11:03 PM, dbush wrote: >>>>>> >> On 5/4/2025 10:05 PM, olcott wrote: >>>>>> >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >>>>>> >>>> But HHH doesn't correct emulated DD by those rules, as those >>>>>> rules >>>>>> >>>> do not allow HHH to stop its emulation, >>>>>> >>> >>>>>> >>> Sure they do you freaking moron... >>>>>> >> >>>>>> >> Then show where in the Intel instruction manual that the >>>>>> execution of >>>>>> >> any instruction other than a HLT is allowed to stop instead of >>>>>> >> executing the next instruction. >>>>>> >> >>>>>> >> Failure to do so in your next reply, or within one hour of >>>>>> your next >>>>>> >> post on this newsgroup, will be taken as you official on-the- >>>>>> record >>>>>> >> admission that there is no such allowance and that HHH does NOT >>>>>> >> correctly simulate DD. >>>>>> > >>>>>> > Let the record show that Peter Olcott made the following post >>>>>> in this >>>>>> > newsgroup after the above message: >>>>>> > >>>>>> > On 5/4/2025 11:04 PM, olcott wrote: >>>>>> > > D *WOULD NEVER STOP RUNNING UNLESS* >>>>>> > > indicates that professor Sipser was agreeing >>>>>> > > to hypotheticals AS *NOT CHANGING THE INPUT* >>>>>> > > >>>>>> > > You are taking >>>>>> > > *WOULD NEVER STOP RUNNING UNLESS* >>>>>> > > to mean *NEVER STOPS RUNNING* that is incorrect. >>>>>> > >>>>>> > And has made no attempt after over 9 hours to show where in the >>>>>> Intel >>>>>> > instruction manual that execution is allowed to stop after any >>>>>> > instruction other than HLT. >>>>>> > >>> >>> stupidly moronic >>> >> >> >> If you don't want to be called out lying, don't lie. > > When N instructions of DD are emulated by HHH > according to the rules of the x86 language then The subject was "DD emulated by HHH", not "N instructions of DD emulated by HHH". Changing the subject is the dishonest dodge of the strawman deception.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 18:39 -0500 |
| Message-ID | <vvgqv5$1ag3a$1@dont-email.me> |
| In reply to | #117957 |
On 5/7/2025 6:31 PM, dbush wrote: > On 5/7/2025 7:26 PM, olcott wrote: >> On 5/7/2025 6:18 PM, dbush wrote: >>> On 5/7/2025 7:16 PM, olcott wrote: >>>> On 5/7/2025 6:10 PM, dbush wrote: >>>>> On 5/7/2025 7:05 PM, olcott wrote: >>>>>> On 5/7/2025 5:05 PM, dbush wrote: >>>>>>> On 5/7/2025 5:56 PM, olcott wrote: >>>>>>>> On 5/7/2025 4:47 PM, dbush wrote: >>>>>>>>> On 5/7/2025 5:46 PM, olcott wrote: >>>>>>>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>>>>>>>>>> On 07/05/2025 20:35, olcott wrote: >>>>>>>>>>>> On 5/7/2025 1:59 PM, Richard Heathfield wrote: >>>>>>>>>>>>> On 07/05/2025 19:31, olcott wrote: >>>>>>>>>>> >>>>>>>>>>> <snip> >>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I already know that the contradictory part of the >>>>>>>>>>>>>> counter-example input has always been unreachable code. >>>>>>>>>>>>> >>>>>>>>>>>>> If the code is unreachable, it can't be part of a working >>>>>>>>>>>>> program, so simply remove it. >>>>>>>>>>>> >>>>>>>>>>>> It is unreachable by the Halting Problem counter-example >>>>>>>>>>>> input D when correctly simulated by the simulating >>>>>>>>>>>> termination analyzer H that it has been defined to thwart. >>>>>>>>>>> >>>>>>>>>>> If the simulation can't reach code that the directly executed >>>>>>>>>>> program reaches, then it's not a faithful simulation. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If is was true that it is not a faithful simulation >>>>>>>>>> then you would be able to show exactly what sequence >>>>>>>>>> of instructions would be a faithful simulation. >>>>>>>>> >>>>>>>>> >>>>>>>>> The sequence executed by HHH1, as you are on record as >>>>>>>>> admitting is correct: >>>>>>>>> >>>>>>>> >>>>>>>> What exact sequence of the following machine addresses >>>>>>>> of DD emulated by HHH >>>>>>> >>>>>>> Which it does incorrectly as you have admitted on the record: >>>>>>> >>>>>> >>>>>> Liar >>>>> >>>>> And *yet again* you lie about having made such an admission when >>>>> the evidence is right there below in black and white for all to see. >>>>> >>>>> Your dishonesty knows no bounds. >>>>> >>>>> And the fact that you trimmed the below in your reply in an attempt >>>>> to hide the fact that you lied further shows your dishonesty. >>>>> >>>>>> >>>>>> Yet you cannot show how to do it correctly >>>>> >>>>> Like HHH1 does, as you have admitted on the record: >>>>> >>>>> >>>>> On 5/6/2025 5:17 PM, dbush wrote: >>>>> > On 5/6/2025 5:03 PM, olcott wrote: >>>>> >> On 5/6/2025 3:51 PM, dbush wrote: >>>>> >>> On 5/6/2025 4:46 PM, olcott wrote: >>>>> >>>> On 5/6/2025 3:31 PM, dbush wrote: >>>>> >>>>> Then what is the first instruction emulated by HHH that differs >>>>> >>>>> from the emulation performed by UTM? >>>>> >>>>> >>>>> >>>> >>>>> >>>> HHH1 is exactly the same as HHH except that DD >>>>> >>>> does not call HHH1. This IS the UTM emulator. >>>>> >>>> It does not abort. >>>>> >>> >>>>> >>> Last chance: >>>>> >>> >>>>> >>> What is the first instruction emulated by HHH that differs >>>>> from the >>>>> >>> emulation performed by HHH1? >>>>> >> >>>>> >> Go back and read the part you ignored moron. >>>>> > >>>>> > Let the record show that Peter Olcott has neglected to identify an >>>>> > instruction that HHH emulates differently from HHH1. >>>>> > >>>>> >>> Failure to provide this in your next message or within one >>>>> hour of >>>>> >>> your next post in this newsgroup will be taken as your >>>>> official on- >>>>> >>> the-record admission that the emulations performed by HHH and >>>>> HHH1 >>>>> >>> are in fact exactly the same up until the point that HHH >>>>> aborts, at >>>>> >>> which point HHH did not correctly simulate the last >>>>> instruction it >>>>> >>> simulated as you are previously on record as admitting. >>>>> > >>>>> > Therefore, as per the above requirements: >>>>> > >>>>> > LET THE RECORD SHOW >>>>> > >>>>> > That Peter Olcott >>>>> > >>>>> > Has *officially* admitted >>>>> > >>>>> > That the emulations performed by HHH and HHH1 are in fact >>>>> exactly the >>>>> > same up until the point that HHH aborts, at which point HHH did not >>>>> > correctly simulate the last instruction it simulated as he is >>>>> previously >>>>> > on record as admitting. >>>>> >>>>> >>>>>>> On 5/5/2025 8:24 AM, dbush wrote: >>>>>>> > On 5/4/2025 11:03 PM, dbush wrote: >>>>>>> >> On 5/4/2025 10:05 PM, olcott wrote: >>>>>>> >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >>>>>>> >>>> But HHH doesn't correct emulated DD by those rules, as >>>>>>> those rules >>>>>>> >>>> do not allow HHH to stop its emulation, >>>>>>> >>> >>>>>>> >>> Sure they do you freaking moron... >>>>>>> >> >>>>>>> >> Then show where in the Intel instruction manual that the >>>>>>> execution of >>>>>>> >> any instruction other than a HLT is allowed to stop instead of >>>>>>> >> executing the next instruction. >>>>>>> >> >>>>>>> >> Failure to do so in your next reply, or within one hour of >>>>>>> your next >>>>>>> >> post on this newsgroup, will be taken as you official on-the- >>>>>>> record >>>>>>> >> admission that there is no such allowance and that HHH does NOT >>>>>>> >> correctly simulate DD. >>>>>>> > >>>>>>> > Let the record show that Peter Olcott made the following post >>>>>>> in this >>>>>>> > newsgroup after the above message: >>>>>>> > >>>>>>> > On 5/4/2025 11:04 PM, olcott wrote: >>>>>>> > > D *WOULD NEVER STOP RUNNING UNLESS* >>>>>>> > > indicates that professor Sipser was agreeing >>>>>>> > > to hypotheticals AS *NOT CHANGING THE INPUT* >>>>>>> > > >>>>>>> > > You are taking >>>>>>> > > *WOULD NEVER STOP RUNNING UNLESS* >>>>>>> > > to mean *NEVER STOPS RUNNING* that is incorrect. >>>>>>> > >>>>>>> > And has made no attempt after over 9 hours to show where in >>>>>>> the Intel >>>>>>> > instruction manual that execution is allowed to stop after any >>>>>>> > instruction other than HLT. >>>>>>> > >>>> >>>> stupidly moronic >>>> >>> >>> >>> If you don't want to be called out lying, don't lie. >> >> When N instructions of DD are emulated by HHH >> according to the rules of the x86 language then > > The subject was "DD emulated by HHH", not "N instructions of DD emulated > by HHH". > That you and Richard construe anything less than an infinite number of steps of DD emulated by HHH (according to the rules of the x86 language) as an incorrect emulation IS MORONICALLY STUPID -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 20:14 -0400 |
| Message-ID | <vvgt1b$1auqp$1@dont-email.me> |
| In reply to | #117958 |
On 5/7/2025 7:39 PM, olcott wrote: > On 5/7/2025 6:31 PM, dbush wrote: >> On 5/7/2025 7:26 PM, olcott wrote: >>> On 5/7/2025 6:18 PM, dbush wrote: >>>> On 5/7/2025 7:16 PM, olcott wrote: >>>>> On 5/7/2025 6:10 PM, dbush wrote: >>>>>> On 5/7/2025 7:05 PM, olcott wrote: >>>>>>> On 5/7/2025 5:05 PM, dbush wrote: >>>>>>>> On 5/7/2025 5:56 PM, olcott wrote: >>>>>>>>> On 5/7/2025 4:47 PM, dbush wrote: >>>>>>>>>> On 5/7/2025 5:46 PM, olcott wrote: >>>>>>>>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>>>>>>>>>>> On 07/05/2025 20:35, olcott wrote: >>>>>>>>>>>>> On 5/7/2025 1:59 PM, Richard Heathfield wrote: >>>>>>>>>>>>>> On 07/05/2025 19:31, olcott wrote: >>>>>>>>>>>> >>>>>>>>>>>> <snip> >>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I already know that the contradictory part of the >>>>>>>>>>>>>>> counter-example input has always been unreachable code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the code is unreachable, it can't be part of a working >>>>>>>>>>>>>> program, so simply remove it. >>>>>>>>>>>>> >>>>>>>>>>>>> It is unreachable by the Halting Problem counter-example >>>>>>>>>>>>> input D when correctly simulated by the simulating >>>>>>>>>>>>> termination analyzer H that it has been defined to thwart. >>>>>>>>>>>> >>>>>>>>>>>> If the simulation can't reach code that the directly >>>>>>>>>>>> executed program reaches, then it's not a faithful simulation. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If is was true that it is not a faithful simulation >>>>>>>>>>> then you would be able to show exactly what sequence >>>>>>>>>>> of instructions would be a faithful simulation. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The sequence executed by HHH1, as you are on record as >>>>>>>>>> admitting is correct: >>>>>>>>>> >>>>>>>>> >>>>>>>>> What exact sequence of the following machine addresses >>>>>>>>> of DD emulated by HHH >>>>>>>> >>>>>>>> Which it does incorrectly as you have admitted on the record: >>>>>>>> >>>>>>> >>>>>>> Liar >>>>>> >>>>>> And *yet again* you lie about having made such an admission when >>>>>> the evidence is right there below in black and white for all to see. >>>>>> >>>>>> Your dishonesty knows no bounds. >>>>>> >>>>>> And the fact that you trimmed the below in your reply in an >>>>>> attempt to hide the fact that you lied further shows your dishonesty. >>>>>> >>>>>>> >>>>>>> Yet you cannot show how to do it correctly >>>>>> >>>>>> Like HHH1 does, as you have admitted on the record: >>>>>> >>>>>> >>>>>> On 5/6/2025 5:17 PM, dbush wrote: >>>>>> > On 5/6/2025 5:03 PM, olcott wrote: >>>>>> >> On 5/6/2025 3:51 PM, dbush wrote: >>>>>> >>> On 5/6/2025 4:46 PM, olcott wrote: >>>>>> >>>> On 5/6/2025 3:31 PM, dbush wrote: >>>>>> >>>>> Then what is the first instruction emulated by HHH that >>>>>> differs >>>>>> >>>>> from the emulation performed by UTM? >>>>>> >>>>> >>>>>> >>>> >>>>>> >>>> HHH1 is exactly the same as HHH except that DD >>>>>> >>>> does not call HHH1. This IS the UTM emulator. >>>>>> >>>> It does not abort. >>>>>> >>> >>>>>> >>> Last chance: >>>>>> >>> >>>>>> >>> What is the first instruction emulated by HHH that differs >>>>>> from the >>>>>> >>> emulation performed by HHH1? >>>>>> >> >>>>>> >> Go back and read the part you ignored moron. >>>>>> > >>>>>> > Let the record show that Peter Olcott has neglected to identify an >>>>>> > instruction that HHH emulates differently from HHH1. >>>>>> > >>>>>> >>> Failure to provide this in your next message or within one >>>>>> hour of >>>>>> >>> your next post in this newsgroup will be taken as your >>>>>> official on- >>>>>> >>> the-record admission that the emulations performed by HHH and >>>>>> HHH1 >>>>>> >>> are in fact exactly the same up until the point that HHH >>>>>> aborts, at >>>>>> >>> which point HHH did not correctly simulate the last >>>>>> instruction it >>>>>> >>> simulated as you are previously on record as admitting. >>>>>> > >>>>>> > Therefore, as per the above requirements: >>>>>> > >>>>>> > LET THE RECORD SHOW >>>>>> > >>>>>> > That Peter Olcott >>>>>> > >>>>>> > Has *officially* admitted >>>>>> > >>>>>> > That the emulations performed by HHH and HHH1 are in fact >>>>>> exactly the >>>>>> > same up until the point that HHH aborts, at which point HHH did >>>>>> not >>>>>> > correctly simulate the last instruction it simulated as he is >>>>>> previously >>>>>> > on record as admitting. >>>>>> >>>>>> >>>>>>>> On 5/5/2025 8:24 AM, dbush wrote: >>>>>>>> > On 5/4/2025 11:03 PM, dbush wrote: >>>>>>>> >> On 5/4/2025 10:05 PM, olcott wrote: >>>>>>>> >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >>>>>>>> >>>> But HHH doesn't correct emulated DD by those rules, as >>>>>>>> those rules >>>>>>>> >>>> do not allow HHH to stop its emulation, >>>>>>>> >>> >>>>>>>> >>> Sure they do you freaking moron... >>>>>>>> >> >>>>>>>> >> Then show where in the Intel instruction manual that the >>>>>>>> execution of >>>>>>>> >> any instruction other than a HLT is allowed to stop instead of >>>>>>>> >> executing the next instruction. >>>>>>>> >> >>>>>>>> >> Failure to do so in your next reply, or within one hour of >>>>>>>> your next >>>>>>>> >> post on this newsgroup, will be taken as you official on- >>>>>>>> the- record >>>>>>>> >> admission that there is no such allowance and that HHH does NOT >>>>>>>> >> correctly simulate DD. >>>>>>>> > >>>>>>>> > Let the record show that Peter Olcott made the following post >>>>>>>> in this >>>>>>>> > newsgroup after the above message: >>>>>>>> > >>>>>>>> > On 5/4/2025 11:04 PM, olcott wrote: >>>>>>>> > > D *WOULD NEVER STOP RUNNING UNLESS* >>>>>>>> > > indicates that professor Sipser was agreeing >>>>>>>> > > to hypotheticals AS *NOT CHANGING THE INPUT* >>>>>>>> > > >>>>>>>> > > You are taking >>>>>>>> > > *WOULD NEVER STOP RUNNING UNLESS* >>>>>>>> > > to mean *NEVER STOPS RUNNING* that is incorrect. >>>>>>>> > >>>>>>>> > And has made no attempt after over 9 hours to show where in >>>>>>>> the Intel >>>>>>>> > instruction manual that execution is allowed to stop after any >>>>>>>> > instruction other than HLT. >>>>>>>> > >>>>> >>>>> stupidly moronic >>>>> >>>> >>>> >>>> If you don't want to be called out lying, don't lie. >>> >>> When N instructions of DD are emulated by HHH >>> according to the rules of the x86 language then >> >> The subject was "DD emulated by HHH", not "N instructions of DD >> emulated by HHH". >> > > That you and Richard construe anything less than an > infinite number of steps of DD emulated by HHH > (according to the rules of the x86 language) > as an incorrect emulation IS MORONICALLY STUPID The fixed immutable code of HHH simulates a fixed number X of instructions of DD, the last of which was simulated incorrectly. Any number other than X is not what HHH simulates. UTM simulates X+Y instruction of DD correctly and reaches a final state. > >> Changing the subject is the dishonest dodge of the strawman deception.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 18:40 -0500 |
| Message-ID | <vvgr22$1ag3a$2@dont-email.me> |
| In reply to | #117957 |
On 5/7/2025 6:31 PM, dbush wrote: > On 5/7/2025 7:26 PM, olcott wrote: >> >> When N instructions of DD are emulated by HHH >> according to the rules of the x86 language then > > The subject was "DD emulated by HHH", not "N instructions of DD emulated > by HHH". > > Changing the subject is the dishonest dodge of the strawman deception. That you and Richard construe anything less than an infinite number of steps of DD emulated by HHH (according to the rules of the x86 language) as an incorrect emulation IS MORONICALLY STUPID. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 20:15 -0400 |
| Message-ID | <vvgt36$1auqp$2@dont-email.me> |
| In reply to | #117959 |
On 5/7/2025 7:40 PM, olcott wrote: > On 5/7/2025 6:31 PM, dbush wrote: >> On 5/7/2025 7:26 PM, olcott wrote: >>> >>> When N instructions of DD are emulated by HHH >>> according to the rules of the x86 language then >> >> The subject was "DD emulated by HHH", not "N instructions of DD >> emulated by HHH". >> >> Changing the subject is the dishonest dodge of the strawman deception. > > > That you and Richard construe anything less than an > infinite number of steps of DD emulated by HHH > (according to the rules of the x86 language) > as an incorrect emulation IS MORONICALLY STUPID. > The fixed immutable code of HHH simulates a fixed number X of instructions of DD, the last of which was simulated incorrectly. Any number other than X is not what HHH simulates and is therefore irrelevant to HHH. UTM simulates X+Y instruction of DD correctly and reaches a final state.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 19:19 -0500 |
| Message-ID | <vvgtbe$1b0li$1@dont-email.me> |
| In reply to | #117962 |
On 5/7/2025 7:15 PM, dbush wrote:
> On 5/7/2025 7:40 PM, olcott wrote:
>> On 5/7/2025 6:31 PM, dbush wrote:
>>> On 5/7/2025 7:26 PM, olcott wrote:
>>>>
>>>> When N instructions of DD are emulated by HHH
>>>> according to the rules of the x86 language then
>>>
>>> The subject was "DD emulated by HHH", not "N instructions of DD
>>> emulated by HHH".
>>>
>>> Changing the subject is the dishonest dodge of the strawman deception.
>>
>>
>> That you and Richard construe anything less than an
>> infinite number of steps of DD emulated by HHH
>> (according to the rules of the x86 language)
>> as an incorrect emulation IS MORONICALLY STUPID.
>>
>
> The fixed immutable code of HHH simulates a fixed number X of
> instructions of DD, the last of which was simulated incorrectly. Any
> number other than X is not what HHH simulates and is therefore
> irrelevant to HHH.
>
> UTM simulates X+Y instruction of DD correctly and reaches a final state.
>
I will make it easier to understand.
void DDD()
{
HHH(DDD);
return;
}
Can DDD simulated by HHH 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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 20:44 -0400 |
| Message-ID | <vvguot$1auqp$3@dont-email.me> |
| In reply to | #117963 |
On 5/7/2025 8:19 PM, olcott wrote:
> On 5/7/2025 7:15 PM, dbush wrote:
>> On 5/7/2025 7:40 PM, olcott wrote:
>>> On 5/7/2025 6:31 PM, dbush wrote:
>>>> On 5/7/2025 7:26 PM, olcott wrote:
>>>>>
>>>>> When N instructions of DD are emulated by HHH
>>>>> according to the rules of the x86 language then
>>>>
>>>> The subject was "DD emulated by HHH", not "N instructions of DD
>>>> emulated by HHH".
>>>>
>>>> Changing the subject is the dishonest dodge of the strawman deception.
>>>
>>>
>>> That you and Richard construe anything less than an
>>> infinite number of steps of DD emulated by HHH
>>> (according to the rules of the x86 language)
>>> as an incorrect emulation IS MORONICALLY STUPID.
>>>
>>
>> The fixed immutable code of HHH simulates a fixed number X of
>> instructions of DD, the last of which was simulated incorrectly. Any
>> number other than X is not what HHH simulates and is therefore
>> irrelevant to HHH.
>>
>> UTM simulates X+Y instruction of DD correctly and reaches a final state.
>>
>
> I will make it easier to understand.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> Can DDD simulated by HHH reach its own "return" instruction?
>
Category error. There is no "can" as algorithm HHH is fixed and
immutable, as is algorithm DDD.
Algorithm HHH *does not* simulate algorithm DDD to the end but instead
aborts in violation of the x86 language.
Algorithm UTM *does* simulate algorithm DDD to the end.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 20:20 -0500 |
| Message-ID | <vvh0t2$1b939$1@dont-email.me> |
| In reply to | #117964 |
On 5/7/2025 7:44 PM, dbush wrote:
> On 5/7/2025 8:19 PM, olcott wrote:
>> On 5/7/2025 7:15 PM, dbush wrote:
>>> On 5/7/2025 7:40 PM, olcott wrote:
>>>> On 5/7/2025 6:31 PM, dbush wrote:
>>>>> On 5/7/2025 7:26 PM, olcott wrote:
>>>>>>
>>>>>> When N instructions of DD are emulated by HHH
>>>>>> according to the rules of the x86 language then
>>>>>
>>>>> The subject was "DD emulated by HHH", not "N instructions of DD
>>>>> emulated by HHH".
>>>>>
>>>>> Changing the subject is the dishonest dodge of the strawman deception.
>>>>
>>>>
>>>> That you and Richard construe anything less than an
>>>> infinite number of steps of DD emulated by HHH
>>>> (according to the rules of the x86 language)
>>>> as an incorrect emulation IS MORONICALLY STUPID.
>>>>
>>>
>>> The fixed immutable code of HHH simulates a fixed number X of
>>> instructions of DD, the last of which was simulated incorrectly. Any
>>> number other than X is not what HHH simulates and is therefore
>>> irrelevant to HHH.
>>>
>>> UTM simulates X+Y instruction of DD correctly and reaches a final state.
>>>
>>
>> I will make it easier to understand.
>>
>> void DDD()
>> {
>> HHH(DDD);
>> return;
>> }
>>
>> Can DDD simulated by HHH reach its own "return" instruction?
>>
>
> Category error. There is no "can" as algorithm HHH is fixed and
> immutable, as is algorithm DDD.
>
Does there exist an HHH such that DDD emulated by
HHH according to the rules of the C programming language
where the DDD element of the infinite set of HHH/DDD
pairs reaches its own "return" instruction?
It is like I am asking you is there a positive
number that is less than zero? You don't have
to check the positive numbers one-at-a-time.
We can know with complete certainty that no DDD
simulated by any HHH can possibly reach its own
"return" instruction.
> Algorithm HHH *does not* simulate algorithm DDD to the end but instead
> aborts in violation of the x86 language.
>
there is no end to reach.
> Algorithm UTM *does* simulate algorithm DDD to the end.
>
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 21:30 -0400 |
| Message-ID | <vvh1ev$1bt2l$1@dont-email.me> |
| In reply to | #117965 |
On 5/7/2025 9:20 PM, olcott wrote:
> On 5/7/2025 7:44 PM, dbush wrote:
>> On 5/7/2025 8:19 PM, olcott wrote:
>>> On 5/7/2025 7:15 PM, dbush wrote:
>>>> On 5/7/2025 7:40 PM, olcott wrote:
>>>>> On 5/7/2025 6:31 PM, dbush wrote:
>>>>>> On 5/7/2025 7:26 PM, olcott wrote:
>>>>>>>
>>>>>>> When N instructions of DD are emulated by HHH
>>>>>>> according to the rules of the x86 language then
>>>>>>
>>>>>> The subject was "DD emulated by HHH", not "N instructions of DD
>>>>>> emulated by HHH".
>>>>>>
>>>>>> Changing the subject is the dishonest dodge of the strawman
>>>>>> deception.
>>>>>
>>>>>
>>>>> That you and Richard construe anything less than an
>>>>> infinite number of steps of DD emulated by HHH
>>>>> (according to the rules of the x86 language)
>>>>> as an incorrect emulation IS MORONICALLY STUPID.
>>>>>
>>>>
>>>> The fixed immutable code of HHH simulates a fixed number X of
>>>> instructions of DD, the last of which was simulated incorrectly.
>>>> Any number other than X is not what HHH simulates and is therefore
>>>> irrelevant to HHH.
>>>>
>>>> UTM simulates X+Y instruction of DD correctly and reaches a final
>>>> state.
>>>>
>>>
>>> I will make it easier to understand.
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> Can DDD simulated by HHH reach its own "return" instruction?
>>>
>>
>> Category error. There is no "can" as algorithm HHH is fixed and
>> immutable, as is algorithm DDD.
>>
>
> Does there exist an HHH
Category error. There is only one algorithm HHH and one algorithm DDD.
> such that DDD emulated by
> HHH according to the rules of the C programming language
> where the DDD element of the infinite set of HHH/DDD
> pairs reaches its own "return" instruction?
Changing the input is not allowed.
>
> It is like I am asking you is there a positive
> number that is less than zero? You don't have
> to check the positive numbers one-at-a-time.
>
> We can know with complete certainty that no DDD
> simulated by any HHH can possibly reach its own
> "return" instruction.
Changing the input is not allowed.
>
>> Algorithm HHH *does not* simulate algorithm DDD to the end but instead
>> aborts in violation of the x86 language.
>>
>
> there is no end to reach.
False. See below.
>
>> Algorithm UTM *does* simulate algorithm DDD to the end.
>>
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 20:48 -0500 |
| Message-ID | <vvh2hr$1b939$2@dont-email.me> |
| In reply to | #117966 |
On 5/7/2025 8:30 PM, dbush wrote:
> On 5/7/2025 9:20 PM, olcott wrote:
>> On 5/7/2025 7:44 PM, dbush wrote:
>>> On 5/7/2025 8:19 PM, olcott wrote:
>>>> On 5/7/2025 7:15 PM, dbush wrote:
>>>>> On 5/7/2025 7:40 PM, olcott wrote:
>>>>>> On 5/7/2025 6:31 PM, dbush wrote:
>>>>>>> On 5/7/2025 7:26 PM, olcott wrote:
>>>>>>>>
>>>>>>>> When N instructions of DD are emulated by HHH
>>>>>>>> according to the rules of the x86 language then
>>>>>>>
>>>>>>> The subject was "DD emulated by HHH", not "N instructions of DD
>>>>>>> emulated by HHH".
>>>>>>>
>>>>>>> Changing the subject is the dishonest dodge of the strawman
>>>>>>> deception.
>>>>>>
>>>>>>
>>>>>> That you and Richard construe anything less than an
>>>>>> infinite number of steps of DD emulated by HHH
>>>>>> (according to the rules of the x86 language)
>>>>>> as an incorrect emulation IS MORONICALLY STUPID.
>>>>>>
>>>>>
>>>>> The fixed immutable code of HHH simulates a fixed number X of
>>>>> instructions of DD, the last of which was simulated incorrectly.
>>>>> Any number other than X is not what HHH simulates and is therefore
>>>>> irrelevant to HHH.
>>>>>
>>>>> UTM simulates X+Y instruction of DD correctly and reaches a final
>>>>> state.
>>>>>
>>>>
>>>> I will make it easier to understand.
>>>>
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return;
>>>> }
>>>>
>>>> Can DDD simulated by HHH reach its own "return" instruction?
>>>>
>>>
>>> Category error. There is no "can" as algorithm HHH is fixed and
>>> immutable, as is algorithm DDD.
>>>
>>
>> Does there exist an HHH
>
> Category error. There is only one algorithm HHH and one algorithm DDD.
>
>> such that DDD emulated by
>> HHH according to the rules of the C programming language
>> where the DDD element of the infinite set of HHH/DDD
>> pairs reaches its own "return" instruction?
>
> Changing the input is not allowed.
>
>>
>> It is like I am asking you is there a positive
>> number that is less than zero? You don't have
>> to check the positive numbers one-at-a-time.
>>
>> We can know with complete certainty that no DDD
>> simulated by any HHH can possibly reach its own
>> "return" instruction.
>
> Changing the input is not allowed.
>
>>
>>> Algorithm HHH *does not* simulate algorithm DDD to the end but
>>> instead aborts in violation of the x86 language.
>>>
>>
>> there is no end to reach.
>
> False. See below.
>
>>
>>> Algorithm UTM *does* simulate algorithm DDD to the end.
DDD emulated by HHH according to the rules of the
x86 language has an easily provably different sequence
of steps than directly executed DDD() according to the
rules of the x86 machine language.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-07 21:59 -0400 |
| Message-ID | <vvh365$1bt2l$2@dont-email.me> |
| In reply to | #117967 |
On 5/7/2025 9:48 PM, olcott wrote:
> On 5/7/2025 8:30 PM, dbush wrote:
>> On 5/7/2025 9:20 PM, olcott wrote:
>>> On 5/7/2025 7:44 PM, dbush wrote:
>>>> On 5/7/2025 8:19 PM, olcott wrote:
>>>>> On 5/7/2025 7:15 PM, dbush wrote:
>>>>>> On 5/7/2025 7:40 PM, olcott wrote:
>>>>>>> On 5/7/2025 6:31 PM, dbush wrote:
>>>>>>>> On 5/7/2025 7:26 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>> When N instructions of DD are emulated by HHH
>>>>>>>>> according to the rules of the x86 language then
>>>>>>>>
>>>>>>>> The subject was "DD emulated by HHH", not "N instructions of DD
>>>>>>>> emulated by HHH".
>>>>>>>>
>>>>>>>> Changing the subject is the dishonest dodge of the strawman
>>>>>>>> deception.
>>>>>>>
>>>>>>>
>>>>>>> That you and Richard construe anything less than an
>>>>>>> infinite number of steps of DD emulated by HHH
>>>>>>> (according to the rules of the x86 language)
>>>>>>> as an incorrect emulation IS MORONICALLY STUPID.
>>>>>>>
>>>>>>
>>>>>> The fixed immutable code of HHH simulates a fixed number X of
>>>>>> instructions of DD, the last of which was simulated incorrectly.
>>>>>> Any number other than X is not what HHH simulates and is therefore
>>>>>> irrelevant to HHH.
>>>>>>
>>>>>> UTM simulates X+Y instruction of DD correctly and reaches a final
>>>>>> state.
>>>>>>
>>>>>
>>>>> I will make it easier to understand.
>>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> Can DDD simulated by HHH reach its own "return" instruction?
>>>>>
>>>>
>>>> Category error. There is no "can" as algorithm HHH is fixed and
>>>> immutable, as is algorithm DDD.
>>>>
>>>
>>> Does there exist an HHH
>>
>> Category error. There is only one algorithm HHH and one algorithm DDD.
>>
>>> such that DDD emulated by
>>> HHH according to the rules of the C programming language
>>> where the DDD element of the infinite set of HHH/DDD
>>> pairs reaches its own "return" instruction?
>>
>> Changing the input is not allowed.
>>
>>>
>>> It is like I am asking you is there a positive
>>> number that is less than zero? You don't have
>>> to check the positive numbers one-at-a-time.
>>>
>>> We can know with complete certainty that no DDD
>>> simulated by any HHH can possibly reach its own
>>> "return" instruction.
>>
>> Changing the input is not allowed.
>>
>>>
>>>> Algorithm HHH *does not* simulate algorithm DDD to the end but
>>>> instead aborts in violation of the x86 language.
>>>>
>>>
>>> there is no end to reach.
>>
>> False. See below.
>>
>>>
>>>> Algorithm UTM *does* simulate algorithm DDD to the end.
>
> DDD emulated by HHH according to the rules of the
> x86 language
Doesn't happen, as you have admitted on the record:
On 5/5/2025 8:24 AM, dbush wrote:
> On 5/4/2025 11:03 PM, dbush wrote:
>> On 5/4/2025 10:05 PM, olcott wrote:
>>> On 5/4/2025 7:23 PM, Richard Damon wrote:
>>>> But HHH doesn't correct emulated DD by those rules, as those rules
>>>> do not allow HHH to stop its emulation,
>>>
>>> Sure they do you freaking moron...
>>
>> Then show where in the Intel instruction manual that the execution of
>> any instruction other than a HLT is allowed to stop instead of
>> executing the next instruction.
>>
>> Failure to do so in your next reply, or within one hour of your next
>> post on this newsgroup, will be taken as you official on-the-record
>> admission that there is no such allowance and that HHH does NOT
>> correctly simulate DD.
>
> Let the record show that Peter Olcott made the following post in this
> newsgroup after the above message:
>
> On 5/4/2025 11:04 PM, olcott wrote:
> > D *WOULD NEVER STOP RUNNING UNLESS*
> > indicates that professor Sipser was agreeing
> > to hypotheticals AS *NOT CHANGING THE INPUT*
> >
> > You are taking
> > *WOULD NEVER STOP RUNNING UNLESS*
> > to mean *NEVER STOPS RUNNING* that is incorrect.
>
> And has made no attempt after over 9 hours to show where in the Intel
> instruction manual that execution is allowed to stop after any
> instruction other than HLT.
>
> Therefore, as per the above criteria:
>
> LET THE RECORD SHOW
>
> That Peter Olcott
>
> Has *officially* admitted
>
> That DD is NOT correctly simulated by HHH
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-08 05:09 +0100 |
| Message-ID | <vvhap5$1hp80$1@dont-email.me> |
| In reply to | #117965 |
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]);
};
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.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 00:22 -0500 |
| Message-ID | <vvhf20$1ihs9$1@dont-email.me> |
| In reply to | #118006 |
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.
> 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.
--
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 06:33 +0100 |
| Message-ID | <vvhfnd$1hvei$3@dont-email.me> |
| In reply to | #118018 |
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.
--
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 | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-05-08 17:14 +0100 |
| Message-ID | <vvil99$1ugd5$1@dont-email.me> |
| In reply to | #118020 |
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.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 12:00 -0500 |
| Subject | Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvinvp$1vglb$1@dont-email.me> |
| In reply to | #118044 |
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>
When HHH(DD) computes the actual mapping from
its actual input to the actual behavior this
it specifies it must be according to the rules
of the x86 language.
int sum(int x, int y) { return x + y; }
sum is required to compute the mapping
from its input into its return value
according to the rules of arithmetic.
This means that requiring sum(3,2) to return
the sum of 5 + 7 is an incorrect requirement.
Like sum(3,2) HHH(DD) is only allowed to report
on the behavior that its input actually specifies.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-08 21:04 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vviv75$222r6$1@dont-email.me> |
| In reply to | #118045 |
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.
>
> When HHH(DD) computes the actual mapping from
> its actual input to the actual behavior this
> it specifies it must be according to the rules
> of the x86 language.
Meaning that it should not abort a halting program, and not skip the
most important part of its input, where it would see a conditional
abort, which makes the program halting.
But HHH violates the x86 language by halting when there is no HLT
instruction.
>
> int sum(int x, int y) { return x + y; }
> sum is required to compute the mapping
> from its input into its return value
> according to the rules of arithmetic.
>
> This means that requiring sum(3,2) to return
> the sum of 5 + 7 is an incorrect requirement.
>
> Like sum(3,2) HHH(DD) is only allowed to report
> on the behavior that its input actually specifies.
>
But HHH is like Sum(3,2) processing only the 3 and not the 2, when it
aborts after processing only the first part of the input and not the
whole input. The whole input specifies a halting program, but the
programmer made HHH blind for the specification that is in the input.
[toc] | [prev] | [next] | [standalone]
Page 4 of 32 — ← Prev page 1 2 3 [4] 5 6 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web