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 30 of 32 — ← Prev page 1 … 28 29 [30] 31 32 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-08 21:18 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <2cdf4423d1a8030626738c2dab258688b6c75efc@i2pn2.org> |
| In reply to | #118065 |
On 5/8/25 7:48 PM, olcott wrote:
> On 5/8/2025 6:35 PM, Richard Damon wrote:
>> On 5/8/25 1:00 PM, olcott wrote:
>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>
>>>>>>> Let's take a look.
>>>>>>>
>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>> stop at HHH's first departure from the rules of the C programming
>>>>>>> language (or at least the first departure I spot).
>>>>>>>
>>>>>>> Turn in your songbook if you will to:
>>>>>>>
>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>> {
>>>>>>> u32 size;
>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>> ;
>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>> {
>>>>>>> Output("source[N]: ", source[N]);
>>>>>>> *destination[N] = source[N];
>>>>>>> }
>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>> ((u32*)*destination) [-1]);
>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>> ((u32*)*destination) [-2]);
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> deprecated.
>>>>>
>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>
>>>>> Everybody makes mistakes, and one slip would be all very well, but
>>>>> you make essentially the same mistake --- writing to memory that
>>>>> your program doesn't own --- no fewer than four times in a single
>>>>> function.
>>>>>
>>>>>>> I'll ignore the syntax error (a null statement at file scope is a
>>>>>>> rookie error).
>>>>>>>
>>>>>>> Instead, let's jump straight to this line:
>>>>>>>
>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>
>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>
>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>
>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>> deref it. So now *destination is NULL.
>>>>>>>
>>>>>>> We go on:
>>>>>>>
>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>> {
>>>>>>> Output("source[N]: ", source[N]);
>>>>>>> *destination[N] = source[N];
>>>>>>> }
>>>>>>>
>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>> destination[N] derefs a null pointer.
>>>>>>>
>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>> pity's sake.
>>>>>>>
>>>>>>
>>>>>> If you can't even understand what is essentially
>>>>>> an infinite recursive relationship between two functions
>>>>>> except that one function can terminate the other then
>>>>>> you don't have a clue about the essence of my system.
>>>>>
>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>> dereference a null pointer, you have no business trying to teach
>>>>> anyone anything about C.
>>>>>
>>>>> Your code is the work of a programmer so hideously incompetent that
>>>>> 'programmer' is scarcely a fair word to use.
>>>>>
>>>>> When you publish code like that, to even *think* about denigrating
>>>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>>>
>>>> One problem here is that you don't understand how PO's code works.
>>>> That's to be expected, and PO's response ought to be to explain it
>>>> so that you understand. Instead he goes off on one of his rants, so
>>>> blamewise it's really down to PO.
>>>>
>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>> execution environment. x87utm provides a number of primative calls
>>>> that halt7.c code can make, such as Allocate(), used to allocate a
>>>> block of memory for use in halt7.c. Within halt7.c code calls an
>>>> Allocate() function, and x86utm intercepts that and performs the
>>>> function internally, then jumps the calling code in halt7.c over the
>>>> Allocate call where it continues as normal. The call never goes to
>>>> the implementation of Allocate in halt7.c, so the null pointer
>>>> dereferencing does not actually occur. There are a whole bunch of
>>>> similar x86utm primitive operations that work in the same way.
>>>>
>>>> PO should have said all that, not me, but it seems he's not
>>>> interested in genuine communication.
>>>>
>>>> Mike.
>>>>
>>>>
>>>
>>> Thanks for those details, they are correct.
>>> I try to stay focused on the key essence gist
>>> of the issue and never delve down into the weeds.
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> The key gist of the issue (no weeds involved)
>>> is that HHH emulated DD according to the rules
>>> of the x86 language
>>
>> Excpet, as you have admitted, your DD isn't a program (just a C
>> funciton), and thus not a proper input for a halt decider, which by
>> definiton must be a program.
>>
>> Your C function can't be a program, as you have specifically said that
>> the function, and only the funciton is the input, and programs must
>> include in them all their code, so since the code of HHH isn't
>> included in DD or the input representing it, it isn't a program, and
>> thus not a proper input
>>
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> *until H correctly determines that*
>>> *its simulated D would never stop running unless aborted*
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>
>> But that statement implies, as required that H be a halt decider and D
>> to be a proper input to one, neither of which are satisfied, as you
>> have admitte
>>
>>> When HHH(DD) computes the actual mapping from
>>> its actual input to the actual behavior this
>>> it specifies it must be according to the rules
>>> of the x86 language.
>>
>> But it doesn't, as it doesn't correctly follow the behavior of the x86
>> language, as that requires HHH to follow the call instruction, which
>> it can not do as the required (and accepted by your) condition that
>> the decider is a pure function, which means it can only look at its
>> input, which does not include the code which the call points to.
>>
>>>
>>> int sum(int x, int y) { return x + y; }
>>> sum is required to compute the mapping
>>> from its input into its return value
>>> according to the rules of arithmetic.
>>
>> Right, and a halt decider is required to (try to) compute the mapping
>> from the input (which needs to be the representation of a program) to
>> the results of running that program (since that is the DEFINITION of
>> Halt Deciding).
>>
>>>
>>> This means that requiring sum(3,2) to return
>>> the sum of 5 + 7 is an incorrect requirement.
>>
>> Right, just as HHH trying to claim that its answer is based on the
>> fact that it can't reach the end of its simulation of the input isn't
>> the correct requirement for HHH.
>>
>>>
>>> Like sum(3,2) HHH(DD) is only allowed to report
>>> on the behavior that its input actually specifies.
>>>
>>
>> Right, which is Halting, since that behavior is DEFINED to be the
>> behavior of running the program the input represents.
>>
>
> Just like requiring sum(3,2) to report on the sum of 5 + 7
> a value other than its input specifies HHH IS NOT ALLOWED
> to report on anything other than the behavior that its input
> specifies.
>
> Its input specifies that it calls HHH(DD) in recursive
> emulation. THIS CANNOT BE IGNORED.
>
No it doesn't, it calls HHH, which does what it does. Since your decider
HHH is defined to abort and return 0, so is the HHH that DD calls, since
it was built from that machine.
What we can not ignore is that HHH has a definition, and HHH needs to
interprete the call in DD by that definition, not you LIE that HHH is
just a correct simulator, since it isn't.
Sorry, you are the one that is choosing to ignore the input and replace
it with somethng it isn't, becaue you don't understand that you did
define it when you created your HHH to abort and return 0.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-08 20:55 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvjnb4$28g5i$10@dont-email.me> |
| In reply to | #118078 |
On 5/8/2025 8:18 PM, Richard Damon wrote:
> On 5/8/25 7:48 PM, olcott wrote:
>> On 5/8/2025 6:35 PM, Richard Damon wrote:
>>> On 5/8/25 1:00 PM, olcott wrote:
>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>
>>>>>>>> Let's take a look.
>>>>>>>>
>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>
>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>
>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>> {
>>>>>>>> u32 size;
>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>> ;
>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>> {
>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>> *destination[N] = source[N];
>>>>>>>> }
>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>> };
>>>>>>>>
>>>>>>>
>>>>>>> deprecated.
>>>>>>
>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>
>>>>>> Everybody makes mistakes, and one slip would be all very well, but
>>>>>> you make essentially the same mistake --- writing to memory that
>>>>>> your program doesn't own --- no fewer than four times in a single
>>>>>> function.
>>>>>>
>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>> a rookie error).
>>>>>>>>
>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>
>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>
>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>
>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>
>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>
>>>>>>>> We go on:
>>>>>>>>
>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>> {
>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>> *destination[N] = source[N];
>>>>>>>> }
>>>>>>>>
>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>
>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>> pity's sake.
>>>>>>>>
>>>>>>>
>>>>>>> If you can't even understand what is essentially
>>>>>>> an infinite recursive relationship between two functions
>>>>>>> except that one function can terminate the other then
>>>>>>> you don't have a clue about the essence of my system.
>>>>>>
>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>> anyone anything about C.
>>>>>>
>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>
>>>>>> When you publish code like that, to even *think* about denigrating
>>>>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>>>>
>>>>> One problem here is that you don't understand how PO's code works.
>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>> so blamewise it's really down to PO.
>>>>>
>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>> execution environment. x87utm provides a number of primative calls
>>>>> that halt7.c code can make, such as Allocate(), used to allocate a
>>>>> block of memory for use in halt7.c. Within halt7.c code calls an
>>>>> Allocate() function, and x86utm intercepts that and performs the
>>>>> function internally, then jumps the calling code in halt7.c over
>>>>> the Allocate call where it continues as normal. The call never
>>>>> goes to the implementation of Allocate in halt7.c, so the null
>>>>> pointer dereferencing does not actually occur. There are a whole
>>>>> bunch of similar x86utm primitive operations that work in the same
>>>>> way.
>>>>>
>>>>> PO should have said all that, not me, but it seems he's not
>>>>> interested in genuine communication.
>>>>>
>>>>> Mike.
>>>>>
>>>>>
>>>>
>>>> Thanks for those details, they are correct.
>>>> I try to stay focused on the key essence gist
>>>> of the issue and never delve down into the weeds.
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> The key gist of the issue (no weeds involved)
>>>> is that HHH emulated DD according to the rules
>>>> of the x86 language
>>>
>>> Excpet, as you have admitted, your DD isn't a program (just a C
>>> funciton), and thus not a proper input for a halt decider, which by
>>> definiton must be a program.
>>>
>>> Your C function can't be a program, as you have specifically said
>>> that the function, and only the funciton is the input, and programs
>>> must include in them all their code, so since the code of HHH isn't
>>> included in DD or the input representing it, it isn't a program, and
>>> thus not a proper input
>>>
>>>>
>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>> *until H correctly determines that*
>>>> *its simulated D would never stop running unless aborted*
>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>
>>>
>>> But that statement implies, as required that H be a halt decider and
>>> D to be a proper input to one, neither of which are satisfied, as you
>>> have admitte
>>>
>>>> When HHH(DD) computes the actual mapping from
>>>> its actual input to the actual behavior this
>>>> it specifies it must be according to the rules
>>>> of the x86 language.
>>>
>>> But it doesn't, as it doesn't correctly follow the behavior of the
>>> x86 language, as that requires HHH to follow the call instruction,
>>> which it can not do as the required (and accepted by your) condition
>>> that the decider is a pure function, which means it can only look at
>>> its input, which does not include the code which the call points to.
>>>
>>>>
>>>> int sum(int x, int y) { return x + y; }
>>>> sum is required to compute the mapping
>>>> from its input into its return value
>>>> according to the rules of arithmetic.
>>>
>>> Right, and a halt decider is required to (try to) compute the mapping
>>> from the input (which needs to be the representation of a program) to
>>> the results of running that program (since that is the DEFINITION of
>>> Halt Deciding).
>>>
>>>>
>>>> This means that requiring sum(3,2) to return
>>>> the sum of 5 + 7 is an incorrect requirement.
>>>
>>> Right, just as HHH trying to claim that its answer is based on the
>>> fact that it can't reach the end of its simulation of the input isn't
>>> the correct requirement for HHH.
>>>
>>>>
>>>> Like sum(3,2) HHH(DD) is only allowed to report
>>>> on the behavior that its input actually specifies.
>>>>
>>>
>>> Right, which is Halting, since that behavior is DEFINED to be the
>>> behavior of running the program the input represents.
>>>
>>
>> Just like requiring sum(3,2) to report on the sum of 5 + 7
>> a value other than its input specifies HHH IS NOT ALLOWED
>> to report on anything other than the behavior that its input
>> specifies.
>>
>> Its input specifies that it calls HHH(DD) in recursive
>> emulation. THIS CANNOT BE IGNORED.
>>
>
> No it doesn't, it calls HHH, which does what it does. Since your decider
> HHH is defined to abort and return 0, so is the HHH that DD calls, since
> it was built from that machine.
>
> What we can not ignore is that HHH has a definition, and HHH needs to
> interprete the call in DD by that definition, not you LIE that HHH is
> just a correct simulator, since it isn't.
>
> Sorry, you are the one that is choosing to ignore the input and replace
> it with somethng it isn't, becaue you don't understand that you did
> define it when you created your HHH to abort and return 0.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
For every HHH that can possibly exist at machine address
000015d2 that correctly emulates 1 or more x86 instructions
of DDD (the exact machine code bytes specified above) no
correctly emulated DDD ever reaches their own "return"
instruction.
This may simply be too difficult for most everyone here.
Instead of simply saying they they don't understand the
x86 language they try to deflect away from this subject
to try to hide their own ignorance.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-08 22:26 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <39fd7f30194076f71af0ba9009f92a7a87cfaf2a@i2pn2.org> |
| In reply to | #118084 |
On 5/8/25 9:55 PM, olcott wrote:
> On 5/8/2025 8:18 PM, Richard Damon wrote:
>> On 5/8/25 7:48 PM, olcott wrote:
>>> On 5/8/2025 6:35 PM, Richard Damon wrote:
>>>> On 5/8/25 1:00 PM, olcott wrote:
>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>>
>>>>>>>>> Let's take a look.
>>>>>>>>>
>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>>
>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>
>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>> {
>>>>>>>>> u32 size;
>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>> ;
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> deprecated.
>>>>>>>
>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>
>>>>>>> Everybody makes mistakes, and one slip would be all very well,
>>>>>>> but you make essentially the same mistake --- writing to memory
>>>>>>> that your program doesn't own --- no fewer than four times in a
>>>>>>> single function.
>>>>>>>
>>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>>> a rookie error).
>>>>>>>>>
>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>
>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>
>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>
>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>>
>>>>>>>>> We go on:
>>>>>>>>>
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>
>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>>> pity's sake.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you can't even understand what is essentially
>>>>>>>> an infinite recursive relationship between two functions
>>>>>>>> except that one function can terminate the other then
>>>>>>>> you don't have a clue about the essence of my system.
>>>>>>>
>>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>>> anyone anything about C.
>>>>>>>
>>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>>
>>>>>>> When you publish code like that, to even *think* about
>>>>>>> denigrating other people's C knowledge is the height of arrogant
>>>>>>> hypocrisy.
>>>>>>>
>>>>>> One problem here is that you don't understand how PO's code works.
>>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>>> so blamewise it's really down to PO.
>>>>>>
>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>>> execution environment. x87utm provides a number of primative
>>>>>> calls that halt7.c code can make, such as Allocate(), used to
>>>>>> allocate a block of memory for use in halt7.c. Within halt7.c
>>>>>> code calls an Allocate() function, and x86utm intercepts that and
>>>>>> performs the function internally, then jumps the calling code in
>>>>>> halt7.c over the Allocate call where it continues as normal. The
>>>>>> call never goes to the implementation of Allocate in halt7.c, so
>>>>>> the null pointer dereferencing does not actually occur. There are
>>>>>> a whole bunch of similar x86utm primitive operations that work in
>>>>>> the same way.
>>>>>>
>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>> interested in genuine communication.
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks for those details, they are correct.
>>>>> I try to stay focused on the key essence gist
>>>>> of the issue and never delve down into the weeds.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> The key gist of the issue (no weeds involved)
>>>>> is that HHH emulated DD according to the rules
>>>>> of the x86 language
>>>>
>>>> Excpet, as you have admitted, your DD isn't a program (just a C
>>>> funciton), and thus not a proper input for a halt decider, which by
>>>> definiton must be a program.
>>>>
>>>> Your C function can't be a program, as you have specifically said
>>>> that the function, and only the funciton is the input, and programs
>>>> must include in them all their code, so since the code of HHH isn't
>>>> included in DD or the input representing it, it isn't a program, and
>>>> thus not a proper input
>>>>
>>>>>
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> *until H correctly determines that*
>>>>> *its simulated D would never stop running unless aborted*
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>
>>>>
>>>> But that statement implies, as required that H be a halt decider and
>>>> D to be a proper input to one, neither of which are satisfied, as
>>>> you have admitte
>>>>
>>>>> When HHH(DD) computes the actual mapping from
>>>>> its actual input to the actual behavior this
>>>>> it specifies it must be according to the rules
>>>>> of the x86 language.
>>>>
>>>> But it doesn't, as it doesn't correctly follow the behavior of the
>>>> x86 language, as that requires HHH to follow the call instruction,
>>>> which it can not do as the required (and accepted by your) condition
>>>> that the decider is a pure function, which means it can only look at
>>>> its input, which does not include the code which the call points to.
>>>>
>>>>>
>>>>> int sum(int x, int y) { return x + y; }
>>>>> sum is required to compute the mapping
>>>>> from its input into its return value
>>>>> according to the rules of arithmetic.
>>>>
>>>> Right, and a halt decider is required to (try to) compute the
>>>> mapping from the input (which needs to be the representation of a
>>>> program) to the results of running that program (since that is the
>>>> DEFINITION of Halt Deciding).
>>>>
>>>>>
>>>>> This means that requiring sum(3,2) to return
>>>>> the sum of 5 + 7 is an incorrect requirement.
>>>>
>>>> Right, just as HHH trying to claim that its answer is based on the
>>>> fact that it can't reach the end of its simulation of the input
>>>> isn't the correct requirement for HHH.
>>>>
>>>>>
>>>>> Like sum(3,2) HHH(DD) is only allowed to report
>>>>> on the behavior that its input actually specifies.
>>>>>
>>>>
>>>> Right, which is Halting, since that behavior is DEFINED to be the
>>>> behavior of running the program the input represents.
>>>>
>>>
>>> Just like requiring sum(3,2) to report on the sum of 5 + 7
>>> a value other than its input specifies HHH IS NOT ALLOWED
>>> to report on anything other than the behavior that its input
>>> specifies.
>>>
>>> Its input specifies that it calls HHH(DD) in recursive
>>> emulation. THIS CANNOT BE IGNORED.
>>>
>>
>> No it doesn't, it calls HHH, which does what it does. Since your
>> decider HHH is defined to abort and return 0, so is the HHH that DD
>> calls, since it was built from that machine.
>>
>> What we can not ignore is that HHH has a definition, and HHH needs to
>> interprete the call in DD by that definition, not you LIE that HHH is
>> just a correct simulator, since it isn't.
>>
>> Sorry, you are the one that is choosing to ignore the input and
>> replace it with somethng it isn't, becaue you don't understand that
>> you did define it when you created your HHH to abort and return 0.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> For every HHH that can possibly exist at machine address
> 000015d2 that correctly emulates 1 or more x86 instructions
> of DDD (the exact machine code bytes specified above) no
> correctly emulated DDD ever reaches their own "return"
> instruction.
Since the input doesn't include the code at 000015d2, no HHH that
emulates past the call instruction is a correct program per the
definition of computaiton theory, as it depends on things that are not
its input.
>
> This may simply be too difficult for most everyone here.
> Instead of simply saying they they don't understand the
> x86 language they try to deflect away from this subject
> to try to hide their own ignorance.
>
No, you are just proving that you don't understand the meaning of your
words.
If you want to change the domain to x86 programs, and that HHH and DD
are all part of one program, then you might be able to show that no
program that has a HHH that acts the way you describe every reaches the
return instruction.
Tbhis does NOT say that the "input" is non-halting, as that is a
Computation Theory Term, and not applicable here.
It is still the fact, that by the definition of the Halting Problem,
even when broght into this computation realm, the DEFINITION of a Halt
Decider is, and only is, that it must answer about the behavior of the
directly called program defined by the input.
Since if HHH(DD) return 0, that fact that no HHH emulated its input to a
final state is just an irrelevent fact, the direct execution of the
input returns, and thus is halting.
All you are doing is proving that you can't keep a fact straight, and
your habit is to change statements into lies and false statement,
because you are just a pathoological liar.
Your strawman in irrelvent, becuase the Halting Criteria is clearly
Stated, and anything else which gives a different answer can't be the
equivalent to it.
Unless of course, you are just trying to show that in your mind, every
thing is just lies that you beleive.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-09 11:28 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvkhrq$2m36t$9@dont-email.me> |
| In reply to | #118084 |
Op 09.mei.2025 om 03:55 schreef olcott:
> On 5/8/2025 8:18 PM, Richard Damon wrote:
>> On 5/8/25 7:48 PM, olcott wrote:
>>> On 5/8/2025 6:35 PM, Richard Damon wrote:
>>>> On 5/8/25 1:00 PM, olcott wrote:
>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>>
>>>>>>>>> Let's take a look.
>>>>>>>>>
>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>>
>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>
>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>> {
>>>>>>>>> u32 size;
>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>> ;
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> deprecated.
>>>>>>>
>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>
>>>>>>> Everybody makes mistakes, and one slip would be all very well,
>>>>>>> but you make essentially the same mistake --- writing to memory
>>>>>>> that your program doesn't own --- no fewer than four times in a
>>>>>>> single function.
>>>>>>>
>>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>>> a rookie error).
>>>>>>>>>
>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>
>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>
>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>
>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>>
>>>>>>>>> We go on:
>>>>>>>>>
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>
>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>>> pity's sake.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you can't even understand what is essentially
>>>>>>>> an infinite recursive relationship between two functions
>>>>>>>> except that one function can terminate the other then
>>>>>>>> you don't have a clue about the essence of my system.
>>>>>>>
>>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>>> anyone anything about C.
>>>>>>>
>>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>>
>>>>>>> When you publish code like that, to even *think* about
>>>>>>> denigrating other people's C knowledge is the height of arrogant
>>>>>>> hypocrisy.
>>>>>>>
>>>>>> One problem here is that you don't understand how PO's code works.
>>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>>> so blamewise it's really down to PO.
>>>>>>
>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>>> execution environment. x87utm provides a number of primative
>>>>>> calls that halt7.c code can make, such as Allocate(), used to
>>>>>> allocate a block of memory for use in halt7.c. Within halt7.c
>>>>>> code calls an Allocate() function, and x86utm intercepts that and
>>>>>> performs the function internally, then jumps the calling code in
>>>>>> halt7.c over the Allocate call where it continues as normal. The
>>>>>> call never goes to the implementation of Allocate in halt7.c, so
>>>>>> the null pointer dereferencing does not actually occur. There are
>>>>>> a whole bunch of similar x86utm primitive operations that work in
>>>>>> the same way.
>>>>>>
>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>> interested in genuine communication.
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks for those details, they are correct.
>>>>> I try to stay focused on the key essence gist
>>>>> of the issue and never delve down into the weeds.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> The key gist of the issue (no weeds involved)
>>>>> is that HHH emulated DD according to the rules
>>>>> of the x86 language
>>>>
>>>> Excpet, as you have admitted, your DD isn't a program (just a C
>>>> funciton), and thus not a proper input for a halt decider, which by
>>>> definiton must be a program.
>>>>
>>>> Your C function can't be a program, as you have specifically said
>>>> that the function, and only the funciton is the input, and programs
>>>> must include in them all their code, so since the code of HHH isn't
>>>> included in DD or the input representing it, it isn't a program, and
>>>> thus not a proper input
>>>>
>>>>>
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> *until H correctly determines that*
>>>>> *its simulated D would never stop running unless aborted*
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>
>>>>
>>>> But that statement implies, as required that H be a halt decider and
>>>> D to be a proper input to one, neither of which are satisfied, as
>>>> you have admitte
>>>>
>>>>> When HHH(DD) computes the actual mapping from
>>>>> its actual input to the actual behavior this
>>>>> it specifies it must be according to the rules
>>>>> of the x86 language.
>>>>
>>>> But it doesn't, as it doesn't correctly follow the behavior of the
>>>> x86 language, as that requires HHH to follow the call instruction,
>>>> which it can not do as the required (and accepted by your) condition
>>>> that the decider is a pure function, which means it can only look at
>>>> its input, which does not include the code which the call points to.
>>>>
>>>>>
>>>>> int sum(int x, int y) { return x + y; }
>>>>> sum is required to compute the mapping
>>>>> from its input into its return value
>>>>> according to the rules of arithmetic.
>>>>
>>>> Right, and a halt decider is required to (try to) compute the
>>>> mapping from the input (which needs to be the representation of a
>>>> program) to the results of running that program (since that is the
>>>> DEFINITION of Halt Deciding).
>>>>
>>>>>
>>>>> This means that requiring sum(3,2) to return
>>>>> the sum of 5 + 7 is an incorrect requirement.
>>>>
>>>> Right, just as HHH trying to claim that its answer is based on the
>>>> fact that it can't reach the end of its simulation of the input
>>>> isn't the correct requirement for HHH.
>>>>
>>>>>
>>>>> Like sum(3,2) HHH(DD) is only allowed to report
>>>>> on the behavior that its input actually specifies.
>>>>>
>>>>
>>>> Right, which is Halting, since that behavior is DEFINED to be the
>>>> behavior of running the program the input represents.
>>>>
>>>
>>> Just like requiring sum(3,2) to report on the sum of 5 + 7
>>> a value other than its input specifies HHH IS NOT ALLOWED
>>> to report on anything other than the behavior that its input
>>> specifies.
>>>
>>> Its input specifies that it calls HHH(DD) in recursive
>>> emulation. THIS CANNOT BE IGNORED.
>>>
>>
>> No it doesn't, it calls HHH, which does what it does. Since your
>> decider HHH is defined to abort and return 0, so is the HHH that DD
>> calls, since it was built from that machine.
>>
>> What we can not ignore is that HHH has a definition, and HHH needs to
>> interprete the call in DD by that definition, not you LIE that HHH is
>> just a correct simulator, since it isn't.
>>
>> Sorry, you are the one that is choosing to ignore the input and
>> replace it with somethng it isn't, becaue you don't understand that
>> you did define it when you created your HHH to abort and return 0.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> For every HHH that can possibly exist at machine address
> 000015d2 that correctly emulates 1 or more x86 instructions
> of DDD (the exact machine code bytes specified above) no
> correctly emulated DDD ever reaches their own "return"
> instruction.
>
> This may simply be too difficult for most everyone here.
> Instead of simply saying they they don't understand the
> x86 language they try to deflect away from this subject
> to try to hide their own ignorance.
Nobody disagreed with it, we all see that HHH fails to reach the
'return', because it prematurely aborts and is made blind for
conditional abort in the input.
This has been pointed out many times, but seems to disturb your dreams
so much that you unconsciously decide to ignore it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 11:13 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl9je$2rl0l$18@dont-email.me> |
| In reply to | #118126 |
On 5/9/2025 4:28 AM, Fred. Zwarts wrote:
> Op 09.mei.2025 om 03:55 schreef olcott:
>> On 5/8/2025 8:18 PM, Richard Damon wrote:
>>> On 5/8/25 7:48 PM, olcott wrote:
>>>> On 5/8/2025 6:35 PM, Richard Damon wrote:
>>>>> On 5/8/25 1:00 PM, olcott wrote:
>>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>>>
>>>>>>>>>> Let's take a look.
>>>>>>>>>>
>>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan
>>>>>>>>>> to stop at HHH's first departure from the rules of the C
>>>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>>>
>>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>>
>>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>>> {
>>>>>>>>>> u32 size;
>>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>>> ;
>>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>>> {
>>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>>> *destination[N] = source[N];
>>>>>>>>>> }
>>>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> deprecated.
>>>>>>>>
>>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>>
>>>>>>>> Everybody makes mistakes, and one slip would be all very well,
>>>>>>>> but you make essentially the same mistake --- writing to memory
>>>>>>>> that your program doesn't own --- no fewer than four times in a
>>>>>>>> single function.
>>>>>>>>
>>>>>>>>>> I'll ignore the syntax error (a null statement at file scope
>>>>>>>>>> is a rookie error).
>>>>>>>>>>
>>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>>
>>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>>
>>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>>
>>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>>
>>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>>>
>>>>>>>>>> We go on:
>>>>>>>>>>
>>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>>> {
>>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>>> *destination[N] = source[N];
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> *destination[N] is our first big problem (we're ignoring
>>>>>>>>>> syntax errors, remember). destination is a null pointer, so
>>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>>
>>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>>>> pity's sake.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you can't even understand what is essentially
>>>>>>>>> an infinite recursive relationship between two functions
>>>>>>>>> except that one function can terminate the other then
>>>>>>>>> you don't have a clue about the essence of my system.
>>>>>>>>
>>>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>>>> anyone anything about C.
>>>>>>>>
>>>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>>>
>>>>>>>> When you publish code like that, to even *think* about
>>>>>>>> denigrating other people's C knowledge is the height of arrogant
>>>>>>>> hypocrisy.
>>>>>>>>
>>>>>>> One problem here is that you don't understand how PO's code
>>>>>>> works. That's to be expected, and PO's response ought to be to
>>>>>>> explain it so that you understand. Instead he goes off on one of
>>>>>>> his rants, so blamewise it's really down to PO.
>>>>>>>
>>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>>>> execution environment. x87utm provides a number of primative
>>>>>>> calls that halt7.c code can make, such as Allocate(), used to
>>>>>>> allocate a block of memory for use in halt7.c. Within halt7.c
>>>>>>> code calls an Allocate() function, and x86utm intercepts that and
>>>>>>> performs the function internally, then jumps the calling code in
>>>>>>> halt7.c over the Allocate call where it continues as normal. The
>>>>>>> call never goes to the implementation of Allocate in halt7.c, so
>>>>>>> the null pointer dereferencing does not actually occur. There
>>>>>>> are a whole bunch of similar x86utm primitive operations that
>>>>>>> work in the same way.
>>>>>>>
>>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>>> interested in genuine communication.
>>>>>>>
>>>>>>> Mike.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks for those details, they are correct.
>>>>>> I try to stay focused on the key essence gist
>>>>>> of the issue and never delve down into the weeds.
>>>>>>
>>>>>> int DD()
>>>>>> {
>>>>>> int Halt_Status = HHH(DD);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> The key gist of the issue (no weeds involved)
>>>>>> is that HHH emulated DD according to the rules
>>>>>> of the x86 language
>>>>>
>>>>> Excpet, as you have admitted, your DD isn't a program (just a C
>>>>> funciton), and thus not a proper input for a halt decider, which by
>>>>> definiton must be a program.
>>>>>
>>>>> Your C function can't be a program, as you have specifically said
>>>>> that the function, and only the funciton is the input, and programs
>>>>> must include in them all their code, so since the code of HHH isn't
>>>>> included in DD or the input representing it, it isn't a program,
>>>>> and thus not a proper input
>>>>>
>>>>>>
>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>> *until H correctly determines that*
>>>>>> *its simulated D would never stop running unless aborted*
>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>> 10/13/2022>
>>>>>>
>>>>>
>>>>> But that statement implies, as required that H be a halt decider
>>>>> and D to be a proper input to one, neither of which are satisfied,
>>>>> as you have admitte
>>>>>
>>>>>> When HHH(DD) computes the actual mapping from
>>>>>> its actual input to the actual behavior this
>>>>>> it specifies it must be according to the rules
>>>>>> of the x86 language.
>>>>>
>>>>> But it doesn't, as it doesn't correctly follow the behavior of the
>>>>> x86 language, as that requires HHH to follow the call instruction,
>>>>> which it can not do as the required (and accepted by your)
>>>>> condition that the decider is a pure function, which means it can
>>>>> only look at its input, which does not include the code which the
>>>>> call points to.
>>>>>
>>>>>>
>>>>>> int sum(int x, int y) { return x + y; }
>>>>>> sum is required to compute the mapping
>>>>>> from its input into its return value
>>>>>> according to the rules of arithmetic.
>>>>>
>>>>> Right, and a halt decider is required to (try to) compute the
>>>>> mapping from the input (which needs to be the representation of a
>>>>> program) to the results of running that program (since that is the
>>>>> DEFINITION of Halt Deciding).
>>>>>
>>>>>>
>>>>>> This means that requiring sum(3,2) to return
>>>>>> the sum of 5 + 7 is an incorrect requirement.
>>>>>
>>>>> Right, just as HHH trying to claim that its answer is based on the
>>>>> fact that it can't reach the end of its simulation of the input
>>>>> isn't the correct requirement for HHH.
>>>>>
>>>>>>
>>>>>> Like sum(3,2) HHH(DD) is only allowed to report
>>>>>> on the behavior that its input actually specifies.
>>>>>>
>>>>>
>>>>> Right, which is Halting, since that behavior is DEFINED to be the
>>>>> behavior of running the program the input represents.
>>>>>
>>>>
>>>> Just like requiring sum(3,2) to report on the sum of 5 + 7
>>>> a value other than its input specifies HHH IS NOT ALLOWED
>>>> to report on anything other than the behavior that its input
>>>> specifies.
>>>>
>>>> Its input specifies that it calls HHH(DD) in recursive
>>>> emulation. THIS CANNOT BE IGNORED.
>>>>
>>>
>>> No it doesn't, it calls HHH, which does what it does. Since your
>>> decider HHH is defined to abort and return 0, so is the HHH that DD
>>> calls, since it was built from that machine.
>>>
>>> What we can not ignore is that HHH has a definition, and HHH needs to
>>> interprete the call in DD by that definition, not you LIE that HHH is
>>> just a correct simulator, since it isn't.
>>>
>>> Sorry, you are the one that is choosing to ignore the input and
>>> replace it with somethng it isn't, becaue you don't understand that
>>> you did define it when you created your HHH to abort and return 0.
>>
>> void DDD()
>> {
>> HHH(DDD);
>> return;
>> }
>>
>> _DDD()
>> [00002172] 55 push ebp ; housekeeping
>> [00002173] 8bec mov ebp,esp ; housekeeping
>> [00002175] 6872210000 push 00002172 ; push DDD
>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>> [0000217f] 83c404 add esp,+04
>> [00002182] 5d pop ebp
>> [00002183] c3 ret
>> Size in bytes:(0018) [00002183]
>>
>> For every HHH that can possibly exist at machine address
>> 000015d2 that correctly emulates 1 or more x86 instructions
>> of DDD (the exact machine code bytes specified above) no
>> correctly emulated DDD ever reaches their own "return"
>> instruction.
>>
>> This may simply be too difficult for most everyone here.
>> Instead of simply saying they they don't understand the
>> x86 language they try to deflect away from this subject
>> to try to hide their own ignorance.
> Nobody disagreed with it, we all see that HHH fails to reach the
> 'return', because it prematurely aborts
*That remains counter-factual because this is true*
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 14:33 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <5a1e2e69bfac644b43d7fbd33aa689f50dde7d6d@i2pn2.org> |
| In reply to | #118156 |
On 5/9/25 12:13 PM, olcott wrote:
> On 5/9/2025 4:28 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 03:55 schreef olcott:
>>> On 5/8/2025 8:18 PM, Richard Damon wrote:
>>>> On 5/8/25 7:48 PM, olcott wrote:
>>>>> On 5/8/2025 6:35 PM, Richard Damon wrote:
>>>>>> On 5/8/25 1:00 PM, olcott wrote:
>>>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> <snip>
>>>>>>>>>>>
>>>>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>>>>
>>>>>>>>>>> Let's take a look.
>>>>>>>>>>>
>>>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan
>>>>>>>>>>> to stop at HHH's first departure from the rules of the C
>>>>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>>>>
>>>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>>>
>>>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>>>> {
>>>>>>>>>>> u32 size;
>>>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>>>> ;
>>>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>>>> {
>>>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>>>> *destination[N] = source[N];
>>>>>>>>>>> }
>>>>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>>>> };
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> deprecated.
>>>>>>>>>
>>>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>>>
>>>>>>>>> Everybody makes mistakes, and one slip would be all very well,
>>>>>>>>> but you make essentially the same mistake --- writing to memory
>>>>>>>>> that your program doesn't own --- no fewer than four times in a
>>>>>>>>> single function.
>>>>>>>>>
>>>>>>>>>>> I'll ignore the syntax error (a null statement at file scope
>>>>>>>>>>> is a rookie error).
>>>>>>>>>>>
>>>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>>>
>>>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>>>
>>>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>>>
>>>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>>>
>>>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a
>>>>>>>>>>> null pointer constant... which is fine as long as you don't
>>>>>>>>>>> try to deref it. So now *destination is NULL.
>>>>>>>>>>>
>>>>>>>>>>> We go on:
>>>>>>>>>>>
>>>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>>>> {
>>>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>>>> *destination[N] = source[N];
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> *destination[N] is our first big problem (we're ignoring
>>>>>>>>>>> syntax errors, remember). destination is a null pointer, so
>>>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>>>
>>>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And
>>>>>>>>>>> you / dare/ to impugn other people's C knowledge! Crack a
>>>>>>>>>>> book, for pity's sake.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If you can't even understand what is essentially
>>>>>>>>>> an infinite recursive relationship between two functions
>>>>>>>>>> except that one function can terminate the other then
>>>>>>>>>> you don't have a clue about the essence of my system.
>>>>>>>>>
>>>>>>>>> If you can't even understand why it's a stupendously bad idea
>>>>>>>>> to dereference a null pointer, you have no business trying to
>>>>>>>>> teach anyone anything about C.
>>>>>>>>>
>>>>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>>>>
>>>>>>>>> When you publish code like that, to even *think* about
>>>>>>>>> denigrating other people's C knowledge is the height of
>>>>>>>>> arrogant hypocrisy.
>>>>>>>>>
>>>>>>>> One problem here is that you don't understand how PO's code
>>>>>>>> works. That's to be expected, and PO's response ought to be to
>>>>>>>> explain it so that you understand. Instead he goes off on one
>>>>>>>> of his rants, so blamewise it's really down to PO.
>>>>>>>>
>>>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file
>>>>>>>> is fed as input to his x87utm.exe which is a kind of x86 obj
>>>>>>>> code execution environment. x87utm provides a number of
>>>>>>>> primative calls that halt7.c code can make, such as Allocate(),
>>>>>>>> used to allocate a block of memory for use in halt7.c. Within
>>>>>>>> halt7.c code calls an Allocate() function, and x86utm intercepts
>>>>>>>> that and performs the function internally, then jumps the
>>>>>>>> calling code in halt7.c over the Allocate call where it
>>>>>>>> continues as normal. The call never goes to the implementation
>>>>>>>> of Allocate in halt7.c, so the null pointer dereferencing does
>>>>>>>> not actually occur. There are a whole bunch of similar x86utm
>>>>>>>> primitive operations that work in the same way.
>>>>>>>>
>>>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>>>> interested in genuine communication.
>>>>>>>>
>>>>>>>> Mike.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Thanks for those details, they are correct.
>>>>>>> I try to stay focused on the key essence gist
>>>>>>> of the issue and never delve down into the weeds.
>>>>>>>
>>>>>>> int DD()
>>>>>>> {
>>>>>>> int Halt_Status = HHH(DD);
>>>>>>> if (Halt_Status)
>>>>>>> HERE: goto HERE;
>>>>>>> return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>> The key gist of the issue (no weeds involved)
>>>>>>> is that HHH emulated DD according to the rules
>>>>>>> of the x86 language
>>>>>>
>>>>>> Excpet, as you have admitted, your DD isn't a program (just a C
>>>>>> funciton), and thus not a proper input for a halt decider, which
>>>>>> by definiton must be a program.
>>>>>>
>>>>>> Your C function can't be a program, as you have specifically said
>>>>>> that the function, and only the funciton is the input, and
>>>>>> programs must include in them all their code, so since the code of
>>>>>> HHH isn't included in DD or the input representing it, it isn't a
>>>>>> program, and thus not a proper input
>>>>>>
>>>>>>>
>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>>> 10/13/2022>
>>>>>>> *until H correctly determines that*
>>>>>>> *its simulated D would never stop running unless aborted*
>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words
>>>>>>> 10/13/2022>
>>>>>>>
>>>>>>
>>>>>> But that statement implies, as required that H be a halt decider
>>>>>> and D to be a proper input to one, neither of which are satisfied,
>>>>>> as you have admitte
>>>>>>
>>>>>>> When HHH(DD) computes the actual mapping from
>>>>>>> its actual input to the actual behavior this
>>>>>>> it specifies it must be according to the rules
>>>>>>> of the x86 language.
>>>>>>
>>>>>> But it doesn't, as it doesn't correctly follow the behavior of the
>>>>>> x86 language, as that requires HHH to follow the call instruction,
>>>>>> which it can not do as the required (and accepted by your)
>>>>>> condition that the decider is a pure function, which means it can
>>>>>> only look at its input, which does not include the code which the
>>>>>> call points to.
>>>>>>
>>>>>>>
>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>> sum is required to compute the mapping
>>>>>>> from its input into its return value
>>>>>>> according to the rules of arithmetic.
>>>>>>
>>>>>> Right, and a halt decider is required to (try to) compute the
>>>>>> mapping from the input (which needs to be the representation of a
>>>>>> program) to the results of running that program (since that is the
>>>>>> DEFINITION of Halt Deciding).
>>>>>>
>>>>>>>
>>>>>>> This means that requiring sum(3,2) to return
>>>>>>> the sum of 5 + 7 is an incorrect requirement.
>>>>>>
>>>>>> Right, just as HHH trying to claim that its answer is based on the
>>>>>> fact that it can't reach the end of its simulation of the input
>>>>>> isn't the correct requirement for HHH.
>>>>>>
>>>>>>>
>>>>>>> Like sum(3,2) HHH(DD) is only allowed to report
>>>>>>> on the behavior that its input actually specifies.
>>>>>>>
>>>>>>
>>>>>> Right, which is Halting, since that behavior is DEFINED to be the
>>>>>> behavior of running the program the input represents.
>>>>>>
>>>>>
>>>>> Just like requiring sum(3,2) to report on the sum of 5 + 7
>>>>> a value other than its input specifies HHH IS NOT ALLOWED
>>>>> to report on anything other than the behavior that its input
>>>>> specifies.
>>>>>
>>>>> Its input specifies that it calls HHH(DD) in recursive
>>>>> emulation. THIS CANNOT BE IGNORED.
>>>>>
>>>>
>>>> No it doesn't, it calls HHH, which does what it does. Since your
>>>> decider HHH is defined to abort and return 0, so is the HHH that DD
>>>> calls, since it was built from that machine.
>>>>
>>>> What we can not ignore is that HHH has a definition, and HHH needs
>>>> to interprete the call in DD by that definition, not you LIE that
>>>> HHH is just a correct simulator, since it isn't.
>>>>
>>>> Sorry, you are the one that is choosing to ignore the input and
>>>> replace it with somethng it isn't, becaue you don't understand that
>>>> you did define it when you created your HHH to abort and return 0.
>>>
>>> void DDD()
>>> {
>>> HHH(DDD);
>>> return;
>>> }
>>>
>>> _DDD()
>>> [00002172] 55 push ebp ; housekeeping
>>> [00002173] 8bec mov ebp,esp ; housekeeping
>>> [00002175] 6872210000 push 00002172 ; push DDD
>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>> [0000217f] 83c404 add esp,+04
>>> [00002182] 5d pop ebp
>>> [00002183] c3 ret
>>> Size in bytes:(0018) [00002183]
>>>
>>> For every HHH that can possibly exist at machine address
>>> 000015d2 that correctly emulates 1 or more x86 instructions
>>> of DDD (the exact machine code bytes specified above) no
>>> correctly emulated DDD ever reaches their own "return"
>>> instruction.
>>>
>>> This may simply be too difficult for most everyone here.
>>> Instead of simply saying they they don't understand the
>>> x86 language they try to deflect away from this subject
>>> to try to hide their own ignorance.
>
>> Nobody disagreed with it, we all see that HHH fails to reach the
>> 'return', because it prematurely aborts
>
> *That remains counter-factual because this is true*
No, proven false elsewhere, no need to repeat as you just ignore the
truth and belive your own disproven lies.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> When 1 or more statements of DDD are correctly
> simulated by HHH then this correctly simulated
> DDD cannot possibly reach its own “return statement”.
>
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-09 11:25 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvkhma$2m36t$8@dont-email.me> |
| In reply to | #118065 |
Op 09.mei.2025 om 01:48 schreef olcott:
> On 5/8/2025 6:35 PM, Richard Damon wrote:
>> On 5/8/25 1:00 PM, olcott wrote:
>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>
>>>>>>> Let's take a look.
>>>>>>>
>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>> stop at HHH's first departure from the rules of the C programming
>>>>>>> language (or at least the first departure I spot).
>>>>>>>
>>>>>>> Turn in your songbook if you will to:
>>>>>>>
>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>> {
>>>>>>> u32 size;
>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>> ;
>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>> {
>>>>>>> Output("source[N]: ", source[N]);
>>>>>>> *destination[N] = source[N];
>>>>>>> }
>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>> ((u32*)*destination) [-1]);
>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>> ((u32*)*destination) [-2]);
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> deprecated.
>>>>>
>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>
>>>>> Everybody makes mistakes, and one slip would be all very well, but
>>>>> you make essentially the same mistake --- writing to memory that
>>>>> your program doesn't own --- no fewer than four times in a single
>>>>> function.
>>>>>
>>>>>>> I'll ignore the syntax error (a null statement at file scope is a
>>>>>>> rookie error).
>>>>>>>
>>>>>>> Instead, let's jump straight to this line:
>>>>>>>
>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>
>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>
>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>
>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>> deref it. So now *destination is NULL.
>>>>>>>
>>>>>>> We go on:
>>>>>>>
>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>> {
>>>>>>> Output("source[N]: ", source[N]);
>>>>>>> *destination[N] = source[N];
>>>>>>> }
>>>>>>>
>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>> destination[N] derefs a null pointer.
>>>>>>>
>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>> pity's sake.
>>>>>>>
>>>>>>
>>>>>> If you can't even understand what is essentially
>>>>>> an infinite recursive relationship between two functions
>>>>>> except that one function can terminate the other then
>>>>>> you don't have a clue about the essence of my system.
>>>>>
>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>> dereference a null pointer, you have no business trying to teach
>>>>> anyone anything about C.
>>>>>
>>>>> Your code is the work of a programmer so hideously incompetent that
>>>>> 'programmer' is scarcely a fair word to use.
>>>>>
>>>>> When you publish code like that, to even *think* about denigrating
>>>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>>>
>>>> One problem here is that you don't understand how PO's code works.
>>>> That's to be expected, and PO's response ought to be to explain it
>>>> so that you understand. Instead he goes off on one of his rants, so
>>>> blamewise it's really down to PO.
>>>>
>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>> execution environment. x87utm provides a number of primative calls
>>>> that halt7.c code can make, such as Allocate(), used to allocate a
>>>> block of memory for use in halt7.c. Within halt7.c code calls an
>>>> Allocate() function, and x86utm intercepts that and performs the
>>>> function internally, then jumps the calling code in halt7.c over the
>>>> Allocate call where it continues as normal. The call never goes to
>>>> the implementation of Allocate in halt7.c, so the null pointer
>>>> dereferencing does not actually occur. There are a whole bunch of
>>>> similar x86utm primitive operations that work in the same way.
>>>>
>>>> PO should have said all that, not me, but it seems he's not
>>>> interested in genuine communication.
>>>>
>>>> Mike.
>>>>
>>>>
>>>
>>> Thanks for those details, they are correct.
>>> I try to stay focused on the key essence gist
>>> of the issue and never delve down into the weeds.
>>>
>>> int DD()
>>> {
>>> int Halt_Status = HHH(DD);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> The key gist of the issue (no weeds involved)
>>> is that HHH emulated DD according to the rules
>>> of the x86 language
>>
>> Excpet, as you have admitted, your DD isn't a program (just a C
>> funciton), and thus not a proper input for a halt decider, which by
>> definiton must be a program.
>>
>> Your C function can't be a program, as you have specifically said that
>> the function, and only the funciton is the input, and programs must
>> include in them all their code, so since the code of HHH isn't
>> included in DD or the input representing it, it isn't a program, and
>> thus not a proper input
>>
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>> *until H correctly determines that*
>>> *its simulated D would never stop running unless aborted*
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>
>> But that statement implies, as required that H be a halt decider and D
>> to be a proper input to one, neither of which are satisfied, as you
>> have admitte
>>
>>> When HHH(DD) computes the actual mapping from
>>> its actual input to the actual behavior this
>>> it specifies it must be according to the rules
>>> of the x86 language.
>>
>> But it doesn't, as it doesn't correctly follow the behavior of the x86
>> language, as that requires HHH to follow the call instruction, which
>> it can not do as the required (and accepted by your) condition that
>> the decider is a pure function, which means it can only look at its
>> input, which does not include the code which the call points to.
>>
>>>
>>> int sum(int x, int y) { return x + y; }
>>> sum is required to compute the mapping
>>> from its input into its return value
>>> according to the rules of arithmetic.
>>
>> Right, and a halt decider is required to (try to) compute the mapping
>> from the input (which needs to be the representation of a program) to
>> the results of running that program (since that is the DEFINITION of
>> Halt Deciding).
>>
>>>
>>> This means that requiring sum(3,2) to return
>>> the sum of 5 + 7 is an incorrect requirement.
>>
>> Right, just as HHH trying to claim that its answer is based on the
>> fact that it can't reach the end of its simulation of the input isn't
>> the correct requirement for HHH.
>>
>>>
>>> Like sum(3,2) HHH(DD) is only allowed to report
>>> on the behavior that its input actually specifies.
>>>
>>
>> Right, which is Halting, since that behavior is DEFINED to be the
>> behavior of running the program the input represents.
>>
>
> Just like requiring sum(3,2) to report on the sum of 5 + 7
> a value other than its input specifies HHH IS NOT ALLOWED
> to report on anything other than the behavior that its input
> specifies.
>
Indeed, therefore HHH should process the actual input: including the HHH
that aborts, not the hypothetical HHH that does not abort.
Sum(3,2) should process the actual input, not the hypothetical input 5
and 7.
HHH should process all relevant input, including the part with the
conditional abort, not only the first part of the input.
Sum(3,2) should process all relevant input, not only the 2 and ignore the 3.
So, go and fix HHH.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-09 11:11 -0500 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvl9ga$2rl0l$17@dont-email.me> |
| In reply to | #118125 |
On 5/9/2025 4:25 AM, Fred. Zwarts wrote:
> Op 09.mei.2025 om 01:48 schreef olcott:
>> On 5/8/2025 6:35 PM, Richard Damon wrote:
>>> On 5/8/25 1:00 PM, olcott wrote:
>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>
>>>>>>>> Let's take a look.
>>>>>>>>
>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>
>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>
>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>> {
>>>>>>>> u32 size;
>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>> ;
>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>> {
>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>> *destination[N] = source[N];
>>>>>>>> }
>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>> };
>>>>>>>>
>>>>>>>
>>>>>>> deprecated.
>>>>>>
>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>
>>>>>> Everybody makes mistakes, and one slip would be all very well, but
>>>>>> you make essentially the same mistake --- writing to memory that
>>>>>> your program doesn't own --- no fewer than four times in a single
>>>>>> function.
>>>>>>
>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>> a rookie error).
>>>>>>>>
>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>
>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>
>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>
>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>
>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>
>>>>>>>> We go on:
>>>>>>>>
>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>> {
>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>> *destination[N] = source[N];
>>>>>>>> }
>>>>>>>>
>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>
>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>> pity's sake.
>>>>>>>>
>>>>>>>
>>>>>>> If you can't even understand what is essentially
>>>>>>> an infinite recursive relationship between two functions
>>>>>>> except that one function can terminate the other then
>>>>>>> you don't have a clue about the essence of my system.
>>>>>>
>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>> anyone anything about C.
>>>>>>
>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>
>>>>>> When you publish code like that, to even *think* about denigrating
>>>>>> other people's C knowledge is the height of arrogant hypocrisy.
>>>>>>
>>>>> One problem here is that you don't understand how PO's code works.
>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>> so blamewise it's really down to PO.
>>>>>
>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>> execution environment. x87utm provides a number of primative calls
>>>>> that halt7.c code can make, such as Allocate(), used to allocate a
>>>>> block of memory for use in halt7.c. Within halt7.c code calls an
>>>>> Allocate() function, and x86utm intercepts that and performs the
>>>>> function internally, then jumps the calling code in halt7.c over
>>>>> the Allocate call where it continues as normal. The call never
>>>>> goes to the implementation of Allocate in halt7.c, so the null
>>>>> pointer dereferencing does not actually occur. There are a whole
>>>>> bunch of similar x86utm primitive operations that work in the same
>>>>> way.
>>>>>
>>>>> PO should have said all that, not me, but it seems he's not
>>>>> interested in genuine communication.
>>>>>
>>>>> Mike.
>>>>>
>>>>>
>>>>
>>>> Thanks for those details, they are correct.
>>>> I try to stay focused on the key essence gist
>>>> of the issue and never delve down into the weeds.
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> The key gist of the issue (no weeds involved)
>>>> is that HHH emulated DD according to the rules
>>>> of the x86 language
>>>
>>> Excpet, as you have admitted, your DD isn't a program (just a C
>>> funciton), and thus not a proper input for a halt decider, which by
>>> definiton must be a program.
>>>
>>> Your C function can't be a program, as you have specifically said
>>> that the function, and only the funciton is the input, and programs
>>> must include in them all their code, so since the code of HHH isn't
>>> included in DD or the input representing it, it isn't a program, and
>>> thus not a proper input
>>>
>>>>
>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>> *until H correctly determines that*
>>>> *its simulated D would never stop running unless aborted*
>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>
>>>
>>> But that statement implies, as required that H be a halt decider and
>>> D to be a proper input to one, neither of which are satisfied, as you
>>> have admitte
>>>
>>>> When HHH(DD) computes the actual mapping from
>>>> its actual input to the actual behavior this
>>>> it specifies it must be according to the rules
>>>> of the x86 language.
>>>
>>> But it doesn't, as it doesn't correctly follow the behavior of the
>>> x86 language, as that requires HHH to follow the call instruction,
>>> which it can not do as the required (and accepted by your) condition
>>> that the decider is a pure function, which means it can only look at
>>> its input, which does not include the code which the call points to.
>>>
>>>>
>>>> int sum(int x, int y) { return x + y; }
>>>> sum is required to compute the mapping
>>>> from its input into its return value
>>>> according to the rules of arithmetic.
>>>
>>> Right, and a halt decider is required to (try to) compute the mapping
>>> from the input (which needs to be the representation of a program) to
>>> the results of running that program (since that is the DEFINITION of
>>> Halt Deciding).
>>>
>>>>
>>>> This means that requiring sum(3,2) to return
>>>> the sum of 5 + 7 is an incorrect requirement.
>>>
>>> Right, just as HHH trying to claim that its answer is based on the
>>> fact that it can't reach the end of its simulation of the input isn't
>>> the correct requirement for HHH.
>>>
>>>>
>>>> Like sum(3,2) HHH(DD) is only allowed to report
>>>> on the behavior that its input actually specifies.
>>>>
>>>
>>> Right, which is Halting, since that behavior is DEFINED to be the
>>> behavior of running the program the input represents.
>>>
>>
>> Just like requiring sum(3,2) to report on the sum of 5 + 7
>> a value other than its input specifies HHH IS NOT ALLOWED
>> to report on anything other than the behavior that its input
>> specifies.
>>
> Indeed, therefore HHH should process the actual input: including the HHH
> that aborts, not the hypothetical HHH that does not abort.
HHH cannot say to itself I have no need to abort
because I will abort later on. It either aborts
as soon as it recognizes the non terminating
pattern specified by itself input or no HHH ever aborts.
> Sum(3,2) should process the actual input, not the hypothetical input 5
> and 7.
> HHH should process all relevant input, including the part with the
> conditional abort, not only the first part of the input.
> Sum(3,2) should process all relevant input, not only the 2 and ignore
> the 3.
> So, go and fix HHH.
void DDD()
{
HHH(DDD);
return;
}
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state).
Reaching a final halt state means halting.
Unable to reach a final halt state means non-terminating.
Thus HHH(DDD) is correct to reject its finite input string
DDD as specifying a non-terminating sequence of configurations.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-09 14:34 -0400 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <662ad8aac76a63e58685230e5226e99452ea0f96@i2pn2.org> |
| In reply to | #118155 |
On 5/9/25 12:11 PM, olcott wrote:
> On 5/9/2025 4:25 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 01:48 schreef olcott:
>>> On 5/8/2025 6:35 PM, Richard Damon wrote:
>>>> On 5/8/25 1:00 PM, olcott wrote:
>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>>
>>>>>>>>> Let's take a look.
>>>>>>>>>
>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>>
>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>
>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>> {
>>>>>>>>> u32 size;
>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>> ;
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> deprecated.
>>>>>>>
>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>
>>>>>>> Everybody makes mistakes, and one slip would be all very well,
>>>>>>> but you make essentially the same mistake --- writing to memory
>>>>>>> that your program doesn't own --- no fewer than four times in a
>>>>>>> single function.
>>>>>>>
>>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>>> a rookie error).
>>>>>>>>>
>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>
>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>
>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>
>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>>
>>>>>>>>> We go on:
>>>>>>>>>
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>
>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>>> pity's sake.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you can't even understand what is essentially
>>>>>>>> an infinite recursive relationship between two functions
>>>>>>>> except that one function can terminate the other then
>>>>>>>> you don't have a clue about the essence of my system.
>>>>>>>
>>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>>> anyone anything about C.
>>>>>>>
>>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>>
>>>>>>> When you publish code like that, to even *think* about
>>>>>>> denigrating other people's C knowledge is the height of arrogant
>>>>>>> hypocrisy.
>>>>>>>
>>>>>> One problem here is that you don't understand how PO's code works.
>>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>>> so blamewise it's really down to PO.
>>>>>>
>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>>> execution environment. x87utm provides a number of primative
>>>>>> calls that halt7.c code can make, such as Allocate(), used to
>>>>>> allocate a block of memory for use in halt7.c. Within halt7.c
>>>>>> code calls an Allocate() function, and x86utm intercepts that and
>>>>>> performs the function internally, then jumps the calling code in
>>>>>> halt7.c over the Allocate call where it continues as normal. The
>>>>>> call never goes to the implementation of Allocate in halt7.c, so
>>>>>> the null pointer dereferencing does not actually occur. There are
>>>>>> a whole bunch of similar x86utm primitive operations that work in
>>>>>> the same way.
>>>>>>
>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>> interested in genuine communication.
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks for those details, they are correct.
>>>>> I try to stay focused on the key essence gist
>>>>> of the issue and never delve down into the weeds.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> The key gist of the issue (no weeds involved)
>>>>> is that HHH emulated DD according to the rules
>>>>> of the x86 language
>>>>
>>>> Excpet, as you have admitted, your DD isn't a program (just a C
>>>> funciton), and thus not a proper input for a halt decider, which by
>>>> definiton must be a program.
>>>>
>>>> Your C function can't be a program, as you have specifically said
>>>> that the function, and only the funciton is the input, and programs
>>>> must include in them all their code, so since the code of HHH isn't
>>>> included in DD or the input representing it, it isn't a program, and
>>>> thus not a proper input
>>>>
>>>>>
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> *until H correctly determines that*
>>>>> *its simulated D would never stop running unless aborted*
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>
>>>>
>>>> But that statement implies, as required that H be a halt decider and
>>>> D to be a proper input to one, neither of which are satisfied, as
>>>> you have admitte
>>>>
>>>>> When HHH(DD) computes the actual mapping from
>>>>> its actual input to the actual behavior this
>>>>> it specifies it must be according to the rules
>>>>> of the x86 language.
>>>>
>>>> But it doesn't, as it doesn't correctly follow the behavior of the
>>>> x86 language, as that requires HHH to follow the call instruction,
>>>> which it can not do as the required (and accepted by your) condition
>>>> that the decider is a pure function, which means it can only look at
>>>> its input, which does not include the code which the call points to.
>>>>
>>>>>
>>>>> int sum(int x, int y) { return x + y; }
>>>>> sum is required to compute the mapping
>>>>> from its input into its return value
>>>>> according to the rules of arithmetic.
>>>>
>>>> Right, and a halt decider is required to (try to) compute the
>>>> mapping from the input (which needs to be the representation of a
>>>> program) to the results of running that program (since that is the
>>>> DEFINITION of Halt Deciding).
>>>>
>>>>>
>>>>> This means that requiring sum(3,2) to return
>>>>> the sum of 5 + 7 is an incorrect requirement.
>>>>
>>>> Right, just as HHH trying to claim that its answer is based on the
>>>> fact that it can't reach the end of its simulation of the input
>>>> isn't the correct requirement for HHH.
>>>>
>>>>>
>>>>> Like sum(3,2) HHH(DD) is only allowed to report
>>>>> on the behavior that its input actually specifies.
>>>>>
>>>>
>>>> Right, which is Halting, since that behavior is DEFINED to be the
>>>> behavior of running the program the input represents.
>>>>
>>>
>>> Just like requiring sum(3,2) to report on the sum of 5 + 7
>>> a value other than its input specifies HHH IS NOT ALLOWED
>>> to report on anything other than the behavior that its input
>>> specifies.
>>>
>> Indeed, therefore HHH should process the actual input: including the
>> HHH that aborts, not the hypothetical HHH that does not abort.
>
> HHH cannot say to itself I have no need to abort
> because I will abort later on. It either aborts
> as soon as it recognizes the non terminating
> pattern specified by itself input or no HHH ever aborts.
>
>> Sum(3,2) should process the actual input, not the hypothetical input 5
>> and 7.
>> HHH should process all relevant input, including the part with the
>> conditional abort, not only the first part of the input.
>> Sum(3,2) should process all relevant input, not only the 2 and ignore
>> the 3.
>> So, go and fix HHH.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> When 1 or more statements of DDD are correctly
> simulated by HHH then this correctly simulated
> DDD cannot possibly reach its own “return statement”.
> (final halt state).
>
> Reaching a final halt state means halting.
> Unable to reach a final halt state means non-terminating.
But only after an unboudned number of steps attempted.
>
> Thus HHH(DDD) is correct to reject its finite input string
> DDD as specifying a non-terminating sequence of configurations.
>
No, it isn't, but then you have shown that you think lies are a proper
form of logic.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2025-05-10 09:53 +0200 |
| Subject | Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) |
| Message-ID | <vvn0m0$3dv8d$1@dont-email.me> |
| In reply to | #118155 |
Op 09.mei.2025 om 18:11 schreef olcott:
> On 5/9/2025 4:25 AM, Fred. Zwarts wrote:
>> Op 09.mei.2025 om 01:48 schreef olcott:
>>> On 5/8/2025 6:35 PM, Richard Damon wrote:
>>>> On 5/8/25 1:00 PM, olcott wrote:
>>>>> On 5/8/2025 11:14 AM, Mike Terry wrote:
>>>>>> On 08/05/2025 06:33, Richard Heathfield wrote:
>>>>>>> On 08/05/2025 06:22, olcott wrote:
>>>>>>>> On 5/7/2025 11:09 PM, Richard Heathfield wrote:
>>>>>>>>> On 08/05/2025 02:20, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> Does there exist an HHH such that DDD emulated by
>>>>>>>>>> HHH according to the rules of the C programming language
>>>>>>>>>
>>>>>>>>> Let's take a look.
>>>>>>>>>
>>>>>>>>> The file is 1373 lines long, but don't worry, because I plan to
>>>>>>>>> stop at HHH's first departure from the rules of the C
>>>>>>>>> programming language (or at least the first departure I spot).
>>>>>>>>>
>>>>>>>>> Turn in your songbook if you will to:
>>>>>>>>>
>>>>>>>>> void CopyMachineCode(u8* source, u8** destination)
>>>>>>>>> {
>>>>>>>>> u32 size;
>>>>>>>>> for (size = 0; source[size] != 0xcc; size++)
>>>>>>>>> ;
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>> ((u32*)*destination)[-1] = size;
>>>>>>>>> Output("CopyMachineCode destination[-1]: ",
>>>>>>>>> ((u32*)*destination) [-1]);
>>>>>>>>> Output("CopyMachineCode destination[-2]: ",
>>>>>>>>> ((u32*)*destination) [-2]);
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>
>>>>>>>> deprecated.
>>>>>>>
>>>>>>> It's not just deprecated. It's hopelessly broken.
>>>>>>>
>>>>>>> Everybody makes mistakes, and one slip would be all very well,
>>>>>>> but you make essentially the same mistake --- writing to memory
>>>>>>> that your program doesn't own --- no fewer than four times in a
>>>>>>> single function.
>>>>>>>
>>>>>>>>> I'll ignore the syntax error (a null statement at file scope is
>>>>>>>>> a rookie error).
>>>>>>>>>
>>>>>>>>> Instead, let's jump straight to this line:
>>>>>>>>>
>>>>>>>>> *destination = (u8*) Allocate(size);
>>>>>>>>>
>>>>>>>>> On line 79 of my copy of the code, we find:
>>>>>>>>>
>>>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>>>>
>>>>>>>>> In C, 0 is a null pointer constant, so Allocate returns a null
>>>>>>>>> pointer constant... which is fine as long as you don't try to
>>>>>>>>> deref it. So now *destination is NULL.
>>>>>>>>>
>>>>>>>>> We go on:
>>>>>>>>>
>>>>>>>>> for (u32 N = 0; N < size; N++)
>>>>>>>>> {
>>>>>>>>> Output("source[N]: ", source[N]);
>>>>>>>>> *destination[N] = source[N];
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> *destination[N] is our first big problem (we're ignoring syntax
>>>>>>>>> errors, remember). destination is a null pointer, so
>>>>>>>>> destination[N] derefs a null pointer.
>>>>>>>>>
>>>>>>>>> That's a fail. 0/10, D-, go away and write it again. And you /
>>>>>>>>> dare/ to impugn other people's C knowledge! Crack a book, for
>>>>>>>>> pity's sake.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you can't even understand what is essentially
>>>>>>>> an infinite recursive relationship between two functions
>>>>>>>> except that one function can terminate the other then
>>>>>>>> you don't have a clue about the essence of my system.
>>>>>>>
>>>>>>> If you can't even understand why it's a stupendously bad idea to
>>>>>>> dereference a null pointer, you have no business trying to teach
>>>>>>> anyone anything about C.
>>>>>>>
>>>>>>> Your code is the work of a programmer so hideously incompetent
>>>>>>> that 'programmer' is scarcely a fair word to use.
>>>>>>>
>>>>>>> When you publish code like that, to even *think* about
>>>>>>> denigrating other people's C knowledge is the height of arrogant
>>>>>>> hypocrisy.
>>>>>>>
>>>>>> One problem here is that you don't understand how PO's code works.
>>>>>> That's to be expected, and PO's response ought to be to explain it
>>>>>> so that you understand. Instead he goes off on one of his rants,
>>>>>> so blamewise it's really down to PO.
>>>>>>
>>>>>> PO's halt7.c is compiled (it is not linked), then the obj file is
>>>>>> fed as input to his x87utm.exe which is a kind of x86 obj code
>>>>>> execution environment. x87utm provides a number of primative
>>>>>> calls that halt7.c code can make, such as Allocate(), used to
>>>>>> allocate a block of memory for use in halt7.c. Within halt7.c
>>>>>> code calls an Allocate() function, and x86utm intercepts that and
>>>>>> performs the function internally, then jumps the calling code in
>>>>>> halt7.c over the Allocate call where it continues as normal. The
>>>>>> call never goes to the implementation of Allocate in halt7.c, so
>>>>>> the null pointer dereferencing does not actually occur. There are
>>>>>> a whole bunch of similar x86utm primitive operations that work in
>>>>>> the same way.
>>>>>>
>>>>>> PO should have said all that, not me, but it seems he's not
>>>>>> interested in genuine communication.
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks for those details, they are correct.
>>>>> I try to stay focused on the key essence gist
>>>>> of the issue and never delve down into the weeds.
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> The key gist of the issue (no weeds involved)
>>>>> is that HHH emulated DD according to the rules
>>>>> of the x86 language
>>>>
>>>> Excpet, as you have admitted, your DD isn't a program (just a C
>>>> funciton), and thus not a proper input for a halt decider, which by
>>>> definiton must be a program.
>>>>
>>>> Your C function can't be a program, as you have specifically said
>>>> that the function, and only the funciton is the input, and programs
>>>> must include in them all their code, so since the code of HHH isn't
>>>> included in DD or the input representing it, it isn't a program, and
>>>> thus not a proper input
>>>>
>>>>>
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> *until H correctly determines that*
>>>>> *its simulated D would never stop running unless aborted*
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>
>>>>
>>>> But that statement implies, as required that H be a halt decider and
>>>> D to be a proper input to one, neither of which are satisfied, as
>>>> you have admitte
>>>>
>>>>> When HHH(DD) computes the actual mapping from
>>>>> its actual input to the actual behavior this
>>>>> it specifies it must be according to the rules
>>>>> of the x86 language.
>>>>
>>>> But it doesn't, as it doesn't correctly follow the behavior of the
>>>> x86 language, as that requires HHH to follow the call instruction,
>>>> which it can not do as the required (and accepted by your) condition
>>>> that the decider is a pure function, which means it can only look at
>>>> its input, which does not include the code which the call points to.
>>>>
>>>>>
>>>>> int sum(int x, int y) { return x + y; }
>>>>> sum is required to compute the mapping
>>>>> from its input into its return value
>>>>> according to the rules of arithmetic.
>>>>
>>>> Right, and a halt decider is required to (try to) compute the
>>>> mapping from the input (which needs to be the representation of a
>>>> program) to the results of running that program (since that is the
>>>> DEFINITION of Halt Deciding).
>>>>
>>>>>
>>>>> This means that requiring sum(3,2) to return
>>>>> the sum of 5 + 7 is an incorrect requirement.
>>>>
>>>> Right, just as HHH trying to claim that its answer is based on the
>>>> fact that it can't reach the end of its simulation of the input
>>>> isn't the correct requirement for HHH.
>>>>
>>>>>
>>>>> Like sum(3,2) HHH(DD) is only allowed to report
>>>>> on the behavior that its input actually specifies.
>>>>>
>>>>
>>>> Right, which is Halting, since that behavior is DEFINED to be the
>>>> behavior of running the program the input represents.
>>>>
>>>
>>> Just like requiring sum(3,2) to report on the sum of 5 + 7
>>> a value other than its input specifies HHH IS NOT ALLOWED
>>> to report on anything other than the behavior that its input
>>> specifies.
>>>
>> Indeed, therefore HHH should process the actual input: including the
>> HHH that aborts, not the hypothetical HHH that does not abort.
>
> HHH cannot say to itself I have no need to abort
> because I will abort later on. It either aborts
> as soon as it recognizes the non terminating
> pattern specified by itself input or no HHH ever aborts.
HHH cannot recognise a non terminating pattern if it is not in the
input. The input specifies a program that contains code for a condition
abort. HHH must take that into account to be correct.
HHH cannot be correct. It cannot say 'I do a wild guess that it does not
halt, so I abort'.
>
>> Sum(3,2) should process the actual input, not the hypothetical input 5
>> and 7.
>> HHH should process all relevant input, including the part with the
>> conditional abort, not only the first part of the input.
>> Sum(3,2) should process all relevant input, not only the 2 and ignore
>> the 3.
>> So, go and fix HHH.
>
> void DDD()
> {
> HHH(DDD);
> return;
> }
>
> When 1 or more statements of DDD are correctly
> simulated by HHH then this correctly simulated
> DDD cannot possibly reach its own “return statement”.
> (final halt state).
Yes, we know that HHH fails to reach the reachable end. It makes no
sense to repeat this failure of HHH.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-08 18:45 +0100 |
| Message-ID | <vviqjl$20ffs$1@dont-email.me> |
| In reply to | #118044 |
On 08/05/2025 17:14, 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.
I think you know that I have rapidly come to accord your replies
a high degree of respect, and I don't doubt your suggestion that
there is more to Mr Olcott's code than meets the eye.
But when he started talking about "the rules of the C programming
language", he opened the door to his own knowledge of those rules
being called into question.
> 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.
Competencywise it's also down to him.
> PO's halt7.c is compiled (it is not linked),
A compiler (not necessarily a linker) is /required/ to diagnose
the syntax error. To ignore a report of a syntax error is woeful
negligence.
Furthermore, dereferencing a null pointer shows a remarkable lack
of understanding of how to program in C.
> then the obj file is
> fed as input to his x87utm.exe which is a kind of x86 obj code
> execution environment.
That'd be x86utm.cpp, presumably.
> 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,
The .cpp extension is generally used to indicate C++ code, on
which I have no comment to make. If he intends x86utm.cpp to be
understood as observing C syntax, however, then he may be
surprised to learn that it doesn't.
> PO should have said all that, not me, but it seems he's not
> interested in genuine communication.
Um, quite so.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-08 07:21 -0400 |
| Message-ID | <2d17b821dddb673dd62a367bf152beda602a77e8@i2pn2.org> |
| In reply to | #118018 |
On 5/8/25 1:22 AM, 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.
>
>> 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.
>
But it isn't an infinite recursion, because HHH stops it.
It is only an imagined infinite recusrion when you lie to yourself about
what the input to HHH is.
Your problem is you are stuck in a world of make-beleive where you
beleive your own lies and ignore the turth.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 18:41 -0500 |
| Message-ID | <vvgr39$1ag3a$3@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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-07 22:52 +0100 |
| Message-ID | <vvgknf$18i5r$1@dont-email.me> |
| In reply to | #117937 |
On 07/05/2025 22:46, olcott wrote: > On 5/7/2025 4:30 PM, Richard Heathfield wrote: <snip> >> 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. If it were false, you'd be able to chop out the unreachable code without any adverse effects. Can you? <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-07 16:59 -0500 |
| Message-ID | <vvgl47$18q46$4@dont-email.me> |
| In reply to | #117940 |
On 5/7/2025 4:52 PM, Richard Heathfield wrote: > On 07/05/2025 22:46, olcott wrote: >> On 5/7/2025 4:30 PM, Richard Heathfield wrote: > > <snip> > >>> 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. > > If it were false, you'd be able to chop out the unreachable code without > any adverse effects. Can you? > > <snip> > I already know the answer. You have not yet shown that you even understand the question. I suspect that you don't know the first thing about programming. What exact sequence of the following machine addresses of DD emulated by HHH causes DD to reach its own final halt state at machine address [00002155] When this sequence is required to conform to the rules of the x86 language? _DD() [00002133] 55 push ebp ; housekeeping [00002134] 8bec mov ebp,esp ; housekeeping [00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD [0000213c] e882f4ffff call 000015c3 ; call HHH(DD) [00002141] 83c404 add esp,+04 [00002144] 8945fc mov [ebp-04],eax [00002147] 837dfc00 cmp dword [ebp-04],+00 [0000214b] 7402 jz 0000214f [0000214d] ebfe jmp 0000214d [0000214f] 8b45fc mov eax,[ebp-04] [00002152] 8be5 mov esp,ebp [00002154] 5d pop ebp [00002155] c3 ret Size in bytes:(0035) [00002155] -- 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-07 23:16 +0100 |
| Message-ID | <vvgm45$18i6e$4@dont-email.me> |
| In reply to | #117943 |
On 07/05/2025 22:59, olcott wrote:
> On 5/7/2025 4:52 PM, Richard Heathfield wrote:
>> On 07/05/2025 22:46, olcott wrote:
>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote:
>>
>> <snip>
>>
>>>> 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.
>>
>> If it were false, you'd be able to chop out the unreachable
>> code without any adverse effects. Can you?
>>
>> <snip>
>>
>
> I already know the answer.
Then you already know why your simulation code fails to simulate
correctly... but of course you /don't/ know, so I'll explain.
Let us postulate a program that contains a function as follows:
void invisible(void)
{
secret();
}
When directly executed, the program calls invisible(), but when
simulated, the invisible() call is unreachable.
secret() could do nothing, or it might launch a for(;;); or it
could catch SIGABRT with a returning handler and call abort().
The simulator has no way of knowing which is which.
Therefore a termination analyser that attempts to analyse this
program but cannot reach all the code is doomed to be unable to
run a correct simulation and is necessarily reduced to guesswork.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-05-07 22:26 +0000 |
| Message-ID | <O6RSP.33397$CLof.14762@fx03.ams4> |
| In reply to | #117947 |
On Wed, 07 May 2025 23:16:37 +0100, Richard Heathfield wrote:
> On 07/05/2025 22:59, olcott wrote:
>> On 5/7/2025 4:52 PM, Richard Heathfield wrote:
>>> On 07/05/2025 22:46, olcott wrote:
>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote:
>>>
>>> <snip>
>>>
>>>>> 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.
>>>
>>> If it were false, you'd be able to chop out the unreachable code
>>> without any adverse effects. Can you?
>>>
>>> <snip>
>>>
>>>
>> I already know the answer.
>
> Then you already know why your simulation code fails to simulate
> correctly... but of course you /don't/ know, so I'll explain.
>
> Let us postulate a program that contains a function as follows:
>
> void invisible(void)
> {
> secret();
> }
>
> When directly executed, the program calls invisible(), but when
> simulated, the invisible() call is unreachable.
If invisible() call is unreachable then it isn't an accurate simulation.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-07 23:29 +0100 |
| Message-ID | <vvgmsv$18i5r$3@dont-email.me> |
| In reply to | #117948 |
On 07/05/2025 23:26, Mr Flibble wrote:
> On Wed, 07 May 2025 23:16:37 +0100, Richard Heathfield wrote:
>
>> On 07/05/2025 22:59, olcott wrote:
>>> On 5/7/2025 4:52 PM, Richard Heathfield wrote:
>>>> On 07/05/2025 22:46, olcott wrote:
>>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote:
>>>>
>>>> <snip>
>>>>
>>>>>> 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.
>>>>
>>>> If it were false, you'd be able to chop out the unreachable code
>>>> without any adverse effects. Can you?
>>>>
>>>> <snip>
>>>>
>>>>
>>> I already know the answer.
>>
>> Then you already know why your simulation code fails to simulate
>> correctly... but of course you /don't/ know, so I'll explain.
>>
>> Let us postulate a program that contains a function as follows:
>>
>> void invisible(void)
>> {
>> secret();
>> }
>>
>> When directly executed, the program calls invisible(), but when
>> simulated, the invisible() call is unreachable.
>
> If invisible() call is unreachable then it isn't an accurate simulation.
Precisely. For once we are in agreement.
--
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-07 18:09 -0500 |
| Message-ID | <vvgp6s$1a47o$3@dont-email.me> |
| In reply to | #117947 |
On 5/7/2025 5:16 PM, Richard Heathfield wrote: > On 07/05/2025 22:59, olcott wrote: >> On 5/7/2025 4:52 PM, Richard Heathfield wrote: >>> On 07/05/2025 22:46, olcott wrote: >>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>> >>> <snip> >>> >>>>> 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. >>> >>> If it were false, you'd be able to chop out the unreachable code >>> without any adverse effects. Can you? >>> >>> <snip> >>> >> >> I already know the answer. > > Then you already know why your simulation code fails to simulate > correctly... When I say correctly I mean according to the rules of the x86 language. When you say "correctly" you mean break the rules of the x86 language to match a misconception. -- 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 03:24 +0100 |
| Message-ID | <vvh4ks$1gb9o$1@dont-email.me> |
| In reply to | #117952 |
On 08/05/2025 00:09, olcott wrote: > On 5/7/2025 5:16 PM, Richard Heathfield wrote: >> On 07/05/2025 22:59, olcott wrote: >>> On 5/7/2025 4:52 PM, Richard Heathfield wrote: >>>> On 07/05/2025 22:46, olcott wrote: >>>>> On 5/7/2025 4:30 PM, Richard Heathfield wrote: >>>> >>>> <snip> >>>> >>>>>> 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. >>>> >>>> If it were false, you'd be able to chop out the unreachable >>>> code without any adverse effects. Can you? >>>> >>>> <snip> >>>> >>> >>> I already know the answer. >> >> Then you already know why your simulation code fails to >> simulate correctly... > > When I say correctly I mean according to the > rules of the x86 language. No, when you say 'correctly' my best guess would be that you mean it fits your expectations. > When you say "correctly" you mean break the rules > of the x86 language to match a misconception. No, when I said 'fails to simulate correctly' I meant 'fails to simulate the behaviour it was asked to simulate'. You have already acknowledged that some of the code is reachable by the program when executed directly but not by the simulator. That's self-evidently broken. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 30 of 32 — ← Prev page 1 … 28 29 [30] 31 32 Next page →
Back to top | Article view | comp.theory
csiph-web