Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #107301 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-06-16 22:33 -0500 |
| Last post | 2024-06-18 22:16 -0400 |
| Articles | 20 on this page of 169 — 7 participants |
Back to article view | Back to comp.theory
Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-16 22:33 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 10:31 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 07:20 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 15:30 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 08:47 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 16:18 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 09:34 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 16:49 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 10:56 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-18 09:57 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 07:38 -0500
Re: Simulating termination analyzers for dummies Python <python@invalid.org> - 2024-06-18 14:42 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 08:34 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-18 17:20 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 10:33 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-18 17:47 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:26 -0500
Re: Simulating termination analyzers for dummies Python <python@invalid.org> - 2024-06-18 18:28 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:34 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 10:08 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 08:00 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 15:56 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 10:01 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 17:47 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 11:08 -0500
Re: Simulating termination analyzers for dummies "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-20 10:17 +0200
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-19 20:23 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 19:44 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-19 21:39 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 21:02 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-19 22:17 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 21:25 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 07:33 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 09:58 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: Simulating termination analyzers for dummies joes <noreply@example.com> - 2024-06-20 22:48 +0000
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 17:52 -0500
Re: Simulating termination analyzers for dummies joes <noreply@example.com> - 2024-06-20 23:05 +0000
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 18:09 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 21:29 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 22:43 -0400
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:17 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 00:22 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 07:33 -0400
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-20 17:54 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-20 10:06 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: Simulating termination analyzers for dummies Python <python@invalid.org> - 2024-06-18 17:56 +0200
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:29 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 18:42 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 20:16 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 21:24 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 21:04 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 22:33 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 21:36 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 22:44 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 22:01 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-17 23:15 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-17 22:28 -0500
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 07:36 -0400
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 08:21 -0500
Re: Simulating termination analyzers by dummies joes <noreply@example.com> - 2024-06-18 17:06 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 12:25 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-18 17:57 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 13:16 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-18 20:37 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 16:29 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 08:48 +0000
Re: Simulating termination analyzers by dummies --- test of dishonesty olcott <polcott333@gmail.com> - 2024-06-19 08:12 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 16:08 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Alan Mackenzie <acm@muc.de> - 2024-06-18 21:36 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 16:54 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Alan Mackenzie <acm@muc.de> - 2024-06-19 09:29 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 09:05 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 17:51 +0000
Re: Simulating termination analyzers by dummies --- The only reply until addressed olcott <polcott333@gmail.com> - 2024-06-19 12:52 -0500
Re: Simulating termination analyzers by dummies --- addressed joes <noreply@example.com> - 2024-06-19 18:03 +0000
Re: Simulating termination analyzers by dummies --- --- the only reply until FULLY addressed olcott <polcott333@gmail.com> - 2024-06-19 13:26 -0500
Re: Simulating termination analyzers by dummies --- --- the only reply until FULLY addressed joes <noreply@example.com> - 2024-06-20 16:33 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:29 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 00:40 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-20 18:08 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 10:23 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-21 10:11 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-21 08:19 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-21 10:06 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-22 11:05 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-22 08:04 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-22 09:27 -0400
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-22 09:11 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-22 10:20 -0400
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-22 09:42 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-22 11:08 -0400
Re: Simulating termination analyzers by dummies --- criteria is met joes <noreply@example.com> - 2024-06-22 14:53 +0000
Re: Simulating termination analyzers by dummies --- criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-23 10:57 +0300
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-23 08:13 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-24 10:22 +0300
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-24 08:46 -0500
Re: Simulating termination analyzers by dummies --- criteria is met joes <noreply@example.com> - 2024-06-24 19:52 +0000
Re: Simulating termination analyzers by dummies --- criteria is met Alan Mackenzie <acm@muc.de> - 2024-06-24 20:27 +0000
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-24 16:10 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-24 19:48 -0400
Re: Simulating termination analyzers by dummies --- criteria is met joes <noreply@example.com> - 2024-06-25 08:48 +0000
Re: Simulating termination analyzers by dummies --- criteria is met "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-25 14:14 +0200
Re: Simulating termination analyzers by dummies --- criteria is met Mikko <mikko.levanto@iki.fi> - 2024-06-25 12:27 +0300
Re: Simulating termination analyzers by dummies --- criteria is met Alan Mackenzie <acm@muc.de> - 2024-06-25 14:06 +0000
Re: Simulating termination analyzers by dummies --- criteria is met olcott <polcott333@gmail.com> - 2024-06-24 16:12 -0500
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-24 19:53 -0400
Re: Simulating termination analyzers by dummies --- criteria is met Richard Damon <richard@damon-family.org> - 2024-06-24 19:44 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 21:30 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-18 22:41 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-18 21:51 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 09:08 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 08:31 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 17:43 +0000
Re: Simulating termination analyzers by dummies --- the only reply until addressed olcott <polcott333@gmail.com> - 2024-06-19 12:48 -0500
Re: Simulating termination analyzers by dummies --- the only reply until addressed joes <noreply@example.com> - 2024-06-19 17:59 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 07:30 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 09:23 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 16:43 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 12:09 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 20:24 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 12:16 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 17:32 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 12:40 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 20:24 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 20:24 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 08:57 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 08:20 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-19 16:25 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-19 20:24 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 10:18 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 08:11 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 16:11 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 10:07 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-19 17:50 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-19 11:10 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-20 10:23 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 09:16 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-20 16:29 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 11:35 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-21 09:58 +0200
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-21 08:12 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-21 10:11 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? joes <noreply@example.com> - 2024-06-20 22:54 +0000
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:43 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-20 09:45 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-21 10:02 +0300
Re: Simulating termination analyzers by dummies --- What does halting mean? olcott <polcott333@gmail.com> - 2024-06-21 08:18 -0500
Re: Simulating termination analyzers by dummies --- What does halting mean? Richard Damon <richard@damon-family.org> - 2024-06-21 10:20 -0400
Re: Simulating termination analyzers by dummies --- What does halting mean? Mikko <mikko.levanto@iki.fi> - 2024-06-22 11:14 +0300
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Re: Simulating termination analyzers for dummies Python <python@invalid.org> - 2024-06-18 13:52 +0200
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-18 19:21 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:30 -0500
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-18 19:37 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-18 11:45 -0500
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-19 12:30 +0300
Re: Simulating termination analyzers for dummies olcott <polcott333@gmail.com> - 2024-06-19 08:47 -0500
Re: Simulating termination analyzers for dummies joes <noreply@example.com> - 2024-06-19 17:45 +0000
Re: Simulating termination analyzers for dummies --- The only reply until addressed olcott <polcott333@gmail.com> - 2024-06-19 12:49 -0500
Re: Simulating termination analyzers for dummies Mikko <mikko.levanto@iki.fi> - 2024-06-20 08:53 +0300
Re: Simulating termination analyzers for dummies Richard Damon <richard@damon-family.org> - 2024-06-18 22:16 -0400
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-19 10:08 +0200 |
| Message-ID | <v4u3mr$1rrod$2@dont-email.me> |
| In reply to | #107381 |
Op 18.jun.2024 om 18:26 schreef olcott:
> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>> Op 18.jun.2024 om 17:33 schreef olcott:
>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>
>>> It is a verified fact that serious C people have recently
>>> agreed to the following verbatim statement in the C group.
>
> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>
>>> You either lack this degree of skill in C or are only
>>> interested in playing head games.
>>
>> I have seen the response. It was most certainly not a serious reply.
>> But you know apparently to little of C to understand that.
>> Probably, because you are unable to escape from rebuttal mode, even if
>> the truth is obvious.
>>
>
> I have known C since K&R was the standard and met
> Bjarne Stroustrup when he came to our university
> to promote his new C++ programming language.
>
> *You seem to be willfully ignorant*
>
>> It was your own proof that showed that in
>>
>> int main()
>> {
>> return H(main);
>> }
>>
>>
>> main halts, whereas H reported non-halting. So, it you were honest you
>> would stop claiming that H is correct.
>>
>
> That is merely a more difficult to understand version of this
> same pathological relationship.
>
> int main()
> {
> Output("Input_Halts = ", HH0(main));
> }
>
> _main()
> [000020c2] 55 push ebp
> [000020c3] 8bec mov ebp,esp
> [000020c5] 68c2200000 push 000020c2 ; push main
> [000020ca] e833f4ffff call 00001502 ; call HH0
> [000020cf] 83c404 add esp,+04
> [000020d2] 50 push eax
> [000020d3] 6843070000 push 00000743
> [000020d8] e885e6ffff call 00000762
> [000020dd] 83c408 add esp,+08
> [000020e0] eb04 jmp 000020e6
> [000020e2] 33c0 xor eax,eax
> [000020e4] eb02 jmp 000020e8
> [000020e6] 33c0 xor eax,eax
> [000020e8] 5d pop ebp
> [000020e9] c3 ret
> Size in bytes:(0040) [000020e9]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [000020c2][001036c3][00000000] 55 push ebp
> [000020c3][001036c3][00000000] 8bec mov ebp,esp
> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
> New slave_stack at:103767
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
> [000020c2][0011375f][00113763] 55 push ebp ; begin main
> [000020c3][0011375f][00113763] 8bec mov ebp,esp
> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
> New slave_stack at:14e18f
> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> [000020cf][001036c3][00000000] 83c404 add esp,+04
> [000020d2][001036bf][00000000] 50 push eax
> [000020d3][001036bb][00000743] 6843070000 push 00000743
> [000020d8][001036bb][00000743] e885e6ffff call 00000762
> Input_Halts = 0
> [000020dd][001036c3][00000000] 83c408 add esp,+08
> [000020e0][001036c3][00000000] eb04 jmp 000020e6
> [000020e6][001036c3][00000000] 33c0 xor eax,eax
> [000020e8][001036c7][00000018] 5d pop ebp
> [000020e9][001036cb][00000000] c3 ret ; exit main
> Number of Instructions Executed(10070) == 150 Pages
>
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false negatives, when
used to determine halting behaviour, please, stop to call them
halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the simulation
was correct, when false, the full simulation was not possible.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 08:00 -0500 |
| Message-ID | <v4ukq9$1vpm0$2@dont-email.me> |
| In reply to | #107414 |
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
> Op 18.jun.2024 om 18:26 schreef olcott:
>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>
>>>> It is a verified fact that serious C people have recently
>>>> agreed to the following verbatim statement in the C group.
>>
>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>
>>>> You either lack this degree of skill in C or are only
>>>> interested in playing head games.
>>>
>>> I have seen the response. It was most certainly not a serious reply.
>>> But you know apparently to little of C to understand that.
>>> Probably, because you are unable to escape from rebuttal mode, even
>>> if the truth is obvious.
>>>
>>
>> I have known C since K&R was the standard and met
>> Bjarne Stroustrup when he came to our university
>> to promote his new C++ programming language.
>>
>> *You seem to be willfully ignorant*
>>
>>> It was your own proof that showed that in
>>>
>>> int main()
>>> {
>>> return H(main);
>>> }
>>>
>>>
>>> main halts, whereas H reported non-halting. So, it you were honest
>>> you would stop claiming that H is correct.
>>>
>>
>> That is merely a more difficult to understand version of this
>> same pathological relationship.
>>
>> int main()
>> {
>> Output("Input_Halts = ", HH0(main));
>> }
>>
>> _main()
>> [000020c2] 55 push ebp
>> [000020c3] 8bec mov ebp,esp
>> [000020c5] 68c2200000 push 000020c2 ; push main
>> [000020ca] e833f4ffff call 00001502 ; call HH0
>> [000020cf] 83c404 add esp,+04
>> [000020d2] 50 push eax
>> [000020d3] 6843070000 push 00000743
>> [000020d8] e885e6ffff call 00000762
>> [000020dd] 83c408 add esp,+08
>> [000020e0] eb04 jmp 000020e6
>> [000020e2] 33c0 xor eax,eax
>> [000020e4] eb02 jmp 000020e8
>> [000020e6] 33c0 xor eax,eax
>> [000020e8] 5d pop ebp
>> [000020e9] c3 ret
>> Size in bytes:(0040) [000020e9]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [000020c2][001036c3][00000000] 55 push ebp
>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>> New slave_stack at:103767
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>> New slave_stack at:14e18f
>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>> [000020d2][001036bf][00000000] 50 push eax
>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>> Input_Halts = 0
>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>> [000020e8][001036c7][00000018] 5d pop ebp
>> [000020e9][001036cb][00000000] c3 ret ; exit main
>> Number of Instructions Executed(10070) == 150 Pages
>>
>
> It is easier to understand because a print statement was added.
> You proved that it halts, but H0 reports non-halting.
> So, it produces a false negative.
> So, now it has been proved that H, H0, etc produce false negatives, when
> used to determine halting behaviour, please, stop to call them
> halt-deciders, or termination-deciders.
> They might be "simulation deciders". When returning true, the simulation
> was correct, when false, the full simulation was not possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-19 15:56 +0200 |
| Message-ID | <v4uo37$1vtc8$2@dont-email.me> |
| In reply to | #107424 |
Op 19.jun.2024 om 15:00 schreef olcott:
> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>> Op 18.jun.2024 om 18:26 schreef olcott:
>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>
>>>>> It is a verified fact that serious C people have recently
>>>>> agreed to the following verbatim statement in the C group.
>>>
>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>
>>>>> You either lack this degree of skill in C or are only
>>>>> interested in playing head games.
>>>>
>>>> I have seen the response. It was most certainly not a serious reply.
>>>> But you know apparently to little of C to understand that.
>>>> Probably, because you are unable to escape from rebuttal mode, even
>>>> if the truth is obvious.
>>>>
>>>
>>> I have known C since K&R was the standard and met
>>> Bjarne Stroustrup when he came to our university
>>> to promote his new C++ programming language.
>>>
>>> *You seem to be willfully ignorant*
>>>
>>>> It was your own proof that showed that in
>>>>
>>>> int main()
>>>> {
>>>> return H(main);
>>>> }
>>>>
>>>>
>>>> main halts, whereas H reported non-halting. So, it you were honest
>>>> you would stop claiming that H is correct.
>>>>
>>>
>>> That is merely a more difficult to understand version of this
>>> same pathological relationship.
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", HH0(main));
>>> }
>>>
>>> _main()
>>> [000020c2] 55 push ebp
>>> [000020c3] 8bec mov ebp,esp
>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>> [000020cf] 83c404 add esp,+04
>>> [000020d2] 50 push eax
>>> [000020d3] 6843070000 push 00000743
>>> [000020d8] e885e6ffff call 00000762
>>> [000020dd] 83c408 add esp,+08
>>> [000020e0] eb04 jmp 000020e6
>>> [000020e2] 33c0 xor eax,eax
>>> [000020e4] eb02 jmp 000020e8
>>> [000020e6] 33c0 xor eax,eax
>>> [000020e8] 5d pop ebp
>>> [000020e9] c3 ret
>>> Size in bytes:(0040) [000020e9]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [000020c2][001036c3][00000000] 55 push ebp
>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>> New slave_stack at:103767
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>> New slave_stack at:14e18f
>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>> [000020d2][001036bf][00000000] 50 push eax
>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>> Input_Halts = 0
>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>> [000020e8][001036c7][00000018] 5d pop ebp
>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>> Number of Instructions Executed(10070) == 150 Pages
>>>
>>
>> It is easier to understand because a print statement was added.
>> You proved that it halts, but H0 reports non-halting.
>> So, it produces a false negative.
>> So, now it has been proved that H, H0, etc produce false negatives,
>> when used to determine halting behaviour, please, stop to call them
>> halt-deciders, or termination-deciders.
>> They might be "simulation deciders". When returning true, the
>> simulation was correct, when false, the full simulation was not possible.
>
> I don't want to discuss your screwy example because I
> can't use screwy examples in my paper.
>
> void DDD()
> {
> H0(DDD);
> }
>
> _DDD()
> [000020a2] 55 push ebp ; housekeeping
> [000020a3] 8bec mov ebp,esp ; housekeeping
> [000020a5] 68a2200000 push 000020a2 ; push DDD
> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
> [000020af] 83c404 add esp,+04 ; housekeeping
> [000020b2] 5d pop ebp ; housekeeping
> [000020b3] c3 ret ; never gets here
> Size in bytes:(0018) [000020b3]
>
> Exactly which step of DDD emulated by H0 was emulated
> incorrectly such that this emulation would be complete?
> AKA DDD emulated by H0 reaches machine address [000020b3]
>
Yes, that is your attitude. An example that proves you are wrong are
called 'screwy'. You prefer more complex examples, for which you can
easier hide the essential details.
Similarly, it has been pointed out to you many times that your
simulation fails with the call instruction at 000020aa. H0 is required
to halt, but the simulator fails to simulate the 'ret' instruction of H0.
The simulated H0 is aborted one cycle before it would reach its 'ret'
instruction, after which the simulation would proceed with 000020af.
Your problem is that H0 (or any other simulator you have shown) is able
to simulate itself up to its simulated 'ret'.
It seem that you know it, because you never denied it.
This simple fact seems already to be over your head, so, you prefer to
ignore or to forget it and just repeat the baseless claim.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 10:01 -0500 |
| Message-ID | <v4urs3$21810$2@dont-email.me> |
| In reply to | #107433 |
On 6/19/2024 8:56 AM, Fred. Zwarts wrote:
> Op 19.jun.2024 om 15:00 schreef olcott:
>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>
>>>>>> It is a verified fact that serious C people have recently
>>>>>> agreed to the following verbatim statement in the C group.
>>>>
>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>
>>>>>> You either lack this degree of skill in C or are only
>>>>>> interested in playing head games.
>>>>>
>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>> But you know apparently to little of C to understand that.
>>>>> Probably, because you are unable to escape from rebuttal mode, even
>>>>> if the truth is obvious.
>>>>>
>>>>
>>>> I have known C since K&R was the standard and met
>>>> Bjarne Stroustrup when he came to our university
>>>> to promote his new C++ programming language.
>>>>
>>>> *You seem to be willfully ignorant*
>>>>
>>>>> It was your own proof that showed that in
>>>>>
>>>>> int main()
>>>>> {
>>>>> return H(main);
>>>>> }
>>>>>
>>>>>
>>>>> main halts, whereas H reported non-halting. So, it you were honest
>>>>> you would stop claiming that H is correct.
>>>>>
>>>>
>>>> That is merely a more difficult to understand version of this
>>>> same pathological relationship.
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", HH0(main));
>>>> }
>>>>
>>>> _main()
>>>> [000020c2] 55 push ebp
>>>> [000020c3] 8bec mov ebp,esp
>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>> [000020cf] 83c404 add esp,+04
>>>> [000020d2] 50 push eax
>>>> [000020d3] 6843070000 push 00000743
>>>> [000020d8] e885e6ffff call 00000762
>>>> [000020dd] 83c408 add esp,+08
>>>> [000020e0] eb04 jmp 000020e6
>>>> [000020e2] 33c0 xor eax,eax
>>>> [000020e4] eb02 jmp 000020e8
>>>> [000020e6] 33c0 xor eax,eax
>>>> [000020e8] 5d pop ebp
>>>> [000020e9] c3 ret
>>>> Size in bytes:(0040) [000020e9]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> New slave_stack at:103767
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> New slave_stack at:14e18f
>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>> [000020d2][001036bf][00000000] 50 push eax
>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>> Input_Halts = 0
>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>
>>>
>>> It is easier to understand because a print statement was added.
>>> You proved that it halts, but H0 reports non-halting.
>>> So, it produces a false negative.
>>> So, now it has been proved that H, H0, etc produce false negatives,
>>> when used to determine halting behaviour, please, stop to call them
>>> halt-deciders, or termination-deciders.
>>> They might be "simulation deciders". When returning true, the
>>> simulation was correct, when false, the full simulation was not
>>> possible.
>>
>> I don't want to discuss your screwy example because I
>> can't use screwy examples in my paper.
>>
>> void DDD()
>> {
>> H0(DDD);
>> }
>>
>> _DDD()
>> [000020a2] 55 push ebp ; housekeeping
>> [000020a3] 8bec mov ebp,esp ; housekeeping
>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>> [000020af] 83c404 add esp,+04 ; housekeeping
>> [000020b2] 5d pop ebp ; housekeeping
>> [000020b3] c3 ret ; never gets here
>> Size in bytes:(0018) [000020b3]
>>
>> Exactly which step of DDD emulated by H0 was emulated
>> incorrectly such that this emulation would be complete?
>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>
>
> Yes, that is your attitude. An example that proves you are wrong are
> called 'screwy'. You prefer more complex examples, for which you can
> easier hide the essential details.
>
void DDD()
{
HH0(DDD);
}
int main()
{
HH0(DDD);
}
_DDD()
[00002093] 55 push ebp
[00002094] 8bec mov ebp,esp
[00002096] 6893200000 push 00002093 ; push DDD
[0000209b] e853f4ffff call 000014f3 ; call HH0
[000020a0] 83c404 add esp,+04
[000020a3] 5d pop ebp
[000020a4] c3 ret
Size in bytes:(0018) [000020a4]
_main()
[000020b3] 55 push ebp
[000020b4] 8bec mov ebp,esp
[000020b6] 6893200000 push 00002093 ; push DDD
[000020bb] e833f4ffff call 000014f3 ; call HH0
[000020c0] 83c404 add esp,+04
[000020c3] eb04 jmp 000020c9
[000020c5] 33c0 xor eax,eax
[000020c7] eb02 jmp 000020cb
[000020c9] 33c0 xor eax,eax
[000020cb] 5d pop ebp
[000020cc] c3 ret
Size in bytes:(0026) [000020cc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000020b3][00103680][00000000] 55 push ebp ; begin main
[000020b4][00103680][00000000] 8bec mov ebp,esp
[000020b6][0010367c][00002093] 6893200000 push 00002093 ; push DDD
[000020bb][00103678][000020c0] e833f4ffff call 000014f3 ; call HH0
New slave_stack at:103724
Begin Local Halt Decider Simulation Execution Trace Stored at:11372c
[00002093][0011371c][00113720] 55 push ebp ; begin DDD
[00002094][0011371c][00113720] 8bec mov ebp,esp
[00002096][00113718][00002093] 6893200000 push 00002093 ; push DDD
[0000209b][00113714][000020a0] e853f4ffff call 000014f3 ; call HH0
That call right there to HH0 is fully simulated by the directly
executed HH0 and the 150 pages of steps are not displayed so that
the next four steps of DDD correctly simulated by the correctly
simulated HH0 can be clearly seen and not mixed into the 150 pages
of the instructions of the simulated HH0.
New slave_stack at:14e14c
[00002093][0015e144][0015e148] 55 push ebp ; begin DDD
[00002094][0015e144][0015e148] 8bec mov ebp,esp
[00002096][0015e140][00002093] 6893200000 push 00002093 ; push DDD
[0000209b][0015e13c][000020a0] e853f4ffff call 000014f3 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020c0][00103680][00000000] 83c404 add esp,+04 ; return to main
[000020c3][00103680][00000000] eb04 jmp 000020c9
[000020c9][00103680][00000000] 33c0 xor eax,eax
[000020cb][00103684][00000018] 5d pop ebp
[000020cc][00103688][00000000] c3 ret ; end main
Number of Instructions Executed(10067) == 150 Pages
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-19 17:47 +0200 |
| Message-ID | <v4uuho$1vtc8$5@dont-email.me> |
| In reply to | #107438 |
Op 19.jun.2024 om 17:01 schreef olcott:
> On 6/19/2024 8:56 AM, Fred. Zwarts wrote:
>> Op 19.jun.2024 om 15:00 schreef olcott:
>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>
>>>>>>> It is a verified fact that serious C people have recently
>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>
>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>
>>>>>>> You either lack this degree of skill in C or are only
>>>>>>> interested in playing head games.
>>>>>>
>>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>>> But you know apparently to little of C to understand that.
>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>> even if the truth is obvious.
>>>>>>
>>>>>
>>>>> I have known C since K&R was the standard and met
>>>>> Bjarne Stroustrup when he came to our university
>>>>> to promote his new C++ programming language.
>>>>>
>>>>> *You seem to be willfully ignorant*
>>>>>
>>>>>> It was your own proof that showed that in
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> return H(main);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> main halts, whereas H reported non-halting. So, it you were honest
>>>>>> you would stop claiming that H is correct.
>>>>>>
>>>>>
>>>>> That is merely a more difficult to understand version of this
>>>>> same pathological relationship.
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", HH0(main));
>>>>> }
>>>>>
>>>>> _main()
>>>>> [000020c2] 55 push ebp
>>>>> [000020c3] 8bec mov ebp,esp
>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>> [000020cf] 83c404 add esp,+04
>>>>> [000020d2] 50 push eax
>>>>> [000020d3] 6843070000 push 00000743
>>>>> [000020d8] e885e6ffff call 00000762
>>>>> [000020dd] 83c408 add esp,+08
>>>>> [000020e0] eb04 jmp 000020e6
>>>>> [000020e2] 33c0 xor eax,eax
>>>>> [000020e4] eb02 jmp 000020e8
>>>>> [000020e6] 33c0 xor eax,eax
>>>>> [000020e8] 5d pop ebp
>>>>> [000020e9] c3 ret
>>>>> Size in bytes:(0040) [000020e9]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> New slave_stack at:103767
>>>>>
>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> New slave_stack at:14e18f
>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>
>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>> Input_Halts = 0
>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>
>>>>
>>>> It is easier to understand because a print statement was added.
>>>> You proved that it halts, but H0 reports non-halting.
>>>> So, it produces a false negative.
>>>> So, now it has been proved that H, H0, etc produce false negatives,
>>>> when used to determine halting behaviour, please, stop to call them
>>>> halt-deciders, or termination-deciders.
>>>> They might be "simulation deciders". When returning true, the
>>>> simulation was correct, when false, the full simulation was not
>>>> possible.
>>>
>>> I don't want to discuss your screwy example because I
>>> can't use screwy examples in my paper.
>>>
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>>
>>> _DDD()
>>> [000020a2] 55 push ebp ; housekeeping
>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>> [000020b2] 5d pop ebp ; housekeeping
>>> [000020b3] c3 ret ; never gets here
>>> Size in bytes:(0018) [000020b3]
>>>
>>> Exactly which step of DDD emulated by H0 was emulated
>>> incorrectly such that this emulation would be complete?
>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>
>>
>> Yes, that is your attitude. An example that proves you are wrong are
>> called 'screwy'. You prefer more complex examples, for which you can
>> easier hide the essential details.
>>
>
> void DDD()
> {
> HH0(DDD);
> }
>
> int main()
> {
> HH0(DDD);
> }
>
> _DDD()
> [00002093] 55 push ebp
> [00002094] 8bec mov ebp,esp
> [00002096] 6893200000 push 00002093 ; push DDD
> [0000209b] e853f4ffff call 000014f3 ; call HH0
> [000020a0] 83c404 add esp,+04
> [000020a3] 5d pop ebp
> [000020a4] c3 ret
> Size in bytes:(0018) [000020a4]
>
> _main()
> [000020b3] 55 push ebp
> [000020b4] 8bec mov ebp,esp
> [000020b6] 6893200000 push 00002093 ; push DDD
> [000020bb] e833f4ffff call 000014f3 ; call HH0
> [000020c0] 83c404 add esp,+04
> [000020c3] eb04 jmp 000020c9
> [000020c5] 33c0 xor eax,eax
> [000020c7] eb02 jmp 000020cb
> [000020c9] 33c0 xor eax,eax
> [000020cb] 5d pop ebp
> [000020cc] c3 ret
> Size in bytes:(0026) [000020cc]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [000020b3][00103680][00000000] 55 push ebp ; begin main
> [000020b4][00103680][00000000] 8bec mov ebp,esp
> [000020b6][0010367c][00002093] 6893200000 push 00002093 ; push DDD
> [000020bb][00103678][000020c0] e833f4ffff call 000014f3 ; call HH0
> New slave_stack at:103724
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:11372c
> [00002093][0011371c][00113720] 55 push ebp ; begin DDD
> [00002094][0011371c][00113720] 8bec mov ebp,esp
> [00002096][00113718][00002093] 6893200000 push 00002093 ; push DDD
> [0000209b][00113714][000020a0] e853f4ffff call 000014f3 ; call HH0
>
> That call right there to HH0 is fully simulated by the directly
> executed HH0 and the 150 pages of steps are not displayed so that
> the next four steps of DDD correctly simulated by the correctly
> simulated HH0 can be clearly seen and not mixed into the 150 pages
> of the instructions of the simulated HH0.
>
> New slave_stack at:14e14c
> [00002093][0015e144][0015e148] 55 push ebp ; begin DDD
> [00002094][0015e144][0015e148] 8bec mov ebp,esp
> [00002096][0015e140][00002093] 6893200000 push 00002093 ; push DDD
> [0000209b][0015e13c][000020a0] e853f4ffff call 000014f3 ; call HH0
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> [000020c0][00103680][00000000] 83c404 add esp,+04 ; return to main
> [000020c3][00103680][00000000] eb04 jmp 000020c9
> [000020c9][00103680][00000000] 33c0 xor eax,eax
> [000020cb][00103684][00000018] 5d pop ebp
> [000020cc][00103688][00000000] c3 ret ; end main
> Number of Instructions Executed(10067) == 150 Pages
>
Exactly what I said. Ignore simple proofs like:
int main()
{
return H(main, 0);
}
For which you proved that it reports a false negative.
You prefer more complex examples, for which you can easier hide the
essential details. But even your more complex example is simply a false
negative.
We still do not see the 'ret' instruction of the simulated HH0, even
though HH0 is required to halt.
It assumes an infinite recursion, although one cycle later the simulated
HH0 would also halt, because it runs only one cycle behind the
simulating HH0. Thus: a false negative.
The abort is premature. That is to be expected, because a simulator is
unable to simulate itself up to the end.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 11:08 -0500 |
| Message-ID | <v4uvpp$21os1$3@dont-email.me> |
| In reply to | #107442 |
On 6/19/2024 10:47 AM, Fred. Zwarts wrote:
> Op 19.jun.2024 om 17:01 schreef olcott:
>> On 6/19/2024 8:56 AM, Fred. Zwarts wrote:
>>> Op 19.jun.2024 om 15:00 schreef olcott:
>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>
>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>
>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>
>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>> interested in playing head games.
>>>>>>>
>>>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>>>> But you know apparently to little of C to understand that.
>>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>>> even if the truth is obvious.
>>>>>>>
>>>>>>
>>>>>> I have known C since K&R was the standard and met
>>>>>> Bjarne Stroustrup when he came to our university
>>>>>> to promote his new C++ programming language.
>>>>>>
>>>>>> *You seem to be willfully ignorant*
>>>>>>
>>>>>>> It was your own proof that showed that in
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> return H(main);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>
>>>>>>
>>>>>> That is merely a more difficult to understand version of this
>>>>>> same pathological relationship.
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>> }
>>>>>>
>>>>>> _main()
>>>>>> [000020c2] 55 push ebp
>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>> [000020cf] 83c404 add esp,+04
>>>>>> [000020d2] 50 push eax
>>>>>> [000020d3] 6843070000 push 00000743
>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>> [000020dd] 83c408 add esp,+08
>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>> [000020e8] 5d pop ebp
>>>>>> [000020e9] c3 ret
>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>
>>>>>> machine stack stack machine assembly
>>>>>> address address data code language
>>>>>> ======== ======== ======== ========= =============
>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> New slave_stack at:103767
>>>>>>
>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>> at:11376f
>>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> New slave_stack at:14e18f
>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>
>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>> Input_Halts = 0
>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>
>>>>>
>>>>> It is easier to understand because a print statement was added.
>>>>> You proved that it halts, but H0 reports non-halting.
>>>>> So, it produces a false negative.
>>>>> So, now it has been proved that H, H0, etc produce false negatives,
>>>>> when used to determine halting behaviour, please, stop to call them
>>>>> halt-deciders, or termination-deciders.
>>>>> They might be "simulation deciders". When returning true, the
>>>>> simulation was correct, when false, the full simulation was not
>>>>> possible.
>>>>
>>>> I don't want to discuss your screwy example because I
>>>> can't use screwy examples in my paper.
>>>>
>>>> void DDD()
>>>> {
>>>> H0(DDD);
>>>> }
>>>>
>>>> _DDD()
>>>> [000020a2] 55 push ebp ; housekeeping
>>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>>> [000020b2] 5d pop ebp ; housekeeping
>>>> [000020b3] c3 ret ; never gets here
>>>> Size in bytes:(0018) [000020b3]
>>>>
>>>> Exactly which step of DDD emulated by H0 was emulated
>>>> incorrectly such that this emulation would be complete?
>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>
>>>
>>> Yes, that is your attitude. An example that proves you are wrong are
>>> called 'screwy'. You prefer more complex examples, for which you can
>>> easier hide the essential details.
>>>
>>
>> void DDD()
>> {
>> HH0(DDD);
>> }
>>
>> int main()
>> {
>> HH0(DDD);
>> }
>>
>> _DDD()
>> [00002093] 55 push ebp
>> [00002094] 8bec mov ebp,esp
>> [00002096] 6893200000 push 00002093 ; push DDD
>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>> [000020a0] 83c404 add esp,+04
>> [000020a3] 5d pop ebp
>> [000020a4] c3 ret
>> Size in bytes:(0018) [000020a4]
>>
>> _main()
>> [000020b3] 55 push ebp
>> [000020b4] 8bec mov ebp,esp
>> [000020b6] 6893200000 push 00002093 ; push DDD
>> [000020bb] e833f4ffff call 000014f3 ; call HH0
>> [000020c0] 83c404 add esp,+04
>> [000020c3] eb04 jmp 000020c9
>> [000020c5] 33c0 xor eax,eax
>> [000020c7] eb02 jmp 000020cb
>> [000020c9] 33c0 xor eax,eax
>> [000020cb] 5d pop ebp
>> [000020cc] c3 ret
>> Size in bytes:(0026) [000020cc]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [000020b3][00103680][00000000] 55 push ebp ; begin main
>> [000020b4][00103680][00000000] 8bec mov ebp,esp
>> [000020b6][0010367c][00002093] 6893200000 push 00002093 ; push DDD
>> [000020bb][00103678][000020c0] e833f4ffff call 000014f3 ; call HH0
>> New slave_stack at:103724
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:11372c
>> [00002093][0011371c][00113720] 55 push ebp ; begin DDD
>> [00002094][0011371c][00113720] 8bec mov ebp,esp
>> [00002096][00113718][00002093] 6893200000 push 00002093 ; push DDD
>> [0000209b][00113714][000020a0] e853f4ffff call 000014f3 ; call HH0
>>
>> That call right there to HH0 is fully simulated by the directly
>> executed HH0 and the 150 pages of steps are not displayed so that
>> the next four steps of DDD correctly simulated by the correctly
>> simulated HH0 can be clearly seen and not mixed into the 150 pages
>> of the instructions of the simulated HH0.
>>
>> New slave_stack at:14e14c
>> [00002093][0015e144][0015e148] 55 push ebp ; begin DDD
>> [00002094][0015e144][0015e148] 8bec mov ebp,esp
>> [00002096][0015e140][00002093] 6893200000 push 00002093 ; push DDD
>> [0000209b][0015e13c][000020a0] e853f4ffff call 000014f3 ; call HH0
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> [000020c0][00103680][00000000] 83c404 add esp,+04 ; return to main
>> [000020c3][00103680][00000000] eb04 jmp 000020c9
>> [000020c9][00103680][00000000] 33c0 xor eax,eax
>> [000020cb][00103684][00000018] 5d pop ebp
>> [000020cc][00103688][00000000] c3 ret ; end main
>> Number of Instructions Executed(10067) == 150 Pages
>>
> Exactly what I said. Ignore simple proofs like:
>
> int main()
> {
> return H(main, 0);
> }
>
> For which you proved that it reports a false negative.
>
The correctly emulated input DOES NOT HALT.
The directly executed main() only seems to halt
because the directly executed main() is essentially
the first call in a recursive chain where the
second call is always aborted.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-20 10:17 +0200 |
| Message-ID | <v50oj8$2fh98$3@dont-email.me> |
| In reply to | #107444 |
Op 19.jun.2024 om 18:08 schreef olcott:
> On 6/19/2024 10:47 AM, Fred. Zwarts wrote:
>> Op 19.jun.2024 om 17:01 schreef olcott:
>>> On 6/19/2024 8:56 AM, Fred. Zwarts wrote:
>>>> Op 19.jun.2024 om 15:00 schreef olcott:
>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>>
>>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>>
>>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>>
>>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>>> interested in playing head games.
>>>>>>>>
>>>>>>>> I have seen the response. It was most certainly not a serious
>>>>>>>> reply.
>>>>>>>> But you know apparently to little of C to understand that.
>>>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>>>> even if the truth is obvious.
>>>>>>>>
>>>>>>>
>>>>>>> I have known C since K&R was the standard and met
>>>>>>> Bjarne Stroustrup when he came to our university
>>>>>>> to promote his new C++ programming language.
>>>>>>>
>>>>>>> *You seem to be willfully ignorant*
>>>>>>>
>>>>>>>> It was your own proof that showed that in
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> return H(main);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>>
>>>>>>>
>>>>>>> That is merely a more difficult to understand version of this
>>>>>>> same pathological relationship.
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>>> }
>>>>>>>
>>>>>>> _main()
>>>>>>> [000020c2] 55 push ebp
>>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>>> [000020cf] 83c404 add esp,+04
>>>>>>> [000020d2] 50 push eax
>>>>>>> [000020d3] 6843070000 push 00000743
>>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>>> [000020dd] 83c408 add esp,+08
>>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>>> [000020e8] 5d pop ebp
>>>>>>> [000020e9] c3 ret
>>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>>
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> New slave_stack at:103767
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>>> at:11376f
>>>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> New slave_stack at:14e18f
>>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>
>>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>>> Input_Halts = 0
>>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>>
>>>>>>
>>>>>> It is easier to understand because a print statement was added.
>>>>>> You proved that it halts, but H0 reports non-halting.
>>>>>> So, it produces a false negative.
>>>>>> So, now it has been proved that H, H0, etc produce false
>>>>>> negatives, when used to determine halting behaviour, please, stop
>>>>>> to call them halt-deciders, or termination-deciders.
>>>>>> They might be "simulation deciders". When returning true, the
>>>>>> simulation was correct, when false, the full simulation was not
>>>>>> possible.
>>>>>
>>>>> I don't want to discuss your screwy example because I
>>>>> can't use screwy examples in my paper.
>>>>>
>>>>> void DDD()
>>>>> {
>>>>> H0(DDD);
>>>>> }
>>>>>
>>>>> _DDD()
>>>>> [000020a2] 55 push ebp ; housekeeping
>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>>>> [000020b2] 5d pop ebp ; housekeeping
>>>>> [000020b3] c3 ret ; never gets here
>>>>> Size in bytes:(0018) [000020b3]
>>>>>
>>>>> Exactly which step of DDD emulated by H0 was emulated
>>>>> incorrectly such that this emulation would be complete?
>>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>>
>>>>
>>>> Yes, that is your attitude. An example that proves you are wrong are
>>>> called 'screwy'. You prefer more complex examples, for which you can
>>>> easier hide the essential details.
>>>>
>>>
>>> void DDD()
>>> {
>>> HH0(DDD);
>>> }
>>>
>>> int main()
>>> {
>>> HH0(DDD);
>>> }
>>>
>>> _DDD()
>>> [00002093] 55 push ebp
>>> [00002094] 8bec mov ebp,esp
>>> [00002096] 6893200000 push 00002093 ; push DDD
>>> [0000209b] e853f4ffff call 000014f3 ; call HH0
>>> [000020a0] 83c404 add esp,+04
>>> [000020a3] 5d pop ebp
>>> [000020a4] c3 ret
>>> Size in bytes:(0018) [000020a4]
>>>
>>> _main()
>>> [000020b3] 55 push ebp
>>> [000020b4] 8bec mov ebp,esp
>>> [000020b6] 6893200000 push 00002093 ; push DDD
>>> [000020bb] e833f4ffff call 000014f3 ; call HH0
>>> [000020c0] 83c404 add esp,+04
>>> [000020c3] eb04 jmp 000020c9
>>> [000020c5] 33c0 xor eax,eax
>>> [000020c7] eb02 jmp 000020cb
>>> [000020c9] 33c0 xor eax,eax
>>> [000020cb] 5d pop ebp
>>> [000020cc] c3 ret
>>> Size in bytes:(0026) [000020cc]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [000020b3][00103680][00000000] 55 push ebp ; begin main
>>> [000020b4][00103680][00000000] 8bec mov ebp,esp
>>> [000020b6][0010367c][00002093] 6893200000 push 00002093 ; push DDD
>>> [000020bb][00103678][000020c0] e833f4ffff call 000014f3 ; call HH0
>>> New slave_stack at:103724
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11372c
>>> [00002093][0011371c][00113720] 55 push ebp ; begin DDD
>>> [00002094][0011371c][00113720] 8bec mov ebp,esp
>>> [00002096][00113718][00002093] 6893200000 push 00002093 ; push DDD
>>> [0000209b][00113714][000020a0] e853f4ffff call 000014f3 ; call HH0
>>>
>>> That call right there to HH0 is fully simulated by the directly
>>> executed HH0 and the 150 pages of steps are not displayed so that
>>> the next four steps of DDD correctly simulated by the correctly
>>> simulated HH0 can be clearly seen and not mixed into the 150 pages
>>> of the instructions of the simulated HH0.
>>>
>>> New slave_stack at:14e14c
>>> [00002093][0015e144][0015e148] 55 push ebp ; begin DDD
>>> [00002094][0015e144][0015e148] 8bec mov ebp,esp
>>> [00002096][0015e140][00002093] 6893200000 push 00002093 ; push DDD
>>> [0000209b][0015e13c][000020a0] e853f4ffff call 000014f3 ; call HH0
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> [000020c0][00103680][00000000] 83c404 add esp,+04 ; return to main
>>> [000020c3][00103680][00000000] eb04 jmp 000020c9
>>> [000020c9][00103680][00000000] 33c0 xor eax,eax
>>> [000020cb][00103684][00000018] 5d pop ebp
>>> [000020cc][00103688][00000000] c3 ret ; end main
>>> Number of Instructions Executed(10067) == 150 Pages
>>>
>> Exactly what I said. Ignore simple proofs like:
>>
>> int main()
>> {
>> return H(main, 0);
>> }
>>
>> For which you proved that it reports a false negative.
>>
>
> The correctly emulated input DOES NOT HALT.
No, the *incorrectly* emulated input is prevented to halt, because it
was aborted *too soon*. It aborted one cycle before the simulated H
would abort and halt by itself. Unfortunately, there is never a good
moment to abort, because the simulated self keeps running one cycle
behind the simulating H. So, H is always incorrect.
> The directly executed main() only seems to halt
> because the directly executed main() is essentially
> the first call in a recursive chain where the
> second call is always aborted.
>
Aborted too soon, because one cycle later it would halt by itself.
And since it was aborted, it produces a false negative. That is the fate
of a simulating halt decider.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-19 20:23 -0400 |
| Message-ID | <v4vsqt$ggem$1@i2pn2.org> |
| In reply to | #107424 |
On 6/19/24 9:00 AM, olcott wrote:
> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>> Op 18.jun.2024 om 18:26 schreef olcott:
>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>
>>>>> It is a verified fact that serious C people have recently
>>>>> agreed to the following verbatim statement in the C group.
>>>
>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>
>>>>> You either lack this degree of skill in C or are only
>>>>> interested in playing head games.
>>>>
>>>> I have seen the response. It was most certainly not a serious reply.
>>>> But you know apparently to little of C to understand that.
>>>> Probably, because you are unable to escape from rebuttal mode, even
>>>> if the truth is obvious.
>>>>
>>>
>>> I have known C since K&R was the standard and met
>>> Bjarne Stroustrup when he came to our university
>>> to promote his new C++ programming language.
>>>
>>> *You seem to be willfully ignorant*
>>>
>>>> It was your own proof that showed that in
>>>>
>>>> int main()
>>>> {
>>>> return H(main);
>>>> }
>>>>
>>>>
>>>> main halts, whereas H reported non-halting. So, it you were honest
>>>> you would stop claiming that H is correct.
>>>>
>>>
>>> That is merely a more difficult to understand version of this
>>> same pathological relationship.
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", HH0(main));
>>> }
>>>
>>> _main()
>>> [000020c2] 55 push ebp
>>> [000020c3] 8bec mov ebp,esp
>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>> [000020cf] 83c404 add esp,+04
>>> [000020d2] 50 push eax
>>> [000020d3] 6843070000 push 00000743
>>> [000020d8] e885e6ffff call 00000762
>>> [000020dd] 83c408 add esp,+08
>>> [000020e0] eb04 jmp 000020e6
>>> [000020e2] 33c0 xor eax,eax
>>> [000020e4] eb02 jmp 000020e8
>>> [000020e6] 33c0 xor eax,eax
>>> [000020e8] 5d pop ebp
>>> [000020e9] c3 ret
>>> Size in bytes:(0040) [000020e9]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [000020c2][001036c3][00000000] 55 push ebp
>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>> New slave_stack at:103767
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>> New slave_stack at:14e18f
>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>> [000020d2][001036bf][00000000] 50 push eax
>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>> Input_Halts = 0
>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>> [000020e8][001036c7][00000018] 5d pop ebp
>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>> Number of Instructions Executed(10070) == 150 Pages
>>>
>>
>> It is easier to understand because a print statement was added.
>> You proved that it halts, but H0 reports non-halting.
>> So, it produces a false negative.
>> So, now it has been proved that H, H0, etc produce false negatives,
>> when used to determine halting behaviour, please, stop to call them
>> halt-deciders, or termination-deciders.
>> They might be "simulation deciders". When returning true, the
>> simulation was correct, when false, the full simulation was not possible.
>
> I don't want to discuss your screwy example because I
> can't use screwy examples in my paper.
>
> void DDD()
> {
> H0(DDD);
> }
>
> _DDD()
> [000020a2] 55 push ebp ; housekeeping
> [000020a3] 8bec mov ebp,esp ; housekeeping
> [000020a5] 68a2200000 push 000020a2 ; push DDD
> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
> [000020af] 83c404 add esp,+04 ; housekeeping
> [000020b2] 5d pop ebp ; housekeeping
> [000020b3] c3 ret ; never gets here
> Size in bytes:(0018) [000020b3]
>
> Exactly which step of DDD emulated by H0 was emulated
> incorrectly such that this emulation would be complete?
> AKA DDD emulated by H0 reaches machine address [000020b3]
>
>
Why does H0 NEED to be able to correctly simulate its input?
Your question is just a Strawman, replacing the OBJECTIVE criteria of
the behavior of the machine represented by the input (which inlcudes the
code for H0) with the SUBJECTIVE question of what H0 thinks about it.
And, your H0 doesn't correctly simulate the input, as the *ONLY* correct
simulation of that input would be:
simulate the push ebp
simulate the mov ebp,esp
simulate the push 000020a2
simulate the call 00001aa2
simulate the instruction at 00001aa2
since that isn't what you have ever shown as the simulation by H0, you
have lost the right to call its simulation "correct".
Sorry, your argument is just a lie.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 19:44 -0500 |
| Message-ID | <v4vu1e$27o1c$1@dont-email.me> |
| In reply to | #107464 |
On 6/19/2024 7:23 PM, Richard Damon wrote:
> On 6/19/24 9:00 AM, olcott wrote:
>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>
>>>>>> It is a verified fact that serious C people have recently
>>>>>> agreed to the following verbatim statement in the C group.
>>>>
>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>
>>>>>> You either lack this degree of skill in C or are only
>>>>>> interested in playing head games.
>>>>>
>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>> But you know apparently to little of C to understand that.
>>>>> Probably, because you are unable to escape from rebuttal mode, even
>>>>> if the truth is obvious.
>>>>>
>>>>
>>>> I have known C since K&R was the standard and met
>>>> Bjarne Stroustrup when he came to our university
>>>> to promote his new C++ programming language.
>>>>
>>>> *You seem to be willfully ignorant*
>>>>
>>>>> It was your own proof that showed that in
>>>>>
>>>>> int main()
>>>>> {
>>>>> return H(main);
>>>>> }
>>>>>
>>>>>
>>>>> main halts, whereas H reported non-halting. So, it you were honest
>>>>> you would stop claiming that H is correct.
>>>>>
>>>>
>>>> That is merely a more difficult to understand version of this
>>>> same pathological relationship.
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", HH0(main));
>>>> }
>>>>
>>>> _main()
>>>> [000020c2] 55 push ebp
>>>> [000020c3] 8bec mov ebp,esp
>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>> [000020cf] 83c404 add esp,+04
>>>> [000020d2] 50 push eax
>>>> [000020d3] 6843070000 push 00000743
>>>> [000020d8] e885e6ffff call 00000762
>>>> [000020dd] 83c408 add esp,+08
>>>> [000020e0] eb04 jmp 000020e6
>>>> [000020e2] 33c0 xor eax,eax
>>>> [000020e4] eb02 jmp 000020e8
>>>> [000020e6] 33c0 xor eax,eax
>>>> [000020e8] 5d pop ebp
>>>> [000020e9] c3 ret
>>>> Size in bytes:(0040) [000020e9]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> New slave_stack at:103767
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> New slave_stack at:14e18f
>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>> [000020d2][001036bf][00000000] 50 push eax
>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>> Input_Halts = 0
>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>
>>>
>>> It is easier to understand because a print statement was added.
>>> You proved that it halts, but H0 reports non-halting.
>>> So, it produces a false negative.
>>> So, now it has been proved that H, H0, etc produce false negatives,
>>> when used to determine halting behaviour, please, stop to call them
>>> halt-deciders, or termination-deciders.
>>> They might be "simulation deciders". When returning true, the
>>> simulation was correct, when false, the full simulation was not
>>> possible.
>>
>> I don't want to discuss your screwy example because I
>> can't use screwy examples in my paper.
>>
>> void DDD()
>> {
>> H0(DDD);
>> }
>>
>> _DDD()
>> [000020a2] 55 push ebp ; housekeeping
>> [000020a3] 8bec mov ebp,esp ; housekeeping
>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>> [000020af] 83c404 add esp,+04 ; housekeeping
>> [000020b2] 5d pop ebp ; housekeeping
>> [000020b3] c3 ret ; never gets here
>> Size in bytes:(0018) [000020b3]
>>
>> Exactly which step of DDD emulated by H0 was emulated
>> incorrectly such that this emulation would be complete?
>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>
>>
>
> Why does H0 NEED to be able to correctly simulate its input?
>
Decider must compute the mapping from their finite string
input to the actual behavior that this finite string specifies.
They are not free to imagine the behavior that the authors of
textbooks expect.
> Your question is just a Strawman, replacing the OBJECTIVE criteria of
> the behavior of the machine represented by the input (which inlcudes the
> code for H0) with the SUBJECTIVE question of what H0 thinks about it.
>
> And, your H0 doesn't correctly simulate the input, as the *ONLY* correct
> simulation of that input would be:
>
> simulate the push ebp
> simulate the mov ebp,esp
> simulate the push 000020a2
> simulate the call 00001aa2
> simulate the instruction at 00001aa2
>
I now have a 195 page color-coded execution trace
showing HH0 correctly simulating DDD calling
a simulated HH0 simulating another instance of DDD.
https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
> since that isn't what you have ever shown as the simulation by H0, you
> have lost the right to call its simulation "correct".
>
> Sorry, your argument is just a lie.
*It never has been a falsehood*
--
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 | 2024-06-19 21:39 -0400 |
| Message-ID | <v5019d$ggem$6@i2pn2.org> |
| In reply to | #107469 |
On 6/19/24 8:44 PM, olcott wrote:
> On 6/19/2024 7:23 PM, Richard Damon wrote:
>> On 6/19/24 9:00 AM, olcott wrote:
>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>
>>>>>>> It is a verified fact that serious C people have recently
>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>
>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>
>>>>>>> You either lack this degree of skill in C or are only
>>>>>>> interested in playing head games.
>>>>>>
>>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>>> But you know apparently to little of C to understand that.
>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>> even if the truth is obvious.
>>>>>>
>>>>>
>>>>> I have known C since K&R was the standard and met
>>>>> Bjarne Stroustrup when he came to our university
>>>>> to promote his new C++ programming language.
>>>>>
>>>>> *You seem to be willfully ignorant*
>>>>>
>>>>>> It was your own proof that showed that in
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> return H(main);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> main halts, whereas H reported non-halting. So, it you were honest
>>>>>> you would stop claiming that H is correct.
>>>>>>
>>>>>
>>>>> That is merely a more difficult to understand version of this
>>>>> same pathological relationship.
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", HH0(main));
>>>>> }
>>>>>
>>>>> _main()
>>>>> [000020c2] 55 push ebp
>>>>> [000020c3] 8bec mov ebp,esp
>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>> [000020cf] 83c404 add esp,+04
>>>>> [000020d2] 50 push eax
>>>>> [000020d3] 6843070000 push 00000743
>>>>> [000020d8] e885e6ffff call 00000762
>>>>> [000020dd] 83c408 add esp,+08
>>>>> [000020e0] eb04 jmp 000020e6
>>>>> [000020e2] 33c0 xor eax,eax
>>>>> [000020e4] eb02 jmp 000020e8
>>>>> [000020e6] 33c0 xor eax,eax
>>>>> [000020e8] 5d pop ebp
>>>>> [000020e9] c3 ret
>>>>> Size in bytes:(0040) [000020e9]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> New slave_stack at:103767
>>>>>
>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:11376f
>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> New slave_stack at:14e18f
>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>
>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>> Input_Halts = 0
>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>
>>>>
>>>> It is easier to understand because a print statement was added.
>>>> You proved that it halts, but H0 reports non-halting.
>>>> So, it produces a false negative.
>>>> So, now it has been proved that H, H0, etc produce false negatives,
>>>> when used to determine halting behaviour, please, stop to call them
>>>> halt-deciders, or termination-deciders.
>>>> They might be "simulation deciders". When returning true, the
>>>> simulation was correct, when false, the full simulation was not
>>>> possible.
>>>
>>> I don't want to discuss your screwy example because I
>>> can't use screwy examples in my paper.
>>>
>>> void DDD()
>>> {
>>> H0(DDD);
>>> }
>>>
>>> _DDD()
>>> [000020a2] 55 push ebp ; housekeeping
>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>> [000020b2] 5d pop ebp ; housekeeping
>>> [000020b3] c3 ret ; never gets here
>>> Size in bytes:(0018) [000020b3]
>>>
>>> Exactly which step of DDD emulated by H0 was emulated
>>> incorrectly such that this emulation would be complete?
>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>
>>>
>>
>> Why does H0 NEED to be able to correctly simulate its input?
>>
>
> Decider must compute the mapping from their finite string
> input to the actual behavior that this finite string specifies.
> They are not free to imagine the behavior that the authors of
> textbooks expect.
AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
Yes, the DO need to follow the behavior that the author of the problem
defined.
You are just showing you think it is ok to not follow the REQURIEMENTS
and just LIE about what you are doing.
>
>> Your question is just a Strawman, replacing the OBJECTIVE criteria of
>> the behavior of the machine represented by the input (which inlcudes
>> the code for H0) with the SUBJECTIVE question of what H0 thinks about it.
>>
>> And, your H0 doesn't correctly simulate the input, as the *ONLY*
>> correct simulation of that input would be:
>>
>> simulate the push ebp
>> simulate the mov ebp,esp
>> simulate the push 000020a2
>> simulate the call 00001aa2
>> simulate the instruction at 00001aa2
>>
>
> I now have a 195 page color-coded execution trace
> showing HH0 correctly simulating DDD calling
> a simulated HH0 simulating another instance of DDD.
> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
I'll look into it in more details later, but this is what comes from a
quick look.
The first thing I note, is just like that last one, the TRACE doesn't
start until page 36, so is not as long as you claim. It is nice that you
include the x86 assembly of the program. But it also shows that
something isn't as it seems as there are a lot of functions like:
_OutputString()
[00000743] 55 push ebp
[00000744] 8bec move ebp, esp
[00000746] 5d pop. ebp
[00000747] c3 ret
Size in bytes:(0005) [00000747]
Which your tracing seems to ignore, and the seem to end up doing
something not shown, so clearly, there is activity not being traced and
being hidden. This could be called a LIE.
Also, something is funny about the formatting of the text of the PDF,
like it is edited and reformatted as it doesn't copy and paste well.
First, again, the simulation starts as:
[000020b3][00103680][00000000] 55. push. ebp
[000020b4][00103680][00000000] 8bec. mov ebp, esp
[000020b6][0010367c][00002093] 6893200000 push 00002093
and the code at 20b3 is the code of main, not DDD, so again, this is the
wrong trace. The trace from H0, will start at the instructions of DDD,
at address 00002093
So, this is NOT the trace of HH0(DDD,DDD)
Did you confuse me with someone else you were arguing about and forgot
what the actual problem was.
Then on page 37, we see:
[000012d1][00103620][000003db] e87df4ffff call 00000753
New slave_stack at:103724
[000012d6][00103628][00103674] 83c408 add esp,+08
So, again, your trace isn't actually a correct x86 trace of the actual
code being executed. And these functions at these addresses seem to be
something "magic" as the code shown doesn't match the names given.
SO, it seems something may be rotten in Denmark here.
Then we have on page 43: (spaces and comments added)
[000011dc][00103604][001036ac] 52. push edx
[000011dd][00103604][001036ac] e8b1f5ffff call 00000793
[0000209b][00113714][000020a0] e853f4ffff call 000014f3
The above is NOT a correct simulation of the code that is currently
being simulated by the top level decider, then it gets back to its
proper trace.
[000011e2][00103610][0011372c] 83c40c add esp,+0c
If this is showing a simulation at a different level, it really should
be more clearly indicated
>
>> since that isn't what you have ever shown as the simulation by H0, you
>> have lost the right to call its simulation "correct".
>>
>> Sorry, your argument is just a lie.
>
> *It never has been a falsehood*
>
It has ALWAYS been. You just don't seem to know the meaning of truth.
Look, you repeated the exact same error, even though you apparently did
look at the document to add color coding. (or had a program do it).
It is clear you don't understand about what a correct simulation trace
of your decider simulating the input DDD,DDD
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 21:02 -0500 |
| Message-ID | <v502jc$2ccjk$1@dont-email.me> |
| In reply to | #107470 |
On 6/19/2024 8:39 PM, Richard Damon wrote:
> On 6/19/24 8:44 PM, olcott wrote:
>> On 6/19/2024 7:23 PM, Richard Damon wrote:
>>> On 6/19/24 9:00 AM, olcott wrote:
>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>
>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>
>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>
>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>> interested in playing head games.
>>>>>>>
>>>>>>> I have seen the response. It was most certainly not a serious reply.
>>>>>>> But you know apparently to little of C to understand that.
>>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>>> even if the truth is obvious.
>>>>>>>
>>>>>>
>>>>>> I have known C since K&R was the standard and met
>>>>>> Bjarne Stroustrup when he came to our university
>>>>>> to promote his new C++ programming language.
>>>>>>
>>>>>> *You seem to be willfully ignorant*
>>>>>>
>>>>>>> It was your own proof that showed that in
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> return H(main);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>
>>>>>>
>>>>>> That is merely a more difficult to understand version of this
>>>>>> same pathological relationship.
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>> }
>>>>>>
>>>>>> _main()
>>>>>> [000020c2] 55 push ebp
>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>> [000020cf] 83c404 add esp,+04
>>>>>> [000020d2] 50 push eax
>>>>>> [000020d3] 6843070000 push 00000743
>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>> [000020dd] 83c408 add esp,+08
>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>> [000020e8] 5d pop ebp
>>>>>> [000020e9] c3 ret
>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>
>>>>>> machine stack stack machine assembly
>>>>>> address address data code language
>>>>>> ======== ======== ======== ========= =============
>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> New slave_stack at:103767
>>>>>>
>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>> at:11376f
>>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> New slave_stack at:14e18f
>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>
>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>> Input_Halts = 0
>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>
>>>>>
>>>>> It is easier to understand because a print statement was added.
>>>>> You proved that it halts, but H0 reports non-halting.
>>>>> So, it produces a false negative.
>>>>> So, now it has been proved that H, H0, etc produce false negatives,
>>>>> when used to determine halting behaviour, please, stop to call them
>>>>> halt-deciders, or termination-deciders.
>>>>> They might be "simulation deciders". When returning true, the
>>>>> simulation was correct, when false, the full simulation was not
>>>>> possible.
>>>>
>>>> I don't want to discuss your screwy example because I
>>>> can't use screwy examples in my paper.
>>>>
>>>> void DDD()
>>>> {
>>>> H0(DDD);
>>>> }
>>>>
>>>> _DDD()
>>>> [000020a2] 55 push ebp ; housekeeping
>>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>>> [000020b2] 5d pop ebp ; housekeeping
>>>> [000020b3] c3 ret ; never gets here
>>>> Size in bytes:(0018) [000020b3]
>>>>
>>>> Exactly which step of DDD emulated by H0 was emulated
>>>> incorrectly such that this emulation would be complete?
>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>
>>>>
>>>
>>> Why does H0 NEED to be able to correctly simulate its input?
>>>
>>
>> Decider must compute the mapping from their finite string
>> input to the actual behavior that this finite string specifies.
>> They are not free to imagine the behavior that the authors of
>> textbooks expect.
>
> AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
> EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
>
> Yes, the DO need to follow the behavior that the author of the problem
> defined.
>
> You are just showing you think it is ok to not follow the REQURIEMENTS
> and just LIE about what you are doing.
>
The finite string input does not communicate the behavior
that the textbook authors expect it to communicate.
--
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 | 2024-06-19 22:17 -0400 |
| Message-ID | <v503fg$ggen$1@i2pn2.org> |
| In reply to | #107471 |
On 6/19/24 10:02 PM, olcott wrote:
> On 6/19/2024 8:39 PM, Richard Damon wrote:
>> On 6/19/24 8:44 PM, olcott wrote:
>>> On 6/19/2024 7:23 PM, Richard Damon wrote:
>>>> On 6/19/24 9:00 AM, olcott wrote:
>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>>
>>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>>
>>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>>
>>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>>> interested in playing head games.
>>>>>>>>
>>>>>>>> I have seen the response. It was most certainly not a serious
>>>>>>>> reply.
>>>>>>>> But you know apparently to little of C to understand that.
>>>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>>>> even if the truth is obvious.
>>>>>>>>
>>>>>>>
>>>>>>> I have known C since K&R was the standard and met
>>>>>>> Bjarne Stroustrup when he came to our university
>>>>>>> to promote his new C++ programming language.
>>>>>>>
>>>>>>> *You seem to be willfully ignorant*
>>>>>>>
>>>>>>>> It was your own proof that showed that in
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> return H(main);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>>
>>>>>>>
>>>>>>> That is merely a more difficult to understand version of this
>>>>>>> same pathological relationship.
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>>> }
>>>>>>>
>>>>>>> _main()
>>>>>>> [000020c2] 55 push ebp
>>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>>> [000020cf] 83c404 add esp,+04
>>>>>>> [000020d2] 50 push eax
>>>>>>> [000020d3] 6843070000 push 00000743
>>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>>> [000020dd] 83c408 add esp,+08
>>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>>> [000020e8] 5d pop ebp
>>>>>>> [000020e9] c3 ret
>>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>>
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> New slave_stack at:103767
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>>> at:11376f
>>>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
>>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> New slave_stack at:14e18f
>>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin main
>>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>
>>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>>> Input_Halts = 0
>>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>>
>>>>>>
>>>>>> It is easier to understand because a print statement was added.
>>>>>> You proved that it halts, but H0 reports non-halting.
>>>>>> So, it produces a false negative.
>>>>>> So, now it has been proved that H, H0, etc produce false
>>>>>> negatives, when used to determine halting behaviour, please, stop
>>>>>> to call them halt-deciders, or termination-deciders.
>>>>>> They might be "simulation deciders". When returning true, the
>>>>>> simulation was correct, when false, the full simulation was not
>>>>>> possible.
>>>>>
>>>>> I don't want to discuss your screwy example because I
>>>>> can't use screwy examples in my paper.
>>>>>
>>>>> void DDD()
>>>>> {
>>>>> H0(DDD);
>>>>> }
>>>>>
>>>>> _DDD()
>>>>> [000020a2] 55 push ebp ; housekeeping
>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>>>> [000020b2] 5d pop ebp ; housekeeping
>>>>> [000020b3] c3 ret ; never gets here
>>>>> Size in bytes:(0018) [000020b3]
>>>>>
>>>>> Exactly which step of DDD emulated by H0 was emulated
>>>>> incorrectly such that this emulation would be complete?
>>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>>
>>>>>
>>>>
>>>> Why does H0 NEED to be able to correctly simulate its input?
>>>>
>>>
>>> Decider must compute the mapping from their finite string
>>> input to the actual behavior that this finite string specifies.
>>> They are not free to imagine the behavior that the authors of
>>> textbooks expect.
>>
>> AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
>> EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
>>
>> Yes, the DO need to follow the behavior that the author of the problem
>> defined.
>>
>> You are just showing you think it is ok to not follow the REQURIEMENTS
>> and just LIE about what you are doing.
>>
> The finite string input does not communicate the behavior
> that the textbook authors expect it to communicate.
>
The finite string certainly DOES communicate what is needed to determine
the behavior, or it wasn't a correct representation.
For instance, the x86 code of the full program DDD gives enough
information to fully determine the bahavior of the program the input
represents.
If you don't give the full code, then you LIED in saying that DDD was
constructed per the Linz proof.
Your LIE of showing he input as only inlcuding the x86 code of the
immediate function says either you don't understand what is needed for
the the decider to understand its input, or have just been lying about
what you are doing.
Of course, your decider treats the input as if it was given all the data
it needed, as it at least claims to undertand the meaning of the call to
the decider.
Now, the finite string do NOT give the definition of the question the
decider is supposed to be answering, because that isn't the job of the
input.
That is the job of the programmer who wrote the decider, and if he can't
read the textbook, he should claim that he followed their rules and
built a Halt Decider.
Now, if you want to claim your H as a Universal decider, then you need
to define how we are to specify every question, and if you can't show
how to do, you just admitted that you didn't do what you claimed.
So, in summary, you just showed you don't understand what a requirement
is, so you can't understand what truth is as it is based on requirements.
Sorry, you are just showing your complete stupidity.
I note, you didn't comment on how I quickly determined that you AGAIN
lied about producing the output of your decider correctly simulating its
input of the pathological program.
I guess you are just making it VERY CLEAR that you just don't understand
what you are talking about.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-19 21:25 -0500 |
| Message-ID | <v503ur$2ccjk$2@dont-email.me> |
| In reply to | #107472 |
On 6/19/2024 9:17 PM, Richard Damon wrote:
> On 6/19/24 10:02 PM, olcott wrote:
>> On 6/19/2024 8:39 PM, Richard Damon wrote:
>>> On 6/19/24 8:44 PM, olcott wrote:
>>>> On 6/19/2024 7:23 PM, Richard Damon wrote:
>>>>> On 6/19/24 9:00 AM, olcott wrote:
>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>>>
>>>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>>>
>>>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>>>
>>>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>>>> interested in playing head games.
>>>>>>>>>
>>>>>>>>> I have seen the response. It was most certainly not a serious
>>>>>>>>> reply.
>>>>>>>>> But you know apparently to little of C to understand that.
>>>>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>>>>> even if the truth is obvious.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have known C since K&R was the standard and met
>>>>>>>> Bjarne Stroustrup when he came to our university
>>>>>>>> to promote his new C++ programming language.
>>>>>>>>
>>>>>>>> *You seem to be willfully ignorant*
>>>>>>>>
>>>>>>>>> It was your own proof that showed that in
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> return H(main);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is merely a more difficult to understand version of this
>>>>>>>> same pathological relationship.
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _main()
>>>>>>>> [000020c2] 55 push ebp
>>>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>>>> [000020cf] 83c404 add esp,+04
>>>>>>>> [000020d2] 50 push eax
>>>>>>>> [000020d3] 6843070000 push 00000743
>>>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>>>> [000020dd] 83c408 add esp,+08
>>>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>>>> [000020e8] 5d pop ebp
>>>>>>>> [000020e9] c3 ret
>>>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>>>
>>>>>>>> machine stack stack machine assembly
>>>>>>>> address address data code language
>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>>> New slave_stack at:103767
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>>>> at:11376f
>>>>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin
>>>>>>>> main
>>>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>>> New slave_stack at:14e18f
>>>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin
>>>>>>>> main
>>>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
>>>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>>
>>>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>>>> Input_Halts = 0
>>>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit main
>>>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>>>
>>>>>>>
>>>>>>> It is easier to understand because a print statement was added.
>>>>>>> You proved that it halts, but H0 reports non-halting.
>>>>>>> So, it produces a false negative.
>>>>>>> So, now it has been proved that H, H0, etc produce false
>>>>>>> negatives, when used to determine halting behaviour, please, stop
>>>>>>> to call them halt-deciders, or termination-deciders.
>>>>>>> They might be "simulation deciders". When returning true, the
>>>>>>> simulation was correct, when false, the full simulation was not
>>>>>>> possible.
>>>>>>
>>>>>> I don't want to discuss your screwy example because I
>>>>>> can't use screwy examples in my paper.
>>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>> H0(DDD);
>>>>>> }
>>>>>>
>>>>>> _DDD()
>>>>>> [000020a2] 55 push ebp ; housekeeping
>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>>>>> [000020b2] 5d pop ebp ; housekeeping
>>>>>> [000020b3] c3 ret ; never gets here
>>>>>> Size in bytes:(0018) [000020b3]
>>>>>>
>>>>>> Exactly which step of DDD emulated by H0 was emulated
>>>>>> incorrectly such that this emulation would be complete?
>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>>>
>>>>>>
>>>>>
>>>>> Why does H0 NEED to be able to correctly simulate its input?
>>>>>
>>>>
>>>> Decider must compute the mapping from their finite string
>>>> input to the actual behavior that this finite string specifies.
>>>> They are not free to imagine the behavior that the authors of
>>>> textbooks expect.
>>>
>>> AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
>>> EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
>>>
>>> Yes, the DO need to follow the behavior that the author of the
>>> problem defined.
>>>
>>> You are just showing you think it is ok to not follow the
>>> REQURIEMENTS and just LIE about what you are doing.
>>>
>> The finite string input does not communicate the behavior
>> that the textbook authors expect it to communicate.
>>
>
> The finite string certainly DOES communicate what is needed to determine
> the behavior, or it wasn't a correct representation.
>
There is no sequence of truth preserving operations from the finite
string machine code of DDD that can correctly ignore the pathological
relationship between H0 and DDD as an aspect of the behavior that
this finite string specifies.
No one has noticed this before because no one ever thought to make
every single detail 100% concrete, thus leaving huge gaps in all
prior reasoning.
--
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 | 2024-06-20 07:33 -0400 |
| Message-ID | <v5142v$hpdb$1@i2pn2.org> |
| In reply to | #107473 |
On 6/19/24 10:25 PM, olcott wrote:
> On 6/19/2024 9:17 PM, Richard Damon wrote:
>> On 6/19/24 10:02 PM, olcott wrote:
>>> On 6/19/2024 8:39 PM, Richard Damon wrote:
>>>> On 6/19/24 8:44 PM, olcott wrote:
>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote:
>>>>>> On 6/19/24 9:00 AM, olcott wrote:
>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>>>>
>>>>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>>>>
>>>>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>>>>
>>>>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>>>>> interested in playing head games.
>>>>>>>>>>
>>>>>>>>>> I have seen the response. It was most certainly not a serious
>>>>>>>>>> reply.
>>>>>>>>>> But you know apparently to little of C to understand that.
>>>>>>>>>> Probably, because you are unable to escape from rebuttal mode,
>>>>>>>>>> even if the truth is obvious.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have known C since K&R was the standard and met
>>>>>>>>> Bjarne Stroustrup when he came to our university
>>>>>>>>> to promote his new C++ programming language.
>>>>>>>>>
>>>>>>>>> *You seem to be willfully ignorant*
>>>>>>>>>
>>>>>>>>>> It was your own proof that showed that in
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> return H(main);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is merely a more difficult to understand version of this
>>>>>>>>> same pathological relationship.
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _main()
>>>>>>>>> [000020c2] 55 push ebp
>>>>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>>>>> [000020cf] 83c404 add esp,+04
>>>>>>>>> [000020d2] 50 push eax
>>>>>>>>> [000020d3] 6843070000 push 00000743
>>>>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>>>>> [000020dd] 83c408 add esp,+08
>>>>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>>>>> [000020e8] 5d pop ebp
>>>>>>>>> [000020e9] c3 ret
>>>>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>>>>
>>>>>>>>> machine stack stack machine assembly
>>>>>>>>> address address data code language
>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push
>>>>>>>>> main
>>>>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>>>> New slave_stack at:103767
>>>>>>>>>
>>>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>>>>> at:11376f
>>>>>>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin
>>>>>>>>> main
>>>>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push
>>>>>>>>> main
>>>>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>>>> New slave_stack at:14e18f
>>>>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ; begin
>>>>>>>>> main
>>>>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push
>>>>>>>>> main
>>>>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>>>>>>
>>>>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>>>>> Input_Halts = 0
>>>>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit
>>>>>>>>> main
>>>>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is easier to understand because a print statement was added.
>>>>>>>> You proved that it halts, but H0 reports non-halting.
>>>>>>>> So, it produces a false negative.
>>>>>>>> So, now it has been proved that H, H0, etc produce false
>>>>>>>> negatives, when used to determine halting behaviour, please,
>>>>>>>> stop to call them halt-deciders, or termination-deciders.
>>>>>>>> They might be "simulation deciders". When returning true, the
>>>>>>>> simulation was correct, when false, the full simulation was not
>>>>>>>> possible.
>>>>>>>
>>>>>>> I don't want to discuss your screwy example because I
>>>>>>> can't use screwy examples in my paper.
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> H0(DDD);
>>>>>>> }
>>>>>>>
>>>>>>> _DDD()
>>>>>>> [000020a2] 55 push ebp ; housekeeping
>>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>>>>>> [000020b2] 5d pop ebp ; housekeeping
>>>>>>> [000020b3] c3 ret ; never gets here
>>>>>>> Size in bytes:(0018) [000020b3]
>>>>>>>
>>>>>>> Exactly which step of DDD emulated by H0 was emulated
>>>>>>> incorrectly such that this emulation would be complete?
>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Why does H0 NEED to be able to correctly simulate its input?
>>>>>>
>>>>>
>>>>> Decider must compute the mapping from their finite string
>>>>> input to the actual behavior that this finite string specifies.
>>>>> They are not free to imagine the behavior that the authors of
>>>>> textbooks expect.
>>>>
>>>> AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
>>>> EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
>>>>
>>>> Yes, the DO need to follow the behavior that the author of the
>>>> problem defined.
>>>>
>>>> You are just showing you think it is ok to not follow the
>>>> REQURIEMENTS and just LIE about what you are doing.
>>>>
>>> The finite string input does not communicate the behavior
>>> that the textbook authors expect it to communicate.
>>>
>>
>> The finite string certainly DOES communicate what is needed to
>> determine the behavior, or it wasn't a correct representation.
>>
>
> There is no sequence of truth preserving operations from the finite
> string machine code of DDD that can correctly ignore the pathological
> relationship between H0 and DDD as an aspect of the behavior that
> this finite string specifies.
>
Why does it need to "ignore" the relationship. We can in a finite number
of operations show that the machine code of DDD (but we need ALL the
machine code of DDD, including the functions it calls) show that DDD
represents a Halting Program if the decider does what you claim, and
returns 0 in a finite amount of time.
Therefore, we can PROVE that your decider is wrong, and that you don;t
understand what you are talkinga about.
> No one has noticed this before because no one ever thought to make
> every single detail 100% concrete, thus leaving huge gaps in all
> prior reasoning.
>
Nope, you are seeing phantoms, because you somehow think that the
Decider MUST be right, and if the world doesn't let it be, then the
world is wrong.
This is your fundamental problem, you think, because of your "god
complex" that you must be right, but that is not so. If you were diety,
then you would not be dying of cancer. IF you don't have enough command
over your body to fix that, you don't have command over truth to make it
what you want.
You have just lied to yourself so much that you believe in yourself, but
that means you have beleived in a liar.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 09:58 -0500 |
| Message-ID | <v51g33$2kbbe$1@dont-email.me> |
| In reply to | #107488 |
On 6/20/2024 6:33 AM, Richard Damon wrote:
> On 6/19/24 10:25 PM, olcott wrote:
>> On 6/19/2024 9:17 PM, Richard Damon wrote:
>>> On 6/19/24 10:02 PM, olcott wrote:
>>>> On 6/19/2024 8:39 PM, Richard Damon wrote:
>>>>> On 6/19/24 8:44 PM, olcott wrote:
>>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote:
>>>>>>> On 6/19/24 9:00 AM, olcott wrote:
>>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>>>>>
>>>>>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>>>>>
>>>>>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>>>>>> interested in playing head games.
>>>>>>>>>>>
>>>>>>>>>>> I have seen the response. It was most certainly not a serious
>>>>>>>>>>> reply.
>>>>>>>>>>> But you know apparently to little of C to understand that.
>>>>>>>>>>> Probably, because you are unable to escape from rebuttal
>>>>>>>>>>> mode, even if the truth is obvious.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have known C since K&R was the standard and met
>>>>>>>>>> Bjarne Stroustrup when he came to our university
>>>>>>>>>> to promote his new C++ programming language.
>>>>>>>>>>
>>>>>>>>>> *You seem to be willfully ignorant*
>>>>>>>>>>
>>>>>>>>>>> It was your own proof that showed that in
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> return H(main);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is merely a more difficult to understand version of this
>>>>>>>>>> same pathological relationship.
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _main()
>>>>>>>>>> [000020c2] 55 push ebp
>>>>>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>>>>>> [000020cf] 83c404 add esp,+04
>>>>>>>>>> [000020d2] 50 push eax
>>>>>>>>>> [000020d3] 6843070000 push 00000743
>>>>>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>>>>>> [000020dd] 83c408 add esp,+08
>>>>>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>>>>>> [000020e8] 5d pop ebp
>>>>>>>>>> [000020e9] c3 ret
>>>>>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>>>>>
>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>> address address data code language
>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push
>>>>>>>>>> main
>>>>>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call
>>>>>>>>>> HH0
>>>>>>>>>> New slave_stack at:103767
>>>>>>>>>>
>>>>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>>>>>> at:11376f
>>>>>>>>>> [000020c2][0011375f][00113763] 55 push ebp ;
>>>>>>>>>> begin main
>>>>>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push
>>>>>>>>>> main
>>>>>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call
>>>>>>>>>> HH0
>>>>>>>>>> New slave_stack at:14e18f
>>>>>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ;
>>>>>>>>>> begin main
>>>>>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push
>>>>>>>>>> main
>>>>>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call
>>>>>>>>>> HH0
>>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>>>>>> Stopped
>>>>>>>>>>
>>>>>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>>>>>> Input_Halts = 0
>>>>>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>>>>>> [000020e9][001036cb][00000000] c3 ret ; exit
>>>>>>>>>> main
>>>>>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is easier to understand because a print statement was added.
>>>>>>>>> You proved that it halts, but H0 reports non-halting.
>>>>>>>>> So, it produces a false negative.
>>>>>>>>> So, now it has been proved that H, H0, etc produce false
>>>>>>>>> negatives, when used to determine halting behaviour, please,
>>>>>>>>> stop to call them halt-deciders, or termination-deciders.
>>>>>>>>> They might be "simulation deciders". When returning true, the
>>>>>>>>> simulation was correct, when false, the full simulation was not
>>>>>>>>> possible.
>>>>>>>>
>>>>>>>> I don't want to discuss your screwy example because I
>>>>>>>> can't use screwy examples in my paper.
>>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>> H0(DDD);
>>>>>>>> }
>>>>>>>>
>>>>>>>> _DDD()
>>>>>>>> [000020a2] 55 push ebp ; housekeeping
>>>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>>>>>>> [000020b2] 5d pop ebp ; housekeeping
>>>>>>>> [000020b3] c3 ret ; never gets here
>>>>>>>> Size in bytes:(0018) [000020b3]
>>>>>>>>
>>>>>>>> Exactly which step of DDD emulated by H0 was emulated
>>>>>>>> incorrectly such that this emulation would be complete?
>>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Why does H0 NEED to be able to correctly simulate its input?
>>>>>>>
>>>>>>
>>>>>> Decider must compute the mapping from their finite string
>>>>>> input to the actual behavior that this finite string specifies.
>>>>>> They are not free to imagine the behavior that the authors of
>>>>>> textbooks expect.
>>>>>
>>>>> AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
>>>>> EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
>>>>>
>>>>> Yes, the DO need to follow the behavior that the author of the
>>>>> problem defined.
>>>>>
>>>>> You are just showing you think it is ok to not follow the
>>>>> REQURIEMENTS and just LIE about what you are doing.
>>>>>
>>>> The finite string input does not communicate the behavior
>>>> that the textbook authors expect it to communicate.
>>>>
>>>
>>> The finite string certainly DOES communicate what is needed to
>>> determine the behavior, or it wasn't a correct representation.
>>>
>>
>> There is no sequence of truth preserving operations from the finite
>> string machine code of DDD that can correctly ignore the pathological
>> relationship between H0 and DDD as an aspect of the behavior that
>> this finite string specifies.
>>
>
> Why does it need to "ignore" the relationship. We can in a finite number
> of operations show that the machine code of DDD (but we need ALL the
> machine code of DDD, including the functions it calls) show that DDD
> represents a Halting Program if the decider does what you claim, and
> returns 0 in a finite amount of time.
>
_DDD()
[00002093] 55 push ebp
[00002094] 8bec mov ebp,esp
[00002096] 6893200000 push 00002093
[0000209b] e853f4ffff call 000014f3
[000020a0] 83c404 add esp,+04
[000020a3] 5d pop ebp
[000020a4] c3 ret
Size in bytes:(0018) [000020a4]
We can see that H0 halts and you seem insufficiently technically
competent or outright dishonest when you imply
that H0 cannot
see that DDD correctly simulated by H0 cannot possibly get past
its own [0000209b] machine address in a finite number of steps.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H *correctly simulates its input D*
*until H correctly determines that its simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
--
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 | 2024-06-20 21:55 -0400 |
| Message-ID | <v52mid$jund$2@i2pn2.org> |
| In reply to | #107495 |
On 6/20/24 10:58 AM, olcott wrote:
> On 6/20/2024 6:33 AM, Richard Damon wrote:
>> On 6/19/24 10:25 PM, olcott wrote:
>>> On 6/19/2024 9:17 PM, Richard Damon wrote:
>>>> On 6/19/24 10:02 PM, olcott wrote:
>>>>> On 6/19/2024 8:39 PM, Richard Damon wrote:
>>>>>> On 6/19/24 8:44 PM, olcott wrote:
>>>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote:
>>>>>>>> On 6/19/24 9:00 AM, olcott wrote:
>>>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott:
>>>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
>>>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott:
>>>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is a verified fact that serious C people have recently
>>>>>>>>>>>>> agreed to the following verbatim statement in the C group.
>>>>>>>>>>>
>>>>>>>>>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
>>>>>>>>>>>
>>>>>>>>>>>>> You either lack this degree of skill in C or are only
>>>>>>>>>>>>> interested in playing head games.
>>>>>>>>>>>>
>>>>>>>>>>>> I have seen the response. It was most certainly not a
>>>>>>>>>>>> serious reply.
>>>>>>>>>>>> But you know apparently to little of C to understand that.
>>>>>>>>>>>> Probably, because you are unable to escape from rebuttal
>>>>>>>>>>>> mode, even if the truth is obvious.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have known C since K&R was the standard and met
>>>>>>>>>>> Bjarne Stroustrup when he came to our university
>>>>>>>>>>> to promote his new C++ programming language.
>>>>>>>>>>>
>>>>>>>>>>> *You seem to be willfully ignorant*
>>>>>>>>>>>
>>>>>>>>>>>> It was your own proof that showed that in
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> return H(main);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> main halts, whereas H reported non-halting. So, it you were
>>>>>>>>>>>> honest you would stop claiming that H is correct.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That is merely a more difficult to understand version of this
>>>>>>>>>>> same pathological relationship.
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", HH0(main));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _main()
>>>>>>>>>>> [000020c2] 55 push ebp
>>>>>>>>>>> [000020c3] 8bec mov ebp,esp
>>>>>>>>>>> [000020c5] 68c2200000 push 000020c2 ; push main
>>>>>>>>>>> [000020ca] e833f4ffff call 00001502 ; call HH0
>>>>>>>>>>> [000020cf] 83c404 add esp,+04
>>>>>>>>>>> [000020d2] 50 push eax
>>>>>>>>>>> [000020d3] 6843070000 push 00000743
>>>>>>>>>>> [000020d8] e885e6ffff call 00000762
>>>>>>>>>>> [000020dd] 83c408 add esp,+08
>>>>>>>>>>> [000020e0] eb04 jmp 000020e6
>>>>>>>>>>> [000020e2] 33c0 xor eax,eax
>>>>>>>>>>> [000020e4] eb02 jmp 000020e8
>>>>>>>>>>> [000020e6] 33c0 xor eax,eax
>>>>>>>>>>> [000020e8] 5d pop ebp
>>>>>>>>>>> [000020e9] c3 ret
>>>>>>>>>>> Size in bytes:(0040) [000020e9]
>>>>>>>>>>>
>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>> address address data code language
>>>>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>>>>> [000020c2][001036c3][00000000] 55 push ebp
>>>>>>>>>>> [000020c3][001036c3][00000000] 8bec mov ebp,esp
>>>>>>>>>>> [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ;
>>>>>>>>>>> push main
>>>>>>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ;
>>>>>>>>>>> call HH0
>>>>>>>>>>> New slave_stack at:103767
>>>>>>>>>>>
>>>>>>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>>>>>>>>> at:11376f
>>>>>>>>>>> [000020c2][0011375f][00113763] 55 push ebp ;
>>>>>>>>>>> begin main
>>>>>>>>>>> [000020c3][0011375f][00113763] 8bec mov ebp,esp
>>>>>>>>>>> [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ;
>>>>>>>>>>> push main
>>>>>>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ;
>>>>>>>>>>> call HH0
>>>>>>>>>>> New slave_stack at:14e18f
>>>>>>>>>>> [000020c2][0015e187][0015e18b] 55 push ebp ;
>>>>>>>>>>> begin main
>>>>>>>>>>> [000020c3][0015e187][0015e18b] 8bec mov ebp,esp
>>>>>>>>>>> [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ;
>>>>>>>>>>> push main
>>>>>>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ;
>>>>>>>>>>> call HH0
>>>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>>>>>>> Stopped
>>>>>>>>>>>
>>>>>>>>>>> [000020cf][001036c3][00000000] 83c404 add esp,+04
>>>>>>>>>>> [000020d2][001036bf][00000000] 50 push eax
>>>>>>>>>>> [000020d3][001036bb][00000743] 6843070000 push 00000743
>>>>>>>>>>> [000020d8][001036bb][00000743] e885e6ffff call 00000762
>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>> [000020dd][001036c3][00000000] 83c408 add esp,+08
>>>>>>>>>>> [000020e0][001036c3][00000000] eb04 jmp 000020e6
>>>>>>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
>>>>>>>>>>> [000020e8][001036c7][00000018] 5d pop ebp
>>>>>>>>>>> [000020e9][001036cb][00000000] c3 ret ;
>>>>>>>>>>> exit main
>>>>>>>>>>> Number of Instructions Executed(10070) == 150 Pages
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is easier to understand because a print statement was added.
>>>>>>>>>> You proved that it halts, but H0 reports non-halting.
>>>>>>>>>> So, it produces a false negative.
>>>>>>>>>> So, now it has been proved that H, H0, etc produce false
>>>>>>>>>> negatives, when used to determine halting behaviour, please,
>>>>>>>>>> stop to call them halt-deciders, or termination-deciders.
>>>>>>>>>> They might be "simulation deciders". When returning true, the
>>>>>>>>>> simulation was correct, when false, the full simulation was
>>>>>>>>>> not possible.
>>>>>>>>>
>>>>>>>>> I don't want to discuss your screwy example because I
>>>>>>>>> can't use screwy examples in my paper.
>>>>>>>>>
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>> H0(DDD);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _DDD()
>>>>>>>>> [000020a2] 55 push ebp ; housekeeping
>>>>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping
>>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping
>>>>>>>>> [000020b2] 5d pop ebp ; housekeeping
>>>>>>>>> [000020b3] c3 ret ; never gets here
>>>>>>>>> Size in bytes:(0018) [000020b3]
>>>>>>>>>
>>>>>>>>> Exactly which step of DDD emulated by H0 was emulated
>>>>>>>>> incorrectly such that this emulation would be complete?
>>>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why does H0 NEED to be able to correctly simulate its input?
>>>>>>>>
>>>>>>>
>>>>>>> Decider must compute the mapping from their finite string
>>>>>>> input to the actual behavior that this finite string specifies.
>>>>>>> They are not free to imagine the behavior that the authors of
>>>>>>> textbooks expect.
>>>>>>
>>>>>> AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
>>>>>> EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
>>>>>>
>>>>>> Yes, the DO need to follow the behavior that the author of the
>>>>>> problem defined.
>>>>>>
>>>>>> You are just showing you think it is ok to not follow the
>>>>>> REQURIEMENTS and just LIE about what you are doing.
>>>>>>
>>>>> The finite string input does not communicate the behavior
>>>>> that the textbook authors expect it to communicate.
>>>>>
>>>>
>>>> The finite string certainly DOES communicate what is needed to
>>>> determine the behavior, or it wasn't a correct representation.
>>>>
>>>
>>> There is no sequence of truth preserving operations from the finite
>>> string machine code of DDD that can correctly ignore the pathological
>>> relationship between H0 and DDD as an aspect of the behavior that
>>> this finite string specifies.
>>>
>>
>> Why does it need to "ignore" the relationship. We can in a finite
>> number of operations show that the machine code of DDD (but we need
>> ALL the machine code of DDD, including the functions it calls) show
>> that DDD represents a Halting Program if the decider does what you
>> claim, and returns 0 in a finite amount of time.
>>
>
> _DDD()
> [00002093] 55 push ebp
> [00002094] 8bec mov ebp,esp
> [00002096] 6893200000 push 00002093
> [0000209b] e853f4ffff call 000014f3
> [000020a0] 83c404 add esp,+04
> [000020a3] 5d pop ebp
> [000020a4] c3 ret
> Size in bytes:(0018) [000020a4]
>
> We can see that H0 halts and you seem insufficiently technically
> competent or outright dishonest when you imply
>
> that H0 cannot
> see that DDD correctly simulated by H0 cannot possibly get past
> its own [0000209b] machine address in a finite number of steps.
The fact that is can not see, doesn't make the halting of the input not
happen.
Remember, "H0" is the name for *THIS* *EXACT* *MACHINE* because there
can only be one C entity by the same name at global scope.
And DDD is *DEFINED* to be using *THIS* H0, since the x86 code for H0
must be part of the x86 code for DDD, or you can't simulate more than 4
instructions correctly.
Note, the question that H0 is SUPPOSED to be answering is does its input
halt, or equivalently if an actually correct (and complete) simulation
of this input will halt. Since H0 doesn't do that, its simulaton doesn't
count.
Also, H0 can't prove that its simulation of the input *CAN'T* reach a
final state, because of the fact that it *DOES* about at the point it
does, so either you admit that it is just a trival fact that a machine
that aborts its simulation has shown that it couldn't go farther (since
it didn't) which makes your concept just a trivial decider, or you have
to try to convince people that it is ok to look at the WRONG input,
which is of course, just invalid logic.
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H *correctly simulates its input D*
> *until H correctly determines that its simulated D would never*
> *stop running unless aborted* then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
>
Right, and that was with the DEFINITION that a "Correct Simulation" is a
simulation that actualy DOES correctly repoduce the behavior of the
input, something you claim youir doesn't' need to, and that definition
means tha ta correct simulation doesn't ever stop until it gets to the
end. Something your decider doesn't do, or even correctly predict the
results of (since we can show, and you admit) that the direct execution
of the input will halt (which is why you desperately are trying to prove
that a correct simulation can be different that the actual behavior,
which is just a contradiction of terms).
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-20 22:48 +0000 |
| Message-ID | <v52bjh$jdea$1@i2pn2.org> |
| In reply to | #107473 |
Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott: > On 6/19/2024 9:17 PM, Richard Damon wrote: >> On 6/19/24 10:02 PM, olcott wrote: >>> On 6/19/2024 8:39 PM, Richard Damon wrote: >>>> On 6/19/24 8:44 PM, olcott wrote: >>>>> On 6/19/2024 7:23 PM, Richard Damon wrote: >>>>>> On 6/19/24 9:00 AM, olcott wrote: >>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote: >>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott: >>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott: >>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote: >>>>>>>> It is easier to understand because a print statement was added. >>>>>>>> You proved that it halts, but H0 reports non-halting. >>>>>>>> So, it produces a false negative. >>>>>>>> So, now it has been proved that H, H0, etc produce false >>>>>>>> negatives, when used to determine halting behaviour, please, stop >>>>>>>> to call them halt-deciders, or termination-deciders. >>>>>>>> They might be "simulation deciders". When returning true, the >>>>>>>> simulation was correct, when false, the full simulation was not >>>>>>>> possible. >>>>>> Why does H0 NEED to be able to simulate its input? Yeah, why? That just adds a contradictory requirement. Not that it were possible otherwise. >>>>> Decider must compute the mapping from their finite string input to >>>>> the actual behavior that this finite string specifies. If possible. >>>>> They are not free to imagine the behavior that the authors of >>>>> textbooks expect. Nor crackpots. >>> The finite string input does not communicate the behavior that the >>> textbook authors expect it to communicate. Bullshit. Your neither-decider-nor-simulator just can't handle it. The direct execution of DDD is the measure of things. A simulation must behave identically. Of course you may be able to do analysis on whether it halts, but that's different. Simulation is dumb. >> The finite string certainly DOES communicate what is needed to >> determine the behavior, or it wasn't a correct representation. Deflection follows: > There is no sequence of truth preserving operations from the finite > string machine code of DDD that can correctly ignore the pathological > relationship between H0 and DDD as an aspect of the behavior that this > finite string specifies. Many other simulators or deciders work correctly with DDD, just not the one it calls. But they each get a different one wrong. What do you mean with "ignore the relationship"? > No one has noticed this before because no one ever thought to make every > single detail 100% concrete, thus leaving huge gaps in all prior > reasoning. We have a proof. -- Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 17:52 -0500 |
| Message-ID | <v52br1$2phm9$1@dont-email.me> |
| In reply to | #107507 |
On 6/20/2024 5:48 PM, joes wrote: > Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott: >> On 6/19/2024 9:17 PM, Richard Damon wrote: >>> On 6/19/24 10:02 PM, olcott wrote: >>>> On 6/19/2024 8:39 PM, Richard Damon wrote: >>>>> On 6/19/24 8:44 PM, olcott wrote: >>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote: >>>>>>> On 6/19/24 9:00 AM, olcott wrote: >>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote: >>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott: >>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott: >>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote: > >>>>>>>>> It is easier to understand because a print statement was added. >>>>>>>>> You proved that it halts, but H0 reports non-halting. >>>>>>>>> So, it produces a false negative. >>>>>>>>> So, now it has been proved that H, H0, etc produce false >>>>>>>>> negatives, when used to determine halting behaviour, please, stop >>>>>>>>> to call them halt-deciders, or termination-deciders. >>>>>>>>> They might be "simulation deciders". When returning true, the >>>>>>>>> simulation was correct, when false, the full simulation was not >>>>>>>>> possible. > >>>>>>> Why does H0 NEED to be able to simulate its input? > Yeah, why? That just adds a contradictory requirement. Not that it were > possible otherwise. > >>>>>> Decider must compute the mapping from their finite string input to >>>>>> the actual behavior that this finite string specifies. > If possible. >>>>>> They are not free to imagine the behavior that the authors of >>>>>> textbooks expect. > Nor crackpots. > >>>> The finite string input does not communicate the behavior that the >>>> textbook authors expect it to communicate. > Bullshit. Your neither-decider-nor-simulator just can't handle it. > The direct execution of DDD is the measure of things. A simulation > must behave identically. Of course you may be able to do analysis > on whether it halts, but that's different. Simulation is dumb. > >>> The finite string certainly DOES communicate what is needed to >>> determine the behavior, or it wasn't a correct representation. > Deflection follows: >> There is no sequence of truth preserving operations from the finite >> string machine code of DDD that can correctly ignore the pathological >> relationship between H0 and DDD as an aspect of the behavior that this >> finite string specifies. > Many other simulators or deciders work correctly with DDD, just not the > one it calls. But they each get a different one wrong. > What do you mean with "ignore the relationship"? > >> No one has noticed this before because no one ever thought to make every >> single detail 100% concrete, thus leaving huge gaps in all prior >> reasoning. > We have a proof. > You have dogmatic false assumptions. It is an verified fact that the input to H(D,D) cannot be mapped to the behavior of D(D). When I say "mapped" I don't mean look something up in Google maps. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-20 23:05 +0000 |
| Message-ID | <v52cj2$jdea$3@i2pn2.org> |
| In reply to | #107508 |
Am Thu, 20 Jun 2024 17:52:17 -0500 schrieb olcott: > On 6/20/2024 5:48 PM, joes wrote: >> Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott: >>> On 6/19/2024 9:17 PM, Richard Damon wrote: >>>> On 6/19/24 10:02 PM, olcott wrote: >>>>> On 6/19/2024 8:39 PM, Richard Damon wrote: >>>>>> On 6/19/24 8:44 PM, olcott wrote: >>>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote: >>>>>>>> On 6/19/24 9:00 AM, olcott wrote: >>>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote: >>>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott: >>>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >>>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott: >>>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote: >>>>>>>> Why does H0 NEED to be able to simulate its input? >> Yeah, why? That just adds a contradictory requirement. Not that it were >> possible otherwise. Why do you want to decide halting by incomplete simulation? >>>>>>> Decider must compute the mapping from their finite string input to >>>>>>> the actual behavior that this finite string specifies. >> If possible. Which it is not. >>>>>>> They are not free to imagine the behavior that the authors of >>>>>>> textbooks expect. >> Nor crackpots. >>>>> The finite string input does not communicate the behavior that the >>>>> textbook authors expect it to communicate. >> Bullshit. Your neither-decider-nor-simulator just can't handle it. >> The direct execution of DDD is the measure of things. A simulation must >> behave identically. Of course you may be able to do analysis on whether >> it halts, but that's different. Simulation is dumb. Your "simulator" is wrong. >>>> The finite string certainly DOES communicate what is needed to >>>> determine the behavior, or it wasn't a correct representation. >>> There is no sequence of truth preserving operations from the finite >>> string machine code of DDD that can correctly ignore the pathological >>> relationship between H0 and DDD as an aspect of the behavior that this >>> finite string specifies. >> What do you mean with "ignore the relationship"? Your H0 can not derive the behaviour of DDD, because it contradicts its own result. >> We have a proof. > You have dogmatic false assumptions. Go ahead, disprove Turing. > It is an verified fact that the input to H(D,D) cannot be mapped to the > behavior of D(D). Yes, H can not decide/simulate D(D). G can that exact D constructed on H, but not the E which calls G. > When I say "mapped" I don't mean look something up in Google maps. Cut the insults. -- Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-20 18:09 -0500 |
| Message-ID | <v52cr4$2po78$1@dont-email.me> |
| In reply to | #107510 |
On 6/20/2024 6:05 PM, joes wrote: > Am Thu, 20 Jun 2024 17:52:17 -0500 schrieb olcott: >> On 6/20/2024 5:48 PM, joes wrote: >>> Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott: >>>> On 6/19/2024 9:17 PM, Richard Damon wrote: >>>>> On 6/19/24 10:02 PM, olcott wrote: >>>>>> On 6/19/2024 8:39 PM, Richard Damon wrote: >>>>>>> On 6/19/24 8:44 PM, olcott wrote: >>>>>>>> On 6/19/2024 7:23 PM, Richard Damon wrote: >>>>>>>>> On 6/19/24 9:00 AM, olcott wrote: >>>>>>>>>> On 6/19/2024 3:08 AM, Fred. Zwarts wrote: >>>>>>>>>>> Op 18.jun.2024 om 18:26 schreef olcott: >>>>>>>>>>>> On 6/18/2024 10:47 AM, Fred. Zwarts wrote: >>>>>>>>>>>>> Op 18.jun.2024 om 17:33 schreef olcott: >>>>>>>>>>>>>> On 6/18/2024 10:20 AM, Fred. Zwarts wrote: > >>>>>>>>> Why does H0 NEED to be able to simulate its input? >>> Yeah, why? That just adds a contradictory requirement. Not that it were >>> possible otherwise. > Why do you want to decide halting by incomplete simulation? > >>>>>>>> Decider must compute the mapping from their finite string input to >>>>>>>> the actual behavior that this finite string specifies. >>> If possible. > Which it is not. > >>>>>>>> They are not free to imagine the behavior that the authors of >>>>>>>> textbooks expect. >>> Nor crackpots. > >>>>>> The finite string input does not communicate the behavior that the >>>>>> textbook authors expect it to communicate. >>> Bullshit. Your neither-decider-nor-simulator just can't handle it. >>> The direct execution of DDD is the measure of things. A simulation must >>> behave identically. Of course you may be able to do analysis on whether >>> it halts, but that's different. Simulation is dumb. > Your "simulator" is wrong. > >>>>> The finite string certainly DOES communicate what is needed to >>>>> determine the behavior, or it wasn't a correct representation. > >>>> There is no sequence of truth preserving operations from the finite >>>> string machine code of DDD that can correctly ignore the pathological >>>> relationship between H0 and DDD as an aspect of the behavior that this >>>> finite string specifies. >>> What do you mean with "ignore the relationship"? > Your H0 can not derive the behaviour of DDD, because it contradicts its > own result. > >>> We have a proof. >> You have dogmatic false assumptions. > Go ahead, disprove Turing. >> It is an verified fact that the input to H(D,D) cannot be mapped to the >> behavior of D(D). > Yes, H can not decide/simulate D(D). G can that exact D constructed > on H, but not the E which calls G. > H(D,D) cannot even see the question: Does D(D) halt? H(D,D) does see the question: Must I abort D so that I can terminate? >> When I say "mapped" I don't mean look something up in Google maps. > Cut the insults. > -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web