Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #106259 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-06-04 16:53 -0500 |
| Last post | 2024-06-05 20:39 +0200 |
| Articles | 20 on this page of 210 — 13 participants |
Back to article view | Back to comp.theory
At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-04 16:53 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-04 21:48 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-04 20:54 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-04 22:22 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-04 21:28 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-04 22:45 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-04 21:55 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-04 23:15 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-04 22:21 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-05 07:31 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 07:30 -0500
Re: At least 100 people kept denying the easily verified fact joes <noreply@example.com> - 2024-06-05 18:00 +0000
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-05 19:32 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 20:01 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-05 21:07 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 20:18 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-05 21:27 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 20:31 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-05 22:25 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 21:43 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-05 23:05 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 22:11 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-05 23:41 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 22:44 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-05 23:58 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 23:04 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-06 00:06 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 23:14 -0500
Re: At least 100 people kept denying the easily verified fact wij <wyniijj5@gmail.com> - 2024-06-06 12:32 +0800
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-06 07:11 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-06 08:06 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-06 21:56 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-06 22:04 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-06 23:29 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-06 22:53 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 11:14 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 10:22 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 11:32 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-06 23:29 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 08:09 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 11:14 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 10:29 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 11:46 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 10:56 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 12:25 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 11:46 -0500
Re: Last communication with Richard Rich Yard Daemon <news3@immibis.com> - 2024-06-07 18:51 +0200
Re: Last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 13:12 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 13:11 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 12:14 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 14:22 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 13:38 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 15:23 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 13:53 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 15:23 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-07 17:57 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 11:13 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 12:27 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 10:52 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard immibis <news@immibis.com> - 2024-06-07 18:00 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 12:28 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Alan Mackenzie <acm@muc.de> - 2024-06-07 17:50 +0000
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 13:02 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 14:24 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 13:41 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard wij <wyniijj5@gmail.com> - 2024-06-08 02:57 +0800
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard immibis <news@immibis.com> - 2024-06-07 21:22 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard joes <noreply@example.com> - 2024-06-07 20:45 +0000
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 17:22 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Mikko <mikko.levanto@iki.fi> - 2024-06-08 10:01 +0300
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 08:07 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 09:40 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 08:52 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 10:34 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Mikko <mikko.levanto@iki.fi> - 2024-06-09 10:34 +0300
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-09 07:51 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Mikko <mikko.levanto@iki.fi> - 2024-06-09 18:32 +0300
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-09 11:18 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Mikko <mikko.levanto@iki.fi> - 2024-06-10 10:00 +0300
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-10 10:06 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Mikko <mikko.levanto@iki.fi> - 2024-06-11 10:18 +0300
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-11 22:22 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 14:31 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard wij <wyniijj5@gmail.com> - 2024-06-08 03:43 +0800
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 15:01 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard wij <wyniijj5@gmail.com> - 2024-06-08 12:18 +0800
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 07:20 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-08 14:41 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 08:16 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-08 15:38 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 08:50 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-08 16:01 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 09:06 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-08 16:19 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 09:25 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-08 16:36 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 09:59 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 11:09 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 10:44 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 10:40 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 10:39 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 09:47 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 09:05 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 10:46 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 09:03 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 08:36 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 09:50 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 15:50 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Alan Mackenzie <acm@muc.de> - 2024-06-07 19:57 +0000
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 15:04 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Alan Mackenzie <acm@muc.de> - 2024-06-07 20:16 +0000
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 17:03 -0500
Re: olcott is a moron immibis <news@immibis.com> - 2024-06-08 00:14 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 19:00 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard (we wish) Richard Damon <richard@damon-family.org> - 2024-06-07 16:17 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard (we wish) olcott <polcott333@gmail.com> - 2024-06-07 17:11 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard (we wish) Richard Damon <richard@damon-family.org> - 2024-06-07 18:18 -0400
Re: At least 100 people kept denying the easily verified fact -- closure joes <noreply@example.com> - 2024-06-07 22:22 +0000
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 17:35 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 19:00 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 18:07 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 19:18 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 18:38 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 20:43 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 19:47 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 20:58 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 20:22 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 21:39 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 20:45 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 22:06 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 21:21 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 22:37 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 21:47 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 22:56 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 22:23 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-08 09:03 -0400
Re: At least 100 people kept denying the easily verified fact -- closure joes <noreply@example.com> - 2024-06-07 23:21 +0000
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 18:51 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 19:57 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 19:23 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 20:45 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 19:50 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 21:01 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 19:32 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 20:47 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 19:52 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 21:08 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 20:26 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 21:42 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 20:48 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 22:11 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 21:35 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 22:46 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-07 21:54 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-07 23:11 -0400
Re: At least 100 people kept denying the easily verified fact -- closure Mikko <mikko.levanto@iki.fi> - 2024-06-08 10:31 +0300
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-08 09:03 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-08 08:39 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-08 09:56 -0400
Re: At least 100 people kept denying the easily verified fact -- closure olcott <polcott333@gmail.com> - 2024-06-08 08:12 -0500
Re: At least 100 people kept denying the easily verified fact -- closure Richard Damon <richard@damon-family.org> - 2024-06-08 09:57 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard joes <noreply@example.com> - 2024-06-07 20:56 +0000
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 17:24 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 19:00 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 18:09 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 19:20 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 18:48 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 20:31 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 18:31 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 20:35 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 15:28 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 14:36 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 16:01 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Python <python@invalid.org> - 2024-06-07 23:06 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-07 17:25 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-07 17:12 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Python <python@invalid.org> - 2024-06-08 00:15 +0200
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Mikko <mikko.levanto@iki.fi> - 2024-06-08 09:58 +0300
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-08 08:06 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-08 10:01 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Mikko <mikko.levanto@iki.fi> - 2024-06-09 12:33 +0300
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-09 09:04 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Andy Walker <anw@cuboid.co.uk> - 2024-06-09 15:16 +0100
Simplified proof that DDD correctly simulated by HHH does not halt olcott <polcott333@gmail.com> - 2024-06-09 09:21 -0500
Re: Simplified proof that DDD correctly simulated by HHH does not halt Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard joes <noreply@example.com> - 2024-06-09 15:11 +0000
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-09 11:11 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-09 14:08 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-09 19:17 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-09 20:36 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-09 19:50 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-09 21:07 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard olcott <polcott333@gmail.com> - 2024-06-09 20:22 -0500
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard Richard Damon <richard@damon-family.org> - 2024-06-09 21:41 -0400
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard joes <noreply@example.com> - 2024-06-07 20:52 +0000
Re: At least 100 people kept denying the easily verified fact --- last communication with Richard immibis <news@immibis.com> - 2024-06-07 18:01 +0200
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-06 00:57 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-06 07:11 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-06 08:08 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-06 08:27 -0500
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: At least 100 people kept denying the easily verified fact ornott <news2@immibis.com> - 2024-06-06 18:48 +0200
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-06 11:56 -0500
Re: At least 100 people kept denying the easily verified fact prescott <news2@immibis.com> - 2024-06-06 20:03 +0200
Re: At least 100 people kept denying the easily verified fact Richard Damon <richard@damon-family.org> - 2024-06-06 22:08 -0400
Re: At least 100 people kept denying the easily verified fact "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-05 10:02 +0200
Re: At least 100 people kept denying the easily verified fact olcott <polcott333@gmail.com> - 2024-06-05 08:54 -0500
Re: At least 100 people kept denying the easily verified fact "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-05 20:39 +0200
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-10 10:06 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v474p3$ggn5$7@dont-email.me> |
| In reply to | #106866 |
On 6/10/2024 2:00 AM, Mikko wrote: > On 2024-06-09 16:18:58 +0000, olcott said: > >> On 6/9/2024 10:32 AM, Mikko wrote: >>> On 2024-06-09 12:51:40 +0000, olcott said: >>> >>>> On 6/9/2024 2:34 AM, Mikko wrote: >>>>> On 2024-06-08 13:07:11 +0000, olcott said: >>>>> >>>>>> On 6/8/2024 2:01 AM, Mikko wrote: >>>>>>> On 2024-06-07 22:22:19 +0000, olcott said: >>>>>>> >>>>>>>> On 6/7/2024 3:45 PM, joes wrote: >>>>>>>>> Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis: >>>>>>>>>> He only ignores people now. Except Richard for some reason. >>>>>>>>> The reason being that Richard responds at the same level >>>>>>>>> >>>>>>>> >>>>>>>> You respond with persistent false assumptions that cannot be >>>>>>>> corrected by feedback. >>>>>>> >>>>>>> You cannot correct other people's false assumtion but >>>>>>> you can always present your own for comparison. >>>>>>> >>>>>> >>>>>> I can correct other people false assumptions iff (if and only if) >>>>>> they are as interested in an honest dialogue as I am. >>>>> >>>>> Not even then. If one does not correct one's assumption oneself they >>>>> remain uncorrected. >>>> >>>> So one majickly cures one's own ignorance? >>> >>> Rarely that way. >>> >>>> If one assumes 5 > 6 then one is wrong. >>> >>> Your disagreement does not prevent one from keeping that assumption. >>> >> >> The verified facts prevent anyone from correctly >> maintaining false assumptions. > > No, they don't, if one assumes that the verification was incorrect. *Then they are being dishonest* > Besides, you didn't say they maintain their false assumtions "correctly". > -- 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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-11 10:18 +0300 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v48to3$uhg8$1@dont-email.me> |
| In reply to | #106892 |
On 2024-06-10 15:06:11 +0000, olcott said: > On 6/10/2024 2:00 AM, Mikko wrote: >> On 2024-06-09 16:18:58 +0000, olcott said: >> >>> On 6/9/2024 10:32 AM, Mikko wrote: >>>> On 2024-06-09 12:51:40 +0000, olcott said: >>>> >>>>> On 6/9/2024 2:34 AM, Mikko wrote: >>>>>> On 2024-06-08 13:07:11 +0000, olcott said: >>>>>> >>>>>>> On 6/8/2024 2:01 AM, Mikko wrote: >>>>>>>> On 2024-06-07 22:22:19 +0000, olcott said: >>>>>>>> >>>>>>>>> On 6/7/2024 3:45 PM, joes wrote: >>>>>>>>>> Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis: >>>>>>>>>>> He only ignores people now. Except Richard for some reason. >>>>>>>>>> The reason being that Richard responds at the same level >>>>>>>>>> >>>>>>>>> >>>>>>>>> You respond with persistent false assumptions that cannot be >>>>>>>>> corrected by feedback. >>>>>>>> >>>>>>>> You cannot correct other people's false assumtion but >>>>>>>> you can always present your own for comparison. >>>>>>>> >>>>>>> >>>>>>> I can correct other people false assumptions iff (if and only if) >>>>>>> they are as interested in an honest dialogue as I am. >>>>>> >>>>>> Not even then. If one does not correct one's assumption oneself they >>>>>> remain uncorrected. >>>>> >>>>> So one majickly cures one's own ignorance? >>>> >>>> Rarely that way. >>>> >>>>> If one assumes 5 > 6 then one is wrong. >>>> >>>> Your disagreement does not prevent one from keeping that assumption. >>>> >>> >>> The verified facts prevent anyone from correctly >>> maintaining false assumptions. >> >> No, they don't, if one assumes that the verification was incorrect. > > *Then they are being dishonest* Not necessaritly. Anysay, people usually are half-honest. Some are really dishonest, some are really honest, but must are somewnere between. But that doesn't really matter because >> Besides, you didn't say they maintain their false assumtions "correctly". and still don't. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-11 22:22 -0400 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v4b0oc$3nf9m$7@i2pn2.org> |
| In reply to | #106892 |
On 6/10/24 11:06 AM, olcott wrote: > On 6/10/2024 2:00 AM, Mikko wrote: >> On 2024-06-09 16:18:58 +0000, olcott said: >> >>> On 6/9/2024 10:32 AM, Mikko wrote: >>>> On 2024-06-09 12:51:40 +0000, olcott said: >>>> >>>>> On 6/9/2024 2:34 AM, Mikko wrote: >>>>>> On 2024-06-08 13:07:11 +0000, olcott said: >>>>>> >>>>>>> On 6/8/2024 2:01 AM, Mikko wrote: >>>>>>>> On 2024-06-07 22:22:19 +0000, olcott said: >>>>>>>> >>>>>>>>> On 6/7/2024 3:45 PM, joes wrote: >>>>>>>>>> Am Fri, 07 Jun 2024 21:22:12 +0200 schrieb immibis: >>>>>>>>>>> He only ignores people now. Except Richard for some reason. >>>>>>>>>> The reason being that Richard responds at the same level >>>>>>>>>> >>>>>>>>> >>>>>>>>> You respond with persistent false assumptions that cannot be >>>>>>>>> corrected by feedback. >>>>>>>> >>>>>>>> You cannot correct other people's false assumtion but >>>>>>>> you can always present your own for comparison. >>>>>>>> >>>>>>> >>>>>>> I can correct other people false assumptions iff (if and only if) >>>>>>> they are as interested in an honest dialogue as I am. >>>>>> >>>>>> Not even then. If one does not correct one's assumption oneself they >>>>>> remain uncorrected. >>>>> >>>>> So one majickly cures one's own ignorance? >>>> >>>> Rarely that way. >>>> >>>>> If one assumes 5 > 6 then one is wrong. >>>> >>>> Your disagreement does not prevent one from keeping that assumption. >>>> >>> >>> The verified facts prevent anyone from correctly >>> maintaining false assumptions. >> >> No, they don't, if one assumes that the verification was incorrect. > > *Then they are being dishonest* No, they are looking at the evidence. You have admitted to not actually looking at yoru evidence, and that it ended up not being what you claimed, and that you never could have had the traces you said you looked at. That makes your claims of "verification" unreliable, and thus not really verification. > >> Besides, you didn't say they maintain their false assumtions "correctly". >> >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-07 14:31 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v3vn5u$26d04$1@dont-email.me> |
| In reply to | #106532 |
On 6/7/2024 1:57 PM, wij wrote:
> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>> On 6/7/24 2:02 PM, olcott wrote:
>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>> [ Followup-To: set ]
>>>>>
>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>
>>>>> [ .... ]
>>>>>
>>>>>> _DD()
>>>>>> [00001e12] 55 push ebp
>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>> [00001e15] 51 push ecx
>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>> [00001e19] 50 push eax ; push DD
>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>
>>>>>> A {correct simulation} means that each instruction of the
>>>>>> above x86 machine language of DD is correctly simulated
>>>>>> by HH and simulated in the correct order.
>>>>>
>>>>> That's a bit of sudden and substantial change, isn't it? Less than a
>>>>> few
>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>> instructions"
>>>>> simulated (without ever specifying what you meant by N). It seems that
>>>>> the simulation of exactly one instruction would have met your criterion.
>>>>>
>>>>> That now seems to have changed.
>>>>>
>>>>
>>>> Because I am a relatively terrible writer I must constantly
>>>> improve my words on the basis of reviews.
>>>>
>>>> Try to show how this DD correctly simulated by any HH ever
>>>> stops running without having its simulation aborted by HH.
>>>>
>>>> _DD()
>>>> [00001e12] 55 push ebp
>>>> [00001e13] 8bec mov ebp,esp
>>>> [00001e15] 51 push ecx
>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>> [00001e19] 50 push eax ; push DD
>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>> [00001e1d] 51 push ecx ; push DD
>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>
>>>> A {correct simulation} means that each instruction of the
>>>> above x86 machine language of DD is correctly simulated
>>>> by HH and simulated in the correct order.
>>>>
>>>> Anyone claiming that HH should report on the behavior
>>>> of the directly executed DD(DD) is requiring a violation
>>>> of the above definition of correct simulation.
>>>>
>>>
>>> And thus you admit that HH is not a Halt Decider,
>>
>> More dishonest deflection.
>> The point that I made and you try to deflect using the strawman
>> deception as a fake rebuttal is the I just proved that DD is correctly
>> simulated by HH and this is not the same behavior as the directly
>> executed DD(DD).
>>
>
> The Halting Problem asks for a program H (precisely a TM) that:
> IF H(D,D)==1, THEN D(D) will return.
> ELSE If H(D,D)==0, THEN D(D) will never return.
> ELSE HP is undecidable
>
> You keep solving POOH !!! and made lots of lies.
>
> Surrender to my GUR, son.
>
If people are going to be dishonest about simple things
such as the actual behavior of actual x86 code where
they consistently deny verified facts
then we certainly cannot trust these people with more
difficult issues that require at least some slight degree
of judgment call.
When we can show that even in the halting problem HH
is only required to report on the behavior of DD correctly
simulated by HH these dishonest people merely use that
as another deflection point for their dishonesty.
The way around this that just worked is to stay diligently
focused one one single point until the dishonest people
finally admit that they have simply ignored all the proofs
for three solid years.
On 6/5/2024 10:58 PM, Richard Damon wrote:
> On 6/5/24 11:44 PM, olcott wrote:
>>
>> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>
> But, as I said, I won't acknowledge that you
> are correct, because I am not willing to put
> that effort into your worthless claim.
>
Here is the earliest version of the proof (that everyone
has simply ignored for three solid years) that P correctly
simulated by H would never stop running unless aborted.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
The fact that the execution trace of P derived by the executed
H and the simulated H exactly matches the machine code of P
proves that each instruction of P was simulated correctly and
in the correct order this conclusively proves that P is correctly
simulated by both of these instances of H.
It has proved this since 2021-09-26 and everyone has made
sure to ignore this proof so that they can maintain their false
assumption.
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.
_DD()
[00001e12] 55 push ebp
[00001e13] 8bec mov ebp,esp
[00001e15] 51 push ecx
[00001e16] 8b4508 mov eax,[ebp+08]
[00001e19] 50 push eax ; push DD
[00001e1a] 8b4d08 mov ecx,[ebp+08]
[00001e1d] 51 push ecx ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-06-08 03:43 +0800 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <400b355fb6d07340772b9308dece34b60fd6fcb4.camel@gmail.com> |
| In reply to | #106537 |
On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
> On 6/7/2024 1:57 PM, wij wrote:
> > On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
> > > On 6/7/2024 1:24 PM, Richard Damon wrote:
> > > > On 6/7/24 2:02 PM, olcott wrote:
> > > > > On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
> > > > > > [ Followup-To: set ]
> > > > > >
> > > > > > In comp.theory olcott <polcott333@gmail.com> wrote:
> > > > > >
> > > > > > [ .... ]
> > > > > >
> > > > > > > _DD()
> > > > > > > [00001e12] 55 push ebp
> > > > > > > [00001e13] 8bec mov ebp,esp
> > > > > > > [00001e15] 51 push ecx
> > > > > > > [00001e16] 8b4508 mov eax,[ebp+08]
> > > > > > > [00001e19] 50 push eax ; push DD
> > > > > > > [00001e1a] 8b4d08 mov ecx,[ebp+08]
> > > > > > > [00001e1d] 51 push ecx ; push DD
> > > > > > > [00001e1e] e85ff5ffff call 00001382 ; call HH
> > > > > >
> > > > > > > A {correct simulation} means that each instruction of the
> > > > > > > above x86 machine language of DD is correctly simulated
> > > > > > > by HH and simulated in the correct order.
> > > > > >
> > > > > > That's a bit of sudden and substantial change, isn't it? Less than a
> > > > > > few
> > > > > > days ago, you were defining a correct simulation as "1 to N
> > > > > > instructions"
> > > > > > simulated (without ever specifying what you meant by N). It seems that
> > > > > > the simulation of exactly one instruction would have met your criterion.
> > > > > >
> > > > > > That now seems to have changed.
> > > > > >
> > > > >
> > > > > Because I am a relatively terrible writer I must constantly
> > > > > improve my words on the basis of reviews.
> > > > >
> > > > > Try to show how this DD correctly simulated by any HH ever
> > > > > stops running without having its simulation aborted by HH.
> > > > >
> > > > > _DD()
> > > > > [00001e12] 55 push ebp
> > > > > [00001e13] 8bec mov ebp,esp
> > > > > [00001e15] 51 push ecx
> > > > > [00001e16] 8b4508 mov eax,[ebp+08]
> > > > > [00001e19] 50 push eax ; push DD
> > > > > [00001e1a] 8b4d08 mov ecx,[ebp+08]
> > > > > [00001e1d] 51 push ecx ; push DD
> > > > > [00001e1e] e85ff5ffff call 00001382 ; call HH
> > > > >
> > > > > A {correct simulation} means that each instruction of the
> > > > > above x86 machine language of DD is correctly simulated
> > > > > by HH and simulated in the correct order.
> > > > >
> > > > > Anyone claiming that HH should report on the behavior
> > > > > of the directly executed DD(DD) is requiring a violation
> > > > > of the above definition of correct simulation.
> > > > >
> > > >
> > > > And thus you admit that HH is not a Halt Decider,
> > >
> > > More dishonest deflection.
> > > The point that I made and you try to deflect using the strawman
> > > deception as a fake rebuttal is the I just proved that DD is correctly
> > > simulated by HH and this is not the same behavior as the directly
> > > executed DD(DD).
> > >
> >
> > The Halting Problem asks for a program H (precisely a TM) that:
> > IF H(D,D)==1, THEN D(D) will return.
> > ELSE If H(D,D)==0, THEN D(D) will never return.
> > ELSE HP is undecidable
> >
> > You keep solving POOH !!! and made lots of lies.
> >
> > Surrender to my GUR, son.
> >
>
> If people are going to be dishonest about simple things
> such as the actual behavior of actual x86 code where
> they consistently deny verified facts
>
> then we certainly cannot trust these people with more
> difficult issues that require at least some slight degree
> of judgment call.
>
> When we can show that even in the halting problem HH
> is only required to report on the behavior of DD correctly
> simulated by HH these dishonest people merely use that
> as another deflection point for their dishonesty.
>
> The way around this that just worked is to stay diligently
> focused one one single point until the dishonest people
> finally admit that they have simply ignored all the proofs
> for three solid years.
>
> On 6/5/2024 10:58 PM, Richard Damon wrote:
> > On 6/5/24 11:44 PM, olcott wrote:
> >>
> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
> >
> > But, as I said, I won't acknowledge that you
> > are correct, because I am not willing to put
> > that effort into your worthless claim.
> >
>
> Here is the earliest version of the proof (that everyone
> has simply ignored for three solid years) that P correctly
> simulated by H would never stop running unless aborted.
>
> Halting problem undecidability and infinitely nested simulation
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>
> The fact that the execution trace of P derived by the executed
> H and the simulated H exactly matches the machine code of P
> proves that each instruction of P was simulated correctly and
> in the correct order this conclusively proves that P is correctly
> simulated by both of these instances of H.
>
> It has proved this since 2021-09-26 and everyone has made
> sure to ignore this proof so that they can maintain their false
> assumption.
>
>
>
> Try to show how this DD correctly simulated by any HH ever
> stops running without having its simulation aborted by HH.
>
> _DD()
> [00001e12] 55 push ebp
> [00001e13] 8bec mov ebp,esp
> [00001e15] 51 push ecx
> [00001e16] 8b4508 mov eax,[ebp+08]
> [00001e19] 50 push eax ; push DD
> [00001e1a] 8b4d08 mov ecx,[ebp+08]
> [00001e1d] 51 push ecx ; push DD
> [00001e1e] e85ff5ffff call 00001382 ; call HH
>
> A {correct simulation} means that each instruction of the
> above x86 machine language of DD is correctly simulated
> by HH and simulated in the correct order.
>
> Anyone claiming that HH should report on the behavior
> of the directly executed DD(DD) is requiring a violation
> of the above definition of correct simulation.
>
I recalled now. You knew what the Halting Problem is. But soon, you started to insist
POOH is correct by fabricating ...(lots of things)...
Wake up, your trick won't work.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-07 15:01 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v3vovc$27d15$1@dont-email.me> |
| In reply to | #106539 |
On 6/7/2024 2:43 PM, wij wrote:
> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>> On 6/7/2024 1:57 PM, wij wrote:
>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>> [ Followup-To: set ]
>>>>>>>
>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>
>>>>>>> [ .... ]
>>>>>>>
>>>>>>>> _DD()
>>>>>>>> [00001e12] 55 push ebp
>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>> [00001e15] 51 push ecx
>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>
>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>> by HH and simulated in the correct order.
>>>>>>>
>>>>>>> That's a bit of sudden and substantial change, isn't it? Less than a
>>>>>>> few
>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>> instructions"
>>>>>>> simulated (without ever specifying what you meant by N). It seems that
>>>>>>> the simulation of exactly one instruction would have met your criterion.
>>>>>>>
>>>>>>> That now seems to have changed.
>>>>>>>
>>>>>>
>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>> improve my words on the basis of reviews.
>>>>>>
>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>> stops running without having its simulation aborted by HH.
>>>>>>
>>>>>> _DD()
>>>>>> [00001e12] 55 push ebp
>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>> [00001e15] 51 push ecx
>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>> [00001e19] 50 push eax ; push DD
>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>
>>>>>> A {correct simulation} means that each instruction of the
>>>>>> above x86 machine language of DD is correctly simulated
>>>>>> by HH and simulated in the correct order.
>>>>>>
>>>>>> Anyone claiming that HH should report on the behavior
>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>> of the above definition of correct simulation.
>>>>>>
>>>>>
>>>>> And thus you admit that HH is not a Halt Decider,
>>>>
>>>> More dishonest deflection.
>>>> The point that I made and you try to deflect using the strawman
>>>> deception as a fake rebuttal is the I just proved that DD is correctly
>>>> simulated by HH and this is not the same behavior as the directly
>>>> executed DD(DD).
>>>>
>>>
>>> The Halting Problem asks for a program H (precisely a TM) that:
>>> IF H(D,D)==1, THEN D(D) will return.
>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>> ELSE HP is undecidable
>>>
>>> You keep solving POOH !!! and made lots of lies.
>>>
>>> Surrender to my GUR, son.
>>>
>>
>> If people are going to be dishonest about simple things
>> such as the actual behavior of actual x86 code where
>> they consistently deny verified facts
>>
>> then we certainly cannot trust these people with more
>> difficult issues that require at least some slight degree
>> of judgment call.
>>
>> When we can show that even in the halting problem HH
>> is only required to report on the behavior of DD correctly
>> simulated by HH these dishonest people merely use that
>> as another deflection point for their dishonesty.
>>
>> The way around this that just worked is to stay diligently
>> focused one one single point until the dishonest people
>> finally admit that they have simply ignored all the proofs
>> for three solid years.
>>
>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>> > On 6/5/24 11:44 PM, olcott wrote:
>> >>
>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>> >
>> > But, as I said, I won't acknowledge that you
>> > are correct, because I am not willing to put
>> > that effort into your worthless claim.
>> >
>>
>> Here is the earliest version of the proof (that everyone
>> has simply ignored for three solid years) that P correctly
>> simulated by H would never stop running unless aborted.
>>
>> Halting problem undecidability and infinitely nested simulation
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>>
>> The fact that the execution trace of P derived by the executed
>> H and the simulated H exactly matches the machine code of P
>> proves that each instruction of P was simulated correctly and
>> in the correct order this conclusively proves that P is correctly
>> simulated by both of these instances of H.
>>
>> It has proved this since 2021-09-26 and everyone has made
>> sure to ignore this proof so that they can maintain their false
>> assumption.
>>
>>
>>
>> Try to show how this DD correctly simulated by any HH ever
>> stops running without having its simulation aborted by HH.
>>
>> _DD()
>> [00001e12] 55 push ebp
>> [00001e13] 8bec mov ebp,esp
>> [00001e15] 51 push ecx
>> [00001e16] 8b4508 mov eax,[ebp+08]
>> [00001e19] 50 push eax ; push DD
>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>> [00001e1d] 51 push ecx ; push DD
>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>
>> A {correct simulation} means that each instruction of the
>> above x86 machine language of DD is correctly simulated
>> by HH and simulated in the correct order.
>>
>> Anyone claiming that HH should report on the behavior
>> of the directly executed DD(DD) is requiring a violation
>> of the above definition of correct simulation.
>>
>
> I recalled now. You knew what the Halting Problem is. But soon, you started to insist
> POOH is correct by fabricating ...(lots of things)...
> Wake up, your trick won't work.
>
All the while that you insist on lying about
the verified fact that DD correctly simulated by
HH cannot possibly stop running without having its
simulation aborted by HH.
You won't get to talk to me about anything else such
as why the above statement matters.
If you want to choose to be a liar thus <is> the
consequence that you get.
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-06-08 12:18 +0800 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <385fc1f1467edc63a676d881f08f0bff52d5366c.camel@gmail.com> |
| In reply to | #106543 |
On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
> On 6/7/2024 2:43 PM, wij wrote:
> > On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
> > > On 6/7/2024 1:57 PM, wij wrote:
> > > > On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
> > > > > On 6/7/2024 1:24 PM, Richard Damon wrote:
> > > > > > On 6/7/24 2:02 PM, olcott wrote:
> > > > > > > On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
> > > > > > > > [ Followup-To: set ]
> > > > > > > >
> > > > > > > > In comp.theory olcott <polcott333@gmail.com> wrote:
> > > > > > > >
> > > > > > > > [ .... ]
> > > > > > > >
> > > > > > > > > _DD()
> > > > > > > > > [00001e12] 55 push ebp
> > > > > > > > > [00001e13] 8bec mov ebp,esp
> > > > > > > > > [00001e15] 51 push ecx
> > > > > > > > > [00001e16] 8b4508 mov eax,[ebp+08]
> > > > > > > > > [00001e19] 50 push eax ; push DD
> > > > > > > > > [00001e1a] 8b4d08 mov ecx,[ebp+08]
> > > > > > > > > [00001e1d] 51 push ecx ; push DD
> > > > > > > > > [00001e1e] e85ff5ffff call 00001382 ; call HH
> > > > > > > >
> > > > > > > > > A {correct simulation} means that each instruction of the
> > > > > > > > > above x86 machine language of DD is correctly simulated
> > > > > > > > > by HH and simulated in the correct order.
> > > > > > > >
> > > > > > > > That's a bit of sudden and substantial change, isn't it? Less than a
> > > > > > > > few
> > > > > > > > days ago, you were defining a correct simulation as "1 to N
> > > > > > > > instructions"
> > > > > > > > simulated (without ever specifying what you meant by N). It seems that
> > > > > > > > the simulation of exactly one instruction would have met your criterion.
> > > > > > > >
> > > > > > > > That now seems to have changed.
> > > > > > > >
> > > > > > >
> > > > > > > Because I am a relatively terrible writer I must constantly
> > > > > > > improve my words on the basis of reviews.
> > > > > > >
> > > > > > > Try to show how this DD correctly simulated by any HH ever
> > > > > > > stops running without having its simulation aborted by HH.
> > > > > > >
> > > > > > > _DD()
> > > > > > > [00001e12] 55 push ebp
> > > > > > > [00001e13] 8bec mov ebp,esp
> > > > > > > [00001e15] 51 push ecx
> > > > > > > [00001e16] 8b4508 mov eax,[ebp+08]
> > > > > > > [00001e19] 50 push eax ; push DD
> > > > > > > [00001e1a] 8b4d08 mov ecx,[ebp+08]
> > > > > > > [00001e1d] 51 push ecx ; push DD
> > > > > > > [00001e1e] e85ff5ffff call 00001382 ; call HH
> > > > > > >
> > > > > > > A {correct simulation} means that each instruction of the
> > > > > > > above x86 machine language of DD is correctly simulated
> > > > > > > by HH and simulated in the correct order.
> > > > > > >
> > > > > > > Anyone claiming that HH should report on the behavior
> > > > > > > of the directly executed DD(DD) is requiring a violation
> > > > > > > of the above definition of correct simulation.
> > > > > > >
> > > > > >
> > > > > > And thus you admit that HH is not a Halt Decider,
> > > > >
> > > > > More dishonest deflection.
> > > > > The point that I made and you try to deflect using the strawman
> > > > > deception as a fake rebuttal is the I just proved that DD is correctly
> > > > > simulated by HH and this is not the same behavior as the directly
> > > > > executed DD(DD).
> > > > >
> > > >
> > > > The Halting Problem asks for a program H (precisely a TM) that:
> > > > IF H(D,D)==1, THEN D(D) will return.
> > > > ELSE If H(D,D)==0, THEN D(D) will never return.
> > > > ELSE HP is undecidable
> > > >
> > > > You keep solving POOH !!! and made lots of lies.
> > > >
> > > > Surrender to my GUR, son.
> > > >
> > >
> > > If people are going to be dishonest about simple things
> > > such as the actual behavior of actual x86 code where
> > > they consistently deny verified facts
> > >
> > > then we certainly cannot trust these people with more
> > > difficult issues that require at least some slight degree
> > > of judgment call.
> > >
> > > When we can show that even in the halting problem HH
> > > is only required to report on the behavior of DD correctly
> > > simulated by HH these dishonest people merely use that
> > > as another deflection point for their dishonesty.
> > >
> > > The way around this that just worked is to stay diligently
> > > focused one one single point until the dishonest people
> > > finally admit that they have simply ignored all the proofs
> > > for three solid years.
> > >
> > > On 6/5/2024 10:58 PM, Richard Damon wrote:
> > > > On 6/5/24 11:44 PM, olcott wrote:
> > > >>
> > > >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
> > > >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
> > > >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
> > > >
> > > > But, as I said, I won't acknowledge that you
> > > > are correct, because I am not willing to put
> > > > that effort into your worthless claim.
> > > >
> > >
> > > Here is the earliest version of the proof (that everyone
> > > has simply ignored for three solid years) that P correctly
> > > simulated by H would never stop running unless aborted.
> > >
> > > Halting problem undecidability and infinitely nested simulation
> > > https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> > >
> > >
> > >
> > > The fact that the execution trace of P derived by the executed
> > > H and the simulated H exactly matches the machine code of P
> > > proves that each instruction of P was simulated correctly and
> > > in the correct order this conclusively proves that P is correctly
> > > simulated by both of these instances of H.
> > >
> > > It has proved this since 2021-09-26 and everyone has made
> > > sure to ignore this proof so that they can maintain their false
> > > assumption.
> > >
> > >
> > >
> > > Try to show how this DD correctly simulated by any HH ever
> > > stops running without having its simulation aborted by HH.
> > >
> > > _DD()
> > > [00001e12] 55 push ebp
> > > [00001e13] 8bec mov ebp,esp
> > > [00001e15] 51 push ecx
> > > [00001e16] 8b4508 mov eax,[ebp+08]
> > > [00001e19] 50 push eax ; push DD
> > > [00001e1a] 8b4d08 mov ecx,[ebp+08]
> > > [00001e1d] 51 push ecx ; push DD
> > > [00001e1e] e85ff5ffff call 00001382 ; call HH
> > >
> > > A {correct simulation} means that each instruction of the
> > > above x86 machine language of DD is correctly simulated
> > > by HH and simulated in the correct order.
> > >
> > > Anyone claiming that HH should report on the behavior
> > > of the directly executed DD(DD) is requiring a violation
> > > of the above definition of correct simulation.
> > >
> >
> > I recalled now. You knew what the Halting Problem is. But soon, you started to insist
> > POOH is correct by fabricating ...(lots of things)...
> > Wake up, your trick won't work.
> >
>
> All the while that you insist on lying about
>
> the verified fact that DD correctly simulated by
> HH cannot possibly stop running without having its
> simulation aborted by HH.
>
> You won't get to talk to me about anything else such
> as why the above statement matters.
>
> If you want to choose to be a liar thus <is> the
> consequence that you get.
>
The Halting Problem asks for a program H (precisely a TM) that:
IF H(D,D)==1, THEN D(D) will return.
ELSE If H(D,D)==0, THEN D(D) will never return.
ELSE HP is undecidable
What is your answer? (the last time I saw POOH, it does not report anything)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 07:20 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41i9j$2jqdk$1@dont-email.me> |
| In reply to | #106627 |
On 6/7/2024 11:18 PM, wij wrote:
> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>> On 6/7/2024 2:43 PM, wij wrote:
>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>
>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> [ .... ]
>>>>>>>>>
>>>>>>>>>> _DD()
>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>
>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>
>>>>>>>>> That's a bit of sudden and substantial change, isn't it? Less than a
>>>>>>>>> few
>>>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>>>> instructions"
>>>>>>>>> simulated (without ever specifying what you meant by N). It seems that
>>>>>>>>> the simulation of exactly one instruction would have met your criterion.
>>>>>>>>>
>>>>>>>>> That now seems to have changed.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>
>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>
>>>>>>>> _DD()
>>>>>>>> [00001e12] 55 push ebp
>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>> [00001e15] 51 push ecx
>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>
>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>
>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>> of the above definition of correct simulation.
>>>>>>>>
>>>>>>>
>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>
>>>>>> More dishonest deflection.
>>>>>> The point that I made and you try to deflect using the strawman
>>>>>> deception as a fake rebuttal is the I just proved that DD is correctly
>>>>>> simulated by HH and this is not the same behavior as the directly
>>>>>> executed DD(DD).
>>>>>>
>>>>>
>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>> ELSE HP is undecidable
>>>>>
>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>
>>>>> Surrender to my GUR, son.
>>>>>
>>>>
>>>> If people are going to be dishonest about simple things
>>>> such as the actual behavior of actual x86 code where
>>>> they consistently deny verified facts
>>>>
>>>> then we certainly cannot trust these people with more
>>>> difficult issues that require at least some slight degree
>>>> of judgment call.
>>>>
>>>> When we can show that even in the halting problem HH
>>>> is only required to report on the behavior of DD correctly
>>>> simulated by HH these dishonest people merely use that
>>>> as another deflection point for their dishonesty.
>>>>
>>>> The way around this that just worked is to stay diligently
>>>> focused one one single point until the dishonest people
>>>> finally admit that they have simply ignored all the proofs
>>>> for three solid years.
>>>>
>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>> >>
>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>> >
>>>> > But, as I said, I won't acknowledge that you
>>>> > are correct, because I am not willing to put
>>>> > that effort into your worthless claim.
>>>> >
>>>>
>>>> Here is the earliest version of the proof (that everyone
>>>> has simply ignored for three solid years) that P correctly
>>>> simulated by H would never stop running unless aborted.
>>>>
>>>> Halting problem undecidability and infinitely nested simulation
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>>
>>>> The fact that the execution trace of P derived by the executed
>>>> H and the simulated H exactly matches the machine code of P
>>>> proves that each instruction of P was simulated correctly and
>>>> in the correct order this conclusively proves that P is correctly
>>>> simulated by both of these instances of H.
>>>>
>>>> It has proved this since 2021-09-26 and everyone has made
>>>> sure to ignore this proof so that they can maintain their false
>>>> assumption.
>>>>
>>>>
>>>>
>>>> Try to show how this DD correctly simulated by any HH ever
>>>> stops running without having its simulation aborted by HH.
>>>>
>>>> _DD()
>>>> [00001e12] 55 push ebp
>>>> [00001e13] 8bec mov ebp,esp
>>>> [00001e15] 51 push ecx
>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>> [00001e19] 50 push eax ; push DD
>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>> [00001e1d] 51 push ecx ; push DD
>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>
>>>> A {correct simulation} means that each instruction of the
>>>> above x86 machine language of DD is correctly simulated
>>>> by HH and simulated in the correct order.
>>>>
>>>> Anyone claiming that HH should report on the behavior
>>>> of the directly executed DD(DD) is requiring a violation
>>>> of the above definition of correct simulation.
>>>>
>>>
>>> I recalled now. You knew what the Halting Problem is. But soon, you started to insist
>>> POOH is correct by fabricating ...(lots of things)...
>>> Wake up, your trick won't work.
>>>
>>
>> All the while that you insist on lying about
>>
>> the verified fact that DD correctly simulated by
>> HH cannot possibly stop running without having its
>> simulation aborted by HH.
>>
>> You won't get to talk to me about anything else such
>> as why the above statement matters.
>>
>> If you want to choose to be a liar thus <is> the
>> consequence that you get.
>>
>
> The Halting Problem asks for a program H (precisely a TM) that:
> IF H(D,D)==1, THEN D(D) will return.
> ELSE If H(D,D)==0, THEN D(D) will never return.
> ELSE HP is undecidable
>
> What is your answer? (the last time I saw POOH, it does not report anything)
>
I incorporate by reference
(a) The x86 language
(b) The notion of an x86 emulator
(c) I provide this complete function
void DDD(int (*x)())
{
HH(x, x);
}
_DDD()
[00001de2] 55 push ebp
[00001de3] 8bec mov ebp,esp
[00001de5] 8b4508 mov eax,[ebp+08]
[00001de8] 50 push eax ; push DD
[00001de9] 8b4d08 mov ecx,[ebp+08]
[00001dec] 51 push ecx ; push DD
[00001ded] e890f5ffff call 00001382 ; call HH
[00001df2] 83c408 add esp,+08
[00001df5] 5d pop ebp
[00001df6] c3 ret
Size in bytes:(0021) [00001df6]
Then I state that No DDD correctly emulated by any
x86 emulator H can possibly reach its own [00001df6]
instruction.
To anyone having this mandatory prerequisite knowledge
(perhaps not you) every x86 emulation of DDD by any
x86 emulator H continually repeats the first seven lines
of DDD until it crashes due to out-of-memory error.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-08 14:41 +0200 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41jhb$2jt63$1@dont-email.me> |
| In reply to | #106640 |
Op 08.jun.2024 om 14:20 schreef olcott:
> On 6/7/2024 11:18 PM, wij wrote:
>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>> On 6/7/2024 2:43 PM, wij wrote:
>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>
>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> [ .... ]
>>>>>>>>>>
>>>>>>>>>>> _DD()
>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>
>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>
>>>>>>>>>> That's a bit of sudden and substantial change, isn't it? Less
>>>>>>>>>> than a
>>>>>>>>>> few
>>>>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>>>>> instructions"
>>>>>>>>>> simulated (without ever specifying what you meant by N). It
>>>>>>>>>> seems that
>>>>>>>>>> the simulation of exactly one instruction would have met your
>>>>>>>>>> criterion.
>>>>>>>>>>
>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>
>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>
>>>>>>>>> _DD()
>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>
>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>
>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>
>>>>>>> More dishonest deflection.
>>>>>>> The point that I made and you try to deflect using the strawman
>>>>>>> deception as a fake rebuttal is the I just proved that DD is
>>>>>>> correctly
>>>>>>> simulated by HH and this is not the same behavior as the directly
>>>>>>> executed DD(DD).
>>>>>>>
>>>>>>
>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>> ELSE HP is undecidable
>>>>>>
>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>
>>>>>> Surrender to my GUR, son.
>>>>>>
>>>>>
>>>>> If people are going to be dishonest about simple things
>>>>> such as the actual behavior of actual x86 code where
>>>>> they consistently deny verified facts
>>>>>
>>>>> then we certainly cannot trust these people with more
>>>>> difficult issues that require at least some slight degree
>>>>> of judgment call.
>>>>>
>>>>> When we can show that even in the halting problem HH
>>>>> is only required to report on the behavior of DD correctly
>>>>> simulated by HH these dishonest people merely use that
>>>>> as another deflection point for their dishonesty.
>>>>>
>>>>> The way around this that just worked is to stay diligently
>>>>> focused one one single point until the dishonest people
>>>>> finally admit that they have simply ignored all the proofs
>>>>> for three solid years.
>>>>>
>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>> >>
>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>> >
>>>>> > But, as I said, I won't acknowledge that you
>>>>> > are correct, because I am not willing to put
>>>>> > that effort into your worthless claim.
>>>>> >
>>>>>
>>>>> Here is the earliest version of the proof (that everyone
>>>>> has simply ignored for three solid years) that P correctly
>>>>> simulated by H would never stop running unless aborted.
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>
>>>>>
>>>>> The fact that the execution trace of P derived by the executed
>>>>> H and the simulated H exactly matches the machine code of P
>>>>> proves that each instruction of P was simulated correctly and
>>>>> in the correct order this conclusively proves that P is correctly
>>>>> simulated by both of these instances of H.
>>>>>
>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>> sure to ignore this proof so that they can maintain their false
>>>>> assumption.
>>>>>
>>>>>
>>>>>
>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>> stops running without having its simulation aborted by HH.
>>>>>
>>>>> _DD()
>>>>> [00001e12] 55 push ebp
>>>>> [00001e13] 8bec mov ebp,esp
>>>>> [00001e15] 51 push ecx
>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>> [00001e19] 50 push eax ; push DD
>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>> [00001e1d] 51 push ecx ; push DD
>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>
>>>>> A {correct simulation} means that each instruction of the
>>>>> above x86 machine language of DD is correctly simulated
>>>>> by HH and simulated in the correct order.
>>>>>
>>>>> Anyone claiming that HH should report on the behavior
>>>>> of the directly executed DD(DD) is requiring a violation
>>>>> of the above definition of correct simulation.
>>>>>
>>>>
>>>> I recalled now. You knew what the Halting Problem is. But soon, you
>>>> started to insist
>>>> POOH is correct by fabricating ...(lots of things)...
>>>> Wake up, your trick won't work.
>>>>
>>>
>>> All the while that you insist on lying about
>>>
>>> the verified fact that DD correctly simulated by
>>> HH cannot possibly stop running without having its
>>> simulation aborted by HH.
>>>
>>> You won't get to talk to me about anything else such
>>> as why the above statement matters.
>>>
>>> If you want to choose to be a liar thus <is> the
>>> consequence that you get.
>>>
>>
>> The Halting Problem asks for a program H (precisely a TM) that:
>> IF H(D,D)==1, THEN D(D) will return.
>> ELSE If H(D,D)==0, THEN D(D) will never return.
>> ELSE HP is undecidable
>>
>> What is your answer? (the last time I saw POOH, it does not report
>> anything)
>>
>
> I incorporate by reference
> (a) The x86 language
> (b) The notion of an x86 emulator
>
> (c) I provide this complete function
>
> void DDD(int (*x)())
> {
> HH(x, x);
> }
>
> _DDD()
> [00001de2] 55 push ebp
> [00001de3] 8bec mov ebp,esp
> [00001de5] 8b4508 mov eax,[ebp+08]
> [00001de8] 50 push eax ; push DD
> [00001de9] 8b4d08 mov ecx,[ebp+08]
> [00001dec] 51 push ecx ; push DD
> [00001ded] e890f5ffff call 00001382 ; call HH
> [00001df2] 83c408 add esp,+08
> [00001df5] 5d pop ebp
> [00001df6] c3 ret
> Size in bytes:(0021) [00001df6]
>
> Then I state that No DDD correctly emulated by any
> x86 emulator H can possibly reach its own [00001df6]
> instruction.
>
> To anyone having this mandatory prerequisite knowledge
> (perhaps not you) every x86 emulation of DDD by any
> x86 emulator H continually repeats the first seven lines
> of DDD until it crashes due to out-of-memory error.
>
The only reason being that HH, although required to halt, does not halt,
but calls DDD recursively until it is aborted.
For everyone with a little bit of knowledge of the x86 language it is
clear that if HH would return (as required), then DDD would return as well.
So, not only DDD, but also HH is a problem for the simulator, because
they keep creating new instances of each other.
That the direct execution of HH halts, but the simulation of HH does not
halt, is a clear indication that HH is not correctly simulated. In that
case it does not help to simulate only DDD correctly. The simulation of
HH should go at least to the point where HH returns to DDD. But the
simulator is unable to do that, because it aborts too early, which is a
problem of the simulator, not of DDD.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 08:16 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41liv$2kanc$2@dont-email.me> |
| In reply to | #106645 |
On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
> Op 08.jun.2024 om 14:20 schreef olcott:
>> On 6/7/2024 11:18 PM, wij wrote:
>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>
>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> [ .... ]
>>>>>>>>>>>
>>>>>>>>>>>> _DD()
>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>
>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>
>>>>>>>>>>> That's a bit of sudden and substantial change, isn't it?
>>>>>>>>>>> Less than a
>>>>>>>>>>> few
>>>>>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>>>>>> instructions"
>>>>>>>>>>> simulated (without ever specifying what you meant by N). It
>>>>>>>>>>> seems that
>>>>>>>>>>> the simulation of exactly one instruction would have met your
>>>>>>>>>>> criterion.
>>>>>>>>>>>
>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>
>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>
>>>>>>>>>> _DD()
>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>
>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>
>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>
>>>>>>>> More dishonest deflection.
>>>>>>>> The point that I made and you try to deflect using the strawman
>>>>>>>> deception as a fake rebuttal is the I just proved that DD is
>>>>>>>> correctly
>>>>>>>> simulated by HH and this is not the same behavior as the directly
>>>>>>>> executed DD(DD).
>>>>>>>>
>>>>>>>
>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>> ELSE HP is undecidable
>>>>>>>
>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>
>>>>>>> Surrender to my GUR, son.
>>>>>>>
>>>>>>
>>>>>> If people are going to be dishonest about simple things
>>>>>> such as the actual behavior of actual x86 code where
>>>>>> they consistently deny verified facts
>>>>>>
>>>>>> then we certainly cannot trust these people with more
>>>>>> difficult issues that require at least some slight degree
>>>>>> of judgment call.
>>>>>>
>>>>>> When we can show that even in the halting problem HH
>>>>>> is only required to report on the behavior of DD correctly
>>>>>> simulated by HH these dishonest people merely use that
>>>>>> as another deflection point for their dishonesty.
>>>>>>
>>>>>> The way around this that just worked is to stay diligently
>>>>>> focused one one single point until the dishonest people
>>>>>> finally admit that they have simply ignored all the proofs
>>>>>> for three solid years.
>>>>>>
>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>> >>
>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>> >
>>>>>> > But, as I said, I won't acknowledge that you
>>>>>> > are correct, because I am not willing to put
>>>>>> > that effort into your worthless claim.
>>>>>> >
>>>>>>
>>>>>> Here is the earliest version of the proof (that everyone
>>>>>> has simply ignored for three solid years) that P correctly
>>>>>> simulated by H would never stop running unless aborted.
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>
>>>>>>
>>>>>> The fact that the execution trace of P derived by the executed
>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>> proves that each instruction of P was simulated correctly and
>>>>>> in the correct order this conclusively proves that P is correctly
>>>>>> simulated by both of these instances of H.
>>>>>>
>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>> sure to ignore this proof so that they can maintain their false
>>>>>> assumption.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>> stops running without having its simulation aborted by HH.
>>>>>>
>>>>>> _DD()
>>>>>> [00001e12] 55 push ebp
>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>> [00001e15] 51 push ecx
>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>> [00001e19] 50 push eax ; push DD
>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>
>>>>>> A {correct simulation} means that each instruction of the
>>>>>> above x86 machine language of DD is correctly simulated
>>>>>> by HH and simulated in the correct order.
>>>>>>
>>>>>> Anyone claiming that HH should report on the behavior
>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>> of the above definition of correct simulation.
>>>>>>
>>>>>
>>>>> I recalled now. You knew what the Halting Problem is. But soon, you
>>>>> started to insist
>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>> Wake up, your trick won't work.
>>>>>
>>>>
>>>> All the while that you insist on lying about
>>>>
>>>> the verified fact that DD correctly simulated by
>>>> HH cannot possibly stop running without having its
>>>> simulation aborted by HH.
>>>>
>>>> You won't get to talk to me about anything else such
>>>> as why the above statement matters.
>>>>
>>>> If you want to choose to be a liar thus <is> the
>>>> consequence that you get.
>>>>
>>>
>>> The Halting Problem asks for a program H (precisely a TM) that:
>>> IF H(D,D)==1, THEN D(D) will return.
>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>> ELSE HP is undecidable
>>>
>>> What is your answer? (the last time I saw POOH, it does not report
>>> anything)
>>>
>>
>> I incorporate by reference
>> (a) The x86 language
>> (b) The notion of an x86 emulator
>>
>> (c) I provide this complete function
>>
>> void DDD(int (*x)())
>> {
>> HH(x, x);
>> }
>>
>> _DDD()
>> [00001de2] 55 push ebp
>> [00001de3] 8bec mov ebp,esp
>> [00001de5] 8b4508 mov eax,[ebp+08]
>> [00001de8] 50 push eax ; push DD
>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>> [00001dec] 51 push ecx ; push DD
>> [00001ded] e890f5ffff call 00001382 ; call HH
>> [00001df2] 83c408 add esp,+08
>> [00001df5] 5d pop ebp
>> [00001df6] c3 ret
>> Size in bytes:(0021) [00001df6]
>>
>> Then I state that No DDD correctly emulated by any
>> x86 emulator H can possibly reach its own [00001df6]
>> instruction.
>>
>> To anyone having this mandatory prerequisite knowledge
>> (perhaps not you) every x86 emulation of DDD by any
>> x86 emulator H continually repeats the first seven lines
>> of DDD until it crashes due to out-of-memory error.
>>
>
> The only reason being that HH, although required to halt, does not halt,
> but calls DDD recursively until it is aborted.
Try rereading this again and again until to understand and remember
all of its words unless you fully intend to stay in rebuttal mode
against the verified facts. In that case I will quit replying to
your messages.
<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 words10/13/2022>
> For everyone with a little bit of knowledge of the x86 language it is
> clear that if HH would return (as required), then DDD would return as well.
> So, not only DDD, but also HH is a problem for the simulator, because
> they keep creating new instances of each other.
> That the direct execution of HH halts, but the simulation of HH does not
> halt, is a clear indication that HH is not correctly simulated. In that
> case it does not help to simulate only DDD correctly. The simulation of
> HH should go at least to the point where HH returns to DDD. But the
> simulator is unable to do that, because it aborts too early, which is a
> problem of the simulator, not of DDD.
>
--
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-08 15:38 +0200 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41msk$2jt63$3@dont-email.me> |
| In reply to | #106665 |
Op 08.jun.2024 om 15:16 schreef olcott:
> On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 14:20 schreef olcott:
>>> On 6/7/2024 11:18 PM, wij wrote:
>>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>
>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>
>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>
>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>
>>>>>>>>>>>> That's a bit of sudden and substantial change, isn't it?
>>>>>>>>>>>> Less than a
>>>>>>>>>>>> few
>>>>>>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>>>>>>> instructions"
>>>>>>>>>>>> simulated (without ever specifying what you meant by N). It
>>>>>>>>>>>> seems that
>>>>>>>>>>>> the simulation of exactly one instruction would have met
>>>>>>>>>>>> your criterion.
>>>>>>>>>>>>
>>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>>
>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>
>>>>>>>>>>> _DD()
>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>
>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>
>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>>
>>>>>>>>> More dishonest deflection.
>>>>>>>>> The point that I made and you try to deflect using the strawman
>>>>>>>>> deception as a fake rebuttal is the I just proved that DD is
>>>>>>>>> correctly
>>>>>>>>> simulated by HH and this is not the same behavior as the directly
>>>>>>>>> executed DD(DD).
>>>>>>>>>
>>>>>>>>
>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>> ELSE HP is undecidable
>>>>>>>>
>>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>>
>>>>>>>> Surrender to my GUR, son.
>>>>>>>>
>>>>>>>
>>>>>>> If people are going to be dishonest about simple things
>>>>>>> such as the actual behavior of actual x86 code where
>>>>>>> they consistently deny verified facts
>>>>>>>
>>>>>>> then we certainly cannot trust these people with more
>>>>>>> difficult issues that require at least some slight degree
>>>>>>> of judgment call.
>>>>>>>
>>>>>>> When we can show that even in the halting problem HH
>>>>>>> is only required to report on the behavior of DD correctly
>>>>>>> simulated by HH these dishonest people merely use that
>>>>>>> as another deflection point for their dishonesty.
>>>>>>>
>>>>>>> The way around this that just worked is to stay diligently
>>>>>>> focused one one single point until the dishonest people
>>>>>>> finally admit that they have simply ignored all the proofs
>>>>>>> for three solid years.
>>>>>>>
>>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>>> >>
>>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>>> >
>>>>>>> > But, as I said, I won't acknowledge that you
>>>>>>> > are correct, because I am not willing to put
>>>>>>> > that effort into your worthless claim.
>>>>>>> >
>>>>>>>
>>>>>>> Here is the earliest version of the proof (that everyone
>>>>>>> has simply ignored for three solid years) that P correctly
>>>>>>> simulated by H would never stop running unless aborted.
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>
>>>>>>>
>>>>>>> The fact that the execution trace of P derived by the executed
>>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>>> proves that each instruction of P was simulated correctly and
>>>>>>> in the correct order this conclusively proves that P is correctly
>>>>>>> simulated by both of these instances of H.
>>>>>>>
>>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>>> sure to ignore this proof so that they can maintain their false
>>>>>>> assumption.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>
>>>>>>> _DD()
>>>>>>> [00001e12] 55 push ebp
>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>> [00001e15] 51 push ecx
>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>
>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>> by HH and simulated in the correct order.
>>>>>>>
>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>> of the above definition of correct simulation.
>>>>>>>
>>>>>>
>>>>>> I recalled now. You knew what the Halting Problem is. But soon,
>>>>>> you started to insist
>>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>>> Wake up, your trick won't work.
>>>>>>
>>>>>
>>>>> All the while that you insist on lying about
>>>>>
>>>>> the verified fact that DD correctly simulated by
>>>>> HH cannot possibly stop running without having its
>>>>> simulation aborted by HH.
>>>>>
>>>>> You won't get to talk to me about anything else such
>>>>> as why the above statement matters.
>>>>>
>>>>> If you want to choose to be a liar thus <is> the
>>>>> consequence that you get.
>>>>>
>>>>
>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>> IF H(D,D)==1, THEN D(D) will return.
>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>> ELSE HP is undecidable
>>>>
>>>> What is your answer? (the last time I saw POOH, it does not report
>>>> anything)
>>>>
>>>
>>> I incorporate by reference
>>> (a) The x86 language
>>> (b) The notion of an x86 emulator
>>>
>>> (c) I provide this complete function
>>>
>>> void DDD(int (*x)())
>>> {
>>> HH(x, x);
>>> }
>>>
>>> _DDD()
>>> [00001de2] 55 push ebp
>>> [00001de3] 8bec mov ebp,esp
>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>> [00001de8] 50 push eax ; push DD
>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>> [00001dec] 51 push ecx ; push DD
>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>> [00001df2] 83c408 add esp,+08
>>> [00001df5] 5d pop ebp
>>> [00001df6] c3 ret
>>> Size in bytes:(0021) [00001df6]
>>>
>>> Then I state that No DDD correctly emulated by any
>>> x86 emulator H can possibly reach its own [00001df6]
>>> instruction.
>>>
>>> To anyone having this mandatory prerequisite knowledge
>>> (perhaps not you) every x86 emulation of DDD by any
>>> x86 emulator H continually repeats the first seven lines
>>> of DDD until it crashes due to out-of-memory error.
>>>
>>
>> The only reason being that HH, although required to halt, does not
>> halt, but calls DDD recursively until it is aborted.
>
> Try rereading this again and again until to understand and remember
> all of its words unless you fully intend to stay in rebuttal mode
> against the verified facts. In that case I will quit replying to
> your messages.
>
> <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 words10/13/2022>
Don't only cite Sipser, but try to understand the words. Try to think!
If he really agreed about D, he would come to the same conclusion for H.
If simulating halt decider H correctly simulates its input H
(as part of D)
until H correctly determines that its simulated H would never
stop running unless aborted then
H can abort its simulation of H and correctly report that H
specifies a non-halting sequence of configurations.
So, the following is still valid:
>
>> For everyone with a little bit of knowledge of the x86 language it is
>> clear that if HH would return (as required), then DDD would return as
>> well.
>> So, not only DDD, but also HH is a problem for the simulator, because
>> they keep creating new instances of each other.
>> That the direct execution of HH halts, but the simulation of HH does
>> not halt, is a clear indication that HH is not correctly simulated. In
>> that case it does not help to simulate only DDD correctly. The
>> simulation of HH should go at least to the point where HH returns to
>> DDD. But the simulator is unable to do that, because it aborts too
>> early, which is a problem of the simulator, not of DDD.
>>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 08:50 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41nja$2kanc$9@dont-email.me> |
| In reply to | #106671 |
On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
> Op 08.jun.2024 om 15:16 schreef olcott:
>> On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
>>> Op 08.jun.2024 om 14:20 schreef olcott:
>>>> On 6/7/2024 11:18 PM, wij wrote:
>>>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>>
>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>
>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's a bit of sudden and substantial change, isn't it?
>>>>>>>>>>>>> Less than a
>>>>>>>>>>>>> few
>>>>>>>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>>>>>>>> instructions"
>>>>>>>>>>>>> simulated (without ever specifying what you meant by N).
>>>>>>>>>>>>> It seems that
>>>>>>>>>>>>> the simulation of exactly one instruction would have met
>>>>>>>>>>>>> your criterion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>>>
>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>
>>>>>>>>>>>> _DD()
>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>
>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>>>
>>>>>>>>>> More dishonest deflection.
>>>>>>>>>> The point that I made and you try to deflect using the strawman
>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD is
>>>>>>>>>> correctly
>>>>>>>>>> simulated by HH and this is not the same behavior as the directly
>>>>>>>>>> executed DD(DD).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>
>>>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>>>
>>>>>>>>> Surrender to my GUR, son.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If people are going to be dishonest about simple things
>>>>>>>> such as the actual behavior of actual x86 code where
>>>>>>>> they consistently deny verified facts
>>>>>>>>
>>>>>>>> then we certainly cannot trust these people with more
>>>>>>>> difficult issues that require at least some slight degree
>>>>>>>> of judgment call.
>>>>>>>>
>>>>>>>> When we can show that even in the halting problem HH
>>>>>>>> is only required to report on the behavior of DD correctly
>>>>>>>> simulated by HH these dishonest people merely use that
>>>>>>>> as another deflection point for their dishonesty.
>>>>>>>>
>>>>>>>> The way around this that just worked is to stay diligently
>>>>>>>> focused one one single point until the dishonest people
>>>>>>>> finally admit that they have simply ignored all the proofs
>>>>>>>> for three solid years.
>>>>>>>>
>>>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>>>> >>
>>>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>>>> >
>>>>>>>> > But, as I said, I won't acknowledge that you
>>>>>>>> > are correct, because I am not willing to put
>>>>>>>> > that effort into your worthless claim.
>>>>>>>> >
>>>>>>>>
>>>>>>>> Here is the earliest version of the proof (that everyone
>>>>>>>> has simply ignored for three solid years) that P correctly
>>>>>>>> simulated by H would never stop running unless aborted.
>>>>>>>>
>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>
>>>>>>>>
>>>>>>>> The fact that the execution trace of P derived by the executed
>>>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>>>> proves that each instruction of P was simulated correctly and
>>>>>>>> in the correct order this conclusively proves that P is correctly
>>>>>>>> simulated by both of these instances of H.
>>>>>>>>
>>>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>>>> sure to ignore this proof so that they can maintain their false
>>>>>>>> assumption.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>
>>>>>>>> _DD()
>>>>>>>> [00001e12] 55 push ebp
>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>> [00001e15] 51 push ecx
>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>
>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>
>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>> of the above definition of correct simulation.
>>>>>>>>
>>>>>>>
>>>>>>> I recalled now. You knew what the Halting Problem is. But soon,
>>>>>>> you started to insist
>>>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>>>> Wake up, your trick won't work.
>>>>>>>
>>>>>>
>>>>>> All the while that you insist on lying about
>>>>>>
>>>>>> the verified fact that DD correctly simulated by
>>>>>> HH cannot possibly stop running without having its
>>>>>> simulation aborted by HH.
>>>>>>
>>>>>> You won't get to talk to me about anything else such
>>>>>> as why the above statement matters.
>>>>>>
>>>>>> If you want to choose to be a liar thus <is> the
>>>>>> consequence that you get.
>>>>>>
>>>>>
>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>> ELSE HP is undecidable
>>>>>
>>>>> What is your answer? (the last time I saw POOH, it does not report
>>>>> anything)
>>>>>
>>>>
>>>> I incorporate by reference
>>>> (a) The x86 language
>>>> (b) The notion of an x86 emulator
>>>>
>>>> (c) I provide this complete function
>>>>
>>>> void DDD(int (*x)())
>>>> {
>>>> HH(x, x);
>>>> }
>>>>
>>>> _DDD()
>>>> [00001de2] 55 push ebp
>>>> [00001de3] 8bec mov ebp,esp
>>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>>> [00001de8] 50 push eax ; push DD
>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>>> [00001dec] 51 push ecx ; push DD
>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>> [00001df2] 83c408 add esp,+08
>>>> [00001df5] 5d pop ebp
>>>> [00001df6] c3 ret
>>>> Size in bytes:(0021) [00001df6]
>>>>
>>>> Then I state that No DDD correctly emulated by any
>>>> x86 emulator H can possibly reach its own [00001df6]
>>>> instruction.
>>>>
>>>> To anyone having this mandatory prerequisite knowledge
>>>> (perhaps not you) every x86 emulation of DDD by any
>>>> x86 emulator H continually repeats the first seven lines
>>>> of DDD until it crashes due to out-of-memory error.
>>>>
>>>
>>> The only reason being that HH, although required to halt, does not
>>> halt, but calls DDD recursively until it is aborted.
>>
>> Try rereading this again and again until to understand and remember
>> all of its words unless you fully intend to stay in rebuttal mode
>> against the verified facts. In that case I will quit replying to
>> your messages.
>>
>> <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 words10/13/2022>
>
> Don't only cite Sipser, but try to understand the words. Try to think!
> If he really agreed about D, he would come to the same conclusion for H.
>
> If simulating halt decider H correctly simulates its input H
> (as part of D)
> until H correctly determines that its simulated H would never
> stop running unless aborted then
>
> H can abort its simulation of H and correctly report that H
> specifies a non-halting sequence of configurations.
>
It is only that DD calls HH that makes the simulated HH not halt.
--
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-08 16:01 +0200 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41o8l$2jt63$5@dont-email.me> |
| In reply to | #106678 |
Op 08.jun.2024 om 15:50 schreef olcott:
> On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 15:16 schreef olcott:
>>> On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
>>>> Op 08.jun.2024 om 14:20 schreef olcott:
>>>>> On 6/7/2024 11:18 PM, wij wrote:
>>>>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's a bit of sudden and substantial change, isn't it?
>>>>>>>>>>>>>> Less than a
>>>>>>>>>>>>>> few
>>>>>>>>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>>>>>>>>> instructions"
>>>>>>>>>>>>>> simulated (without ever specifying what you meant by N).
>>>>>>>>>>>>>> It seems that
>>>>>>>>>>>>>> the simulation of exactly one instruction would have met
>>>>>>>>>>>>>> your criterion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>>
>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>
>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>>>>
>>>>>>>>>>> More dishonest deflection.
>>>>>>>>>>> The point that I made and you try to deflect using the strawman
>>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD is
>>>>>>>>>>> correctly
>>>>>>>>>>> simulated by HH and this is not the same behavior as the
>>>>>>>>>>> directly
>>>>>>>>>>> executed DD(DD).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>>
>>>>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>>>>
>>>>>>>>>> Surrender to my GUR, son.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If people are going to be dishonest about simple things
>>>>>>>>> such as the actual behavior of actual x86 code where
>>>>>>>>> they consistently deny verified facts
>>>>>>>>>
>>>>>>>>> then we certainly cannot trust these people with more
>>>>>>>>> difficult issues that require at least some slight degree
>>>>>>>>> of judgment call.
>>>>>>>>>
>>>>>>>>> When we can show that even in the halting problem HH
>>>>>>>>> is only required to report on the behavior of DD correctly
>>>>>>>>> simulated by HH these dishonest people merely use that
>>>>>>>>> as another deflection point for their dishonesty.
>>>>>>>>>
>>>>>>>>> The way around this that just worked is to stay diligently
>>>>>>>>> focused one one single point until the dishonest people
>>>>>>>>> finally admit that they have simply ignored all the proofs
>>>>>>>>> for three solid years.
>>>>>>>>>
>>>>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>>>>> >>
>>>>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>>>>> >
>>>>>>>>> > But, as I said, I won't acknowledge that you
>>>>>>>>> > are correct, because I am not willing to put
>>>>>>>>> > that effort into your worthless claim.
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> Here is the earliest version of the proof (that everyone
>>>>>>>>> has simply ignored for three solid years) that P correctly
>>>>>>>>> simulated by H would never stop running unless aborted.
>>>>>>>>>
>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The fact that the execution trace of P derived by the executed
>>>>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>>>>> proves that each instruction of P was simulated correctly and
>>>>>>>>> in the correct order this conclusively proves that P is correctly
>>>>>>>>> simulated by both of these instances of H.
>>>>>>>>>
>>>>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>>>>> sure to ignore this proof so that they can maintain their false
>>>>>>>>> assumption.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>
>>>>>>>>> _DD()
>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>
>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>
>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I recalled now. You knew what the Halting Problem is. But soon,
>>>>>>>> you started to insist
>>>>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>>>>> Wake up, your trick won't work.
>>>>>>>>
>>>>>>>
>>>>>>> All the while that you insist on lying about
>>>>>>>
>>>>>>> the verified fact that DD correctly simulated by
>>>>>>> HH cannot possibly stop running without having its
>>>>>>> simulation aborted by HH.
>>>>>>>
>>>>>>> You won't get to talk to me about anything else such
>>>>>>> as why the above statement matters.
>>>>>>>
>>>>>>> If you want to choose to be a liar thus <is> the
>>>>>>> consequence that you get.
>>>>>>>
>>>>>>
>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>> ELSE HP is undecidable
>>>>>>
>>>>>> What is your answer? (the last time I saw POOH, it does not report
>>>>>> anything)
>>>>>>
>>>>>
>>>>> I incorporate by reference
>>>>> (a) The x86 language
>>>>> (b) The notion of an x86 emulator
>>>>>
>>>>> (c) I provide this complete function
>>>>>
>>>>> void DDD(int (*x)())
>>>>> {
>>>>> HH(x, x);
>>>>> }
>>>>>
>>>>> _DDD()
>>>>> [00001de2] 55 push ebp
>>>>> [00001de3] 8bec mov ebp,esp
>>>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>>>> [00001de8] 50 push eax ; push DD
>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>>>> [00001dec] 51 push ecx ; push DD
>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>>> [00001df2] 83c408 add esp,+08
>>>>> [00001df5] 5d pop ebp
>>>>> [00001df6] c3 ret
>>>>> Size in bytes:(0021) [00001df6]
>>>>>
>>>>> Then I state that No DDD correctly emulated by any
>>>>> x86 emulator H can possibly reach its own [00001df6]
>>>>> instruction.
>>>>>
>>>>> To anyone having this mandatory prerequisite knowledge
>>>>> (perhaps not you) every x86 emulation of DDD by any
>>>>> x86 emulator H continually repeats the first seven lines
>>>>> of DDD until it crashes due to out-of-memory error.
>>>>>
>>>>
>>>> The only reason being that HH, although required to halt, does not
>>>> halt, but calls DDD recursively until it is aborted.
>>>
>>> Try rereading this again and again until to understand and remember
>>> all of its words unless you fully intend to stay in rebuttal mode
>>> against the verified facts. In that case I will quit replying to
>>> your messages.
>>>
>>> <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 words10/13/2022>
>>
>> Don't only cite Sipser, but try to understand the words. Try to think!
>> If he really agreed about D, he would come to the same conclusion for H.
>>
>> If simulating halt decider H correctly simulates its input H
>> (as part of D)
>> until H correctly determines that its simulated H would never
>> stop running unless aborted then
>>
>> H can abort its simulation of H and correctly report that H
>> specifies a non-halting sequence of configurations.
>>
>
> It is only that DD calls HH that makes the simulated HH not halt.
>
>
With similar logic we can say that it is only HH that simulates DD that
makes the simulated DD not halt.
The fact is that HH and DD both keep creating new instances of each
other. If one of them would halt, the other one would halt as well. Your
claim is that HH halts. If so, then DD halts as well.
Try to think!
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 09:06 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41ogt$2kanc$13@dont-email.me> |
| In reply to | #106685 |
On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
> Op 08.jun.2024 om 15:50 schreef olcott:
>> On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
>>> Op 08.jun.2024 om 15:16 schreef olcott:
>>>> On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
>>>>> Op 08.jun.2024 om 14:20 schreef olcott:
>>>>>> On 6/7/2024 11:18 PM, wij wrote:
>>>>>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>>>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's a bit of sudden and substantial change, isn't it?
>>>>>>>>>>>>>>> Less than a
>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>>>>>>>>>> instructions"
>>>>>>>>>>>>>>> simulated (without ever specifying what you meant by N).
>>>>>>>>>>>>>>> It seems that
>>>>>>>>>>>>>>> the simulation of exactly one instruction would have met
>>>>>>>>>>>>>>> your criterion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>>>>>
>>>>>>>>>>>> More dishonest deflection.
>>>>>>>>>>>> The point that I made and you try to deflect using the strawman
>>>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD is
>>>>>>>>>>>> correctly
>>>>>>>>>>>> simulated by HH and this is not the same behavior as the
>>>>>>>>>>>> directly
>>>>>>>>>>>> executed DD(DD).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>>>
>>>>>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>>>>>
>>>>>>>>>>> Surrender to my GUR, son.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If people are going to be dishonest about simple things
>>>>>>>>>> such as the actual behavior of actual x86 code where
>>>>>>>>>> they consistently deny verified facts
>>>>>>>>>>
>>>>>>>>>> then we certainly cannot trust these people with more
>>>>>>>>>> difficult issues that require at least some slight degree
>>>>>>>>>> of judgment call.
>>>>>>>>>>
>>>>>>>>>> When we can show that even in the halting problem HH
>>>>>>>>>> is only required to report on the behavior of DD correctly
>>>>>>>>>> simulated by HH these dishonest people merely use that
>>>>>>>>>> as another deflection point for their dishonesty.
>>>>>>>>>>
>>>>>>>>>> The way around this that just worked is to stay diligently
>>>>>>>>>> focused one one single point until the dishonest people
>>>>>>>>>> finally admit that they have simply ignored all the proofs
>>>>>>>>>> for three solid years.
>>>>>>>>>>
>>>>>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>>>>>> >
>>>>>>>>>> > But, as I said, I won't acknowledge that you
>>>>>>>>>> > are correct, because I am not willing to put
>>>>>>>>>> > that effort into your worthless claim.
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> Here is the earliest version of the proof (that everyone
>>>>>>>>>> has simply ignored for three solid years) that P correctly
>>>>>>>>>> simulated by H would never stop running unless aborted.
>>>>>>>>>>
>>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The fact that the execution trace of P derived by the executed
>>>>>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>>>>>> proves that each instruction of P was simulated correctly and
>>>>>>>>>> in the correct order this conclusively proves that P is correctly
>>>>>>>>>> simulated by both of these instances of H.
>>>>>>>>>>
>>>>>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>>>>>> sure to ignore this proof so that they can maintain their false
>>>>>>>>>> assumption.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>
>>>>>>>>>> _DD()
>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>
>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>
>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I recalled now. You knew what the Halting Problem is. But soon,
>>>>>>>>> you started to insist
>>>>>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>>>>>> Wake up, your trick won't work.
>>>>>>>>>
>>>>>>>>
>>>>>>>> All the while that you insist on lying about
>>>>>>>>
>>>>>>>> the verified fact that DD correctly simulated by
>>>>>>>> HH cannot possibly stop running without having its
>>>>>>>> simulation aborted by HH.
>>>>>>>>
>>>>>>>> You won't get to talk to me about anything else such
>>>>>>>> as why the above statement matters.
>>>>>>>>
>>>>>>>> If you want to choose to be a liar thus <is> the
>>>>>>>> consequence that you get.
>>>>>>>>
>>>>>>>
>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>> ELSE HP is undecidable
>>>>>>>
>>>>>>> What is your answer? (the last time I saw POOH, it does not
>>>>>>> report anything)
>>>>>>>
>>>>>>
>>>>>> I incorporate by reference
>>>>>> (a) The x86 language
>>>>>> (b) The notion of an x86 emulator
>>>>>>
>>>>>> (c) I provide this complete function
>>>>>>
>>>>>> void DDD(int (*x)())
>>>>>> {
>>>>>> HH(x, x);
>>>>>> }
>>>>>>
>>>>>> _DDD()
>>>>>> [00001de2] 55 push ebp
>>>>>> [00001de3] 8bec mov ebp,esp
>>>>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>>>>> [00001de8] 50 push eax ; push DD
>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>>>>> [00001dec] 51 push ecx ; push DD
>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>>>> [00001df2] 83c408 add esp,+08
>>>>>> [00001df5] 5d pop ebp
>>>>>> [00001df6] c3 ret
>>>>>> Size in bytes:(0021) [00001df6]
>>>>>>
>>>>>> Then I state that No DDD correctly emulated by any
>>>>>> x86 emulator H can possibly reach its own [00001df6]
>>>>>> instruction.
>>>>>>
>>>>>> To anyone having this mandatory prerequisite knowledge
>>>>>> (perhaps not you) every x86 emulation of DDD by any
>>>>>> x86 emulator H continually repeats the first seven lines
>>>>>> of DDD until it crashes due to out-of-memory error.
>>>>>>
>>>>>
>>>>> The only reason being that HH, although required to halt, does not
>>>>> halt, but calls DDD recursively until it is aborted.
>>>>
>>>> Try rereading this again and again until to understand and remember
>>>> all of its words unless you fully intend to stay in rebuttal mode
>>>> against the verified facts. In that case I will quit replying to
>>>> your messages.
>>>>
>>>> <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 words10/13/2022>
>>>
>>> Don't only cite Sipser, but try to understand the words. Try to
>>> think! If he really agreed about D, he would come to the same
>>> conclusion for H.
>>>
>>> If simulating halt decider H correctly simulates its input H
>>> (as part of D)
>>> until H correctly determines that its simulated H would never
>>> stop running unless aborted then
>>>
>>> H can abort its simulation of H and correctly report that H
>>> specifies a non-halting sequence of configurations.
>>>
>>
>> It is only that DD calls HH that makes the simulated HH not halt.
>>
>>
>
> With similar logic we can say that it is only HH that simulates DD that
> makes the simulated DD not halt.
>
HH(DD,DD)==0 Please quit lying about this.
--
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-08 16:19 +0200 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41p8p$2jt63$6@dont-email.me> |
| In reply to | #106689 |
Op 08.jun.2024 om 16:06 schreef olcott:
> On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 15:50 schreef olcott:
>>> On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
>>>> Op 08.jun.2024 om 15:16 schreef olcott:
>>>>> On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
>>>>>> Op 08.jun.2024 om 14:20 schreef olcott:
>>>>>>> On 6/7/2024 11:18 PM, wij wrote:
>>>>>>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>>>>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>>>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That's a bit of sudden and substantial change, isn't it?
>>>>>>>>>>>>>>>> Less than a
>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>>>>>>>>>>>> instructions"
>>>>>>>>>>>>>>>> simulated (without ever specifying what you meant by N).
>>>>>>>>>>>>>>>> It seems that
>>>>>>>>>>>>>>>> the simulation of exactly one instruction would have met
>>>>>>>>>>>>>>>> your criterion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>>>>>>
>>>>>>>>>>>>> More dishonest deflection.
>>>>>>>>>>>>> The point that I made and you try to deflect using the
>>>>>>>>>>>>> strawman
>>>>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD
>>>>>>>>>>>>> is correctly
>>>>>>>>>>>>> simulated by HH and this is not the same behavior as the
>>>>>>>>>>>>> directly
>>>>>>>>>>>>> executed DD(DD).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>>>>
>>>>>>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>>>>>>
>>>>>>>>>>>> Surrender to my GUR, son.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If people are going to be dishonest about simple things
>>>>>>>>>>> such as the actual behavior of actual x86 code where
>>>>>>>>>>> they consistently deny verified facts
>>>>>>>>>>>
>>>>>>>>>>> then we certainly cannot trust these people with more
>>>>>>>>>>> difficult issues that require at least some slight degree
>>>>>>>>>>> of judgment call.
>>>>>>>>>>>
>>>>>>>>>>> When we can show that even in the halting problem HH
>>>>>>>>>>> is only required to report on the behavior of DD correctly
>>>>>>>>>>> simulated by HH these dishonest people merely use that
>>>>>>>>>>> as another deflection point for their dishonesty.
>>>>>>>>>>>
>>>>>>>>>>> The way around this that just worked is to stay diligently
>>>>>>>>>>> focused one one single point until the dishonest people
>>>>>>>>>>> finally admit that they have simply ignored all the proofs
>>>>>>>>>>> for three solid years.
>>>>>>>>>>>
>>>>>>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>>>>>>> >
>>>>>>>>>>> > But, as I said, I won't acknowledge that you
>>>>>>>>>>> > are correct, because I am not willing to put
>>>>>>>>>>> > that effort into your worthless claim.
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>> Here is the earliest version of the proof (that everyone
>>>>>>>>>>> has simply ignored for three solid years) that P correctly
>>>>>>>>>>> simulated by H would never stop running unless aborted.
>>>>>>>>>>>
>>>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The fact that the execution trace of P derived by the executed
>>>>>>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>>>>>>> proves that each instruction of P was simulated correctly and
>>>>>>>>>>> in the correct order this conclusively proves that P is
>>>>>>>>>>> correctly
>>>>>>>>>>> simulated by both of these instances of H.
>>>>>>>>>>>
>>>>>>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>>>>>>> sure to ignore this proof so that they can maintain their false
>>>>>>>>>>> assumption.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>
>>>>>>>>>>> _DD()
>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>
>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>
>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I recalled now. You knew what the Halting Problem is. But
>>>>>>>>>> soon, you started to insist
>>>>>>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>>>>>>> Wake up, your trick won't work.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> All the while that you insist on lying about
>>>>>>>>>
>>>>>>>>> the verified fact that DD correctly simulated by
>>>>>>>>> HH cannot possibly stop running without having its
>>>>>>>>> simulation aborted by HH.
>>>>>>>>>
>>>>>>>>> You won't get to talk to me about anything else such
>>>>>>>>> as why the above statement matters.
>>>>>>>>>
>>>>>>>>> If you want to choose to be a liar thus <is> the
>>>>>>>>> consequence that you get.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>> ELSE HP is undecidable
>>>>>>>>
>>>>>>>> What is your answer? (the last time I saw POOH, it does not
>>>>>>>> report anything)
>>>>>>>>
>>>>>>>
>>>>>>> I incorporate by reference
>>>>>>> (a) The x86 language
>>>>>>> (b) The notion of an x86 emulator
>>>>>>>
>>>>>>> (c) I provide this complete function
>>>>>>>
>>>>>>> void DDD(int (*x)())
>>>>>>> {
>>>>>>> HH(x, x);
>>>>>>> }
>>>>>>>
>>>>>>> _DDD()
>>>>>>> [00001de2] 55 push ebp
>>>>>>> [00001de3] 8bec mov ebp,esp
>>>>>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>>>>>> [00001de8] 50 push eax ; push DD
>>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>>>>>> [00001dec] 51 push ecx ; push DD
>>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>>>>> [00001df2] 83c408 add esp,+08
>>>>>>> [00001df5] 5d pop ebp
>>>>>>> [00001df6] c3 ret
>>>>>>> Size in bytes:(0021) [00001df6]
>>>>>>>
>>>>>>> Then I state that No DDD correctly emulated by any
>>>>>>> x86 emulator H can possibly reach its own [00001df6]
>>>>>>> instruction.
>>>>>>>
>>>>>>> To anyone having this mandatory prerequisite knowledge
>>>>>>> (perhaps not you) every x86 emulation of DDD by any
>>>>>>> x86 emulator H continually repeats the first seven lines
>>>>>>> of DDD until it crashes due to out-of-memory error.
>>>>>>>
>>>>>>
>>>>>> The only reason being that HH, although required to halt, does not
>>>>>> halt, but calls DDD recursively until it is aborted.
>>>>>
>>>>> Try rereading this again and again until to understand and remember
>>>>> all of its words unless you fully intend to stay in rebuttal mode
>>>>> against the verified facts. In that case I will quit replying to
>>>>> your messages.
>>>>>
>>>>> <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 words10/13/2022>
>>>>
>>>> Don't only cite Sipser, but try to understand the words. Try to
>>>> think! If he really agreed about D, he would come to the same
>>>> conclusion for H.
>>>>
>>>> If simulating halt decider H correctly simulates its input H
>>>> (as part of D)
>>>> until H correctly determines that its simulated H would never
>>>> stop running unless aborted then
>>>>
>>>> H can abort its simulation of H and correctly report that H
>>>> specifies a non-halting sequence of configurations.
>>>>
>>>
>>> It is only that DD calls HH that makes the simulated HH not halt.
>>>
>>>
>>
>> With similar logic we can say that it is only HH that simulates DD
>> that makes the simulated DD not halt.
>>
>
> HH(DD,DD)==0 Please quit lying about this.
>
I never started, so it is impossible to quit.
HH(DD,DD)=0 means nothing else then that HH decides that 0 is the
correct answer for its procedure. This procedure involves the simulation
of HH (as part of DD).
It does not prove that DD(DD) halts, which would be a false negative.
You proved that HH, when used as a halting test, often has false negatives.
So, I repeat what you have cut out:
The fact is that HH and DD both keep creating new instances of each
other. If one of them would halt, the other one would halt as well. Your
claim is that HH halts. If so, then DD halts as well.
Try to think!
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 09:25 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41pk4$2kanc$16@dont-email.me> |
| In reply to | #106696 |
On 6/8/2024 9:19 AM, Fred. Zwarts wrote:
> Op 08.jun.2024 om 16:06 schreef olcott:
>> On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
>>> Op 08.jun.2024 om 15:50 schreef olcott:
>>>> On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
>>>>> Op 08.jun.2024 om 15:16 schreef olcott:
>>>>>> On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
>>>>>>> Op 08.jun.2024 om 14:20 schreef olcott:
>>>>>>>> On 6/7/2024 11:18 PM, wij wrote:
>>>>>>>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>>>>>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>>>>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>>>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That's a bit of sudden and substantial change, isn't
>>>>>>>>>>>>>>>>> it? Less than a
>>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>> days ago, you were defining a correct simulation as "1
>>>>>>>>>>>>>>>>> to N
>>>>>>>>>>>>>>>>> instructions"
>>>>>>>>>>>>>>>>> simulated (without ever specifying what you meant by
>>>>>>>>>>>>>>>>> N). It seems that
>>>>>>>>>>>>>>>>> the simulation of exactly one instruction would have
>>>>>>>>>>>>>>>>> met your criterion.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because I am a relatively terrible writer I must constantly
>>>>>>>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> More dishonest deflection.
>>>>>>>>>>>>>> The point that I made and you try to deflect using the
>>>>>>>>>>>>>> strawman
>>>>>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD
>>>>>>>>>>>>>> is correctly
>>>>>>>>>>>>>> simulated by HH and this is not the same behavior as the
>>>>>>>>>>>>>> directly
>>>>>>>>>>>>>> executed DD(DD).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Halting Problem asks for a program H (precisely a TM)
>>>>>>>>>>>>> that:
>>>>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>>>>>
>>>>>>>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Surrender to my GUR, son.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If people are going to be dishonest about simple things
>>>>>>>>>>>> such as the actual behavior of actual x86 code where
>>>>>>>>>>>> they consistently deny verified facts
>>>>>>>>>>>>
>>>>>>>>>>>> then we certainly cannot trust these people with more
>>>>>>>>>>>> difficult issues that require at least some slight degree
>>>>>>>>>>>> of judgment call.
>>>>>>>>>>>>
>>>>>>>>>>>> When we can show that even in the halting problem HH
>>>>>>>>>>>> is only required to report on the behavior of DD correctly
>>>>>>>>>>>> simulated by HH these dishonest people merely use that
>>>>>>>>>>>> as another deflection point for their dishonesty.
>>>>>>>>>>>>
>>>>>>>>>>>> The way around this that just worked is to stay diligently
>>>>>>>>>>>> focused one one single point until the dishonest people
>>>>>>>>>>>> finally admit that they have simply ignored all the proofs
>>>>>>>>>>>> for three solid years.
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>>>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>>>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>>>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>>>>>>>> >
>>>>>>>>>>>> > But, as I said, I won't acknowledge that you
>>>>>>>>>>>> > are correct, because I am not willing to put
>>>>>>>>>>>> > that effort into your worthless claim.
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the earliest version of the proof (that everyone
>>>>>>>>>>>> has simply ignored for three solid years) that P correctly
>>>>>>>>>>>> simulated by H would never stop running unless aborted.
>>>>>>>>>>>>
>>>>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that the execution trace of P derived by the executed
>>>>>>>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>>>>>>>> proves that each instruction of P was simulated correctly and
>>>>>>>>>>>> in the correct order this conclusively proves that P is
>>>>>>>>>>>> correctly
>>>>>>>>>>>> simulated by both of these instances of H.
>>>>>>>>>>>>
>>>>>>>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>>>>>>>> sure to ignore this proof so that they can maintain their false
>>>>>>>>>>>> assumption.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>
>>>>>>>>>>>> _DD()
>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>
>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I recalled now. You knew what the Halting Problem is. But
>>>>>>>>>>> soon, you started to insist
>>>>>>>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>>>>>>>> Wake up, your trick won't work.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> All the while that you insist on lying about
>>>>>>>>>>
>>>>>>>>>> the verified fact that DD correctly simulated by
>>>>>>>>>> HH cannot possibly stop running without having its
>>>>>>>>>> simulation aborted by HH.
>>>>>>>>>>
>>>>>>>>>> You won't get to talk to me about anything else such
>>>>>>>>>> as why the above statement matters.
>>>>>>>>>>
>>>>>>>>>> If you want to choose to be a liar thus <is> the
>>>>>>>>>> consequence that you get.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>
>>>>>>>>> What is your answer? (the last time I saw POOH, it does not
>>>>>>>>> report anything)
>>>>>>>>>
>>>>>>>>
>>>>>>>> I incorporate by reference
>>>>>>>> (a) The x86 language
>>>>>>>> (b) The notion of an x86 emulator
>>>>>>>>
>>>>>>>> (c) I provide this complete function
>>>>>>>>
>>>>>>>> void DDD(int (*x)())
>>>>>>>> {
>>>>>>>> HH(x, x);
>>>>>>>> }
>>>>>>>>
>>>>>>>> _DDD()
>>>>>>>> [00001de2] 55 push ebp
>>>>>>>> [00001de3] 8bec mov ebp,esp
>>>>>>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001de8] 50 push eax ; push DD
>>>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [00001dec] 51 push ecx ; push DD
>>>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>>>>>> [00001df2] 83c408 add esp,+08
>>>>>>>> [00001df5] 5d pop ebp
>>>>>>>> [00001df6] c3 ret
>>>>>>>> Size in bytes:(0021) [00001df6]
>>>>>>>>
>>>>>>>> Then I state that No DDD correctly emulated by any
>>>>>>>> x86 emulator H can possibly reach its own [00001df6]
>>>>>>>> instruction.
>>>>>>>>
>>>>>>>> To anyone having this mandatory prerequisite knowledge
>>>>>>>> (perhaps not you) every x86 emulation of DDD by any
>>>>>>>> x86 emulator H continually repeats the first seven lines
>>>>>>>> of DDD until it crashes due to out-of-memory error.
>>>>>>>>
>>>>>>>
>>>>>>> The only reason being that HH, although required to halt, does
>>>>>>> not halt, but calls DDD recursively until it is aborted.
>>>>>>
>>>>>> Try rereading this again and again until to understand and remember
>>>>>> all of its words unless you fully intend to stay in rebuttal mode
>>>>>> against the verified facts. In that case I will quit replying to
>>>>>> your messages.
>>>>>>
>>>>>> <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 words10/13/2022>
>>>>>
>>>>> Don't only cite Sipser, but try to understand the words. Try to
>>>>> think! If he really agreed about D, he would come to the same
>>>>> conclusion for H.
>>>>>
>>>>> If simulating halt decider H correctly simulates its input H
>>>>> (as part of D)
>>>>> until H correctly determines that its simulated H would never
>>>>> stop running unless aborted then
>>>>>
>>>>> H can abort its simulation of H and correctly report that H
>>>>> specifies a non-halting sequence of configurations.
>>>>>
>>>>
>>>> It is only that DD calls HH that makes the simulated HH not halt.
>>>>
>>>>
>>>
>>> With similar logic we can say that it is only HH that simulates DD
>>> that makes the simulated DD not halt.
>>>
>>
>> HH(DD,DD)==0 Please quit lying about this.
>>
>
> I never started, so it is impossible to quit.
> HH(DD,DD)=0 means nothing else then that HH decides that 0 is the
> correct answer for its procedure. This procedure involves the simulation
> of HH (as part of DD).
> It does not prove that DD(DD) halts, which would be a false negative.
> You proved that HH, when used as a halting test, often has false negatives.
>
> So, I repeat what you have cut out:
>
> The fact is that HH and DD both keep creating new instances of each
> other. If one of them would halt, the other one would halt as well. Your
> claim is that HH halts. If so, then DD halts as well.
> Try to think!
DD correctly determines that its own input DD would never
stop running unless aborted. It has no idea that the inner
HH is an instance of itself. HH merely recognizes the infinite
recursion behavior pattern.
--
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-08 16:36 +0200 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41q8s$2jt63$7@dont-email.me> |
| In reply to | #106699 |
Op 08.jun.2024 om 16:25 schreef olcott:
> On 6/8/2024 9:19 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 16:06 schreef olcott:
>>> On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
>>>> Op 08.jun.2024 om 15:50 schreef olcott:
>>>>> On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
>>>>>> Op 08.jun.2024 om 15:16 schreef olcott:
>>>>>>> On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
>>>>>>>> Op 08.jun.2024 om 14:20 schreef olcott:
>>>>>>>>> On 6/7/2024 11:18 PM, wij wrote:
>>>>>>>>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>>>>>>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>>>>>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>>>>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>>>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That's a bit of sudden and substantial change, isn't
>>>>>>>>>>>>>>>>>> it? Less than a
>>>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>>> days ago, you were defining a correct simulation as "1
>>>>>>>>>>>>>>>>>> to N
>>>>>>>>>>>>>>>>>> instructions"
>>>>>>>>>>>>>>>>>> simulated (without ever specifying what you meant by
>>>>>>>>>>>>>>>>>> N). It seems that
>>>>>>>>>>>>>>>>>> the simulation of exactly one instruction would have
>>>>>>>>>>>>>>>>>> met your criterion.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because I am a relatively terrible writer I must
>>>>>>>>>>>>>>>>> constantly
>>>>>>>>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> More dishonest deflection.
>>>>>>>>>>>>>>> The point that I made and you try to deflect using the
>>>>>>>>>>>>>>> strawman
>>>>>>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD
>>>>>>>>>>>>>>> is correctly
>>>>>>>>>>>>>>> simulated by HH and this is not the same behavior as the
>>>>>>>>>>>>>>> directly
>>>>>>>>>>>>>>> executed DD(DD).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The Halting Problem asks for a program H (precisely a TM)
>>>>>>>>>>>>>> that:
>>>>>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Surrender to my GUR, son.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If people are going to be dishonest about simple things
>>>>>>>>>>>>> such as the actual behavior of actual x86 code where
>>>>>>>>>>>>> they consistently deny verified facts
>>>>>>>>>>>>>
>>>>>>>>>>>>> then we certainly cannot trust these people with more
>>>>>>>>>>>>> difficult issues that require at least some slight degree
>>>>>>>>>>>>> of judgment call.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When we can show that even in the halting problem HH
>>>>>>>>>>>>> is only required to report on the behavior of DD correctly
>>>>>>>>>>>>> simulated by HH these dishonest people merely use that
>>>>>>>>>>>>> as another deflection point for their dishonesty.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The way around this that just worked is to stay diligently
>>>>>>>>>>>>> focused one one single point until the dishonest people
>>>>>>>>>>>>> finally admit that they have simply ignored all the proofs
>>>>>>>>>>>>> for three solid years.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>>>>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>>>>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>>>>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > But, as I said, I won't acknowledge that you
>>>>>>>>>>>>> > are correct, because I am not willing to put
>>>>>>>>>>>>> > that effort into your worthless claim.
>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the earliest version of the proof (that everyone
>>>>>>>>>>>>> has simply ignored for three solid years) that P correctly
>>>>>>>>>>>>> simulated by H would never stop running unless aborted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>> simulation
>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact that the execution trace of P derived by the executed
>>>>>>>>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>>>>>>>>> proves that each instruction of P was simulated correctly and
>>>>>>>>>>>>> in the correct order this conclusively proves that P is
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated by both of these instances of H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>>>>>>>>> sure to ignore this proof so that they can maintain their
>>>>>>>>>>>>> false
>>>>>>>>>>>>> assumption.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>>
>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>
>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I recalled now. You knew what the Halting Problem is. But
>>>>>>>>>>>> soon, you started to insist
>>>>>>>>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>>>>>>>>> Wake up, your trick won't work.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> All the while that you insist on lying about
>>>>>>>>>>>
>>>>>>>>>>> the verified fact that DD correctly simulated by
>>>>>>>>>>> HH cannot possibly stop running without having its
>>>>>>>>>>> simulation aborted by HH.
>>>>>>>>>>>
>>>>>>>>>>> You won't get to talk to me about anything else such
>>>>>>>>>>> as why the above statement matters.
>>>>>>>>>>>
>>>>>>>>>>> If you want to choose to be a liar thus <is> the
>>>>>>>>>>> consequence that you get.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>>
>>>>>>>>>> What is your answer? (the last time I saw POOH, it does not
>>>>>>>>>> report anything)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I incorporate by reference
>>>>>>>>> (a) The x86 language
>>>>>>>>> (b) The notion of an x86 emulator
>>>>>>>>>
>>>>>>>>> (c) I provide this complete function
>>>>>>>>>
>>>>>>>>> void DDD(int (*x)())
>>>>>>>>> {
>>>>>>>>> HH(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _DDD()
>>>>>>>>> [00001de2] 55 push ebp
>>>>>>>>> [00001de3] 8bec mov ebp,esp
>>>>>>>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001de8] 50 push eax ; push DD
>>>>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [00001dec] 51 push ecx ; push DD
>>>>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>>>>>>> [00001df2] 83c408 add esp,+08
>>>>>>>>> [00001df5] 5d pop ebp
>>>>>>>>> [00001df6] c3 ret
>>>>>>>>> Size in bytes:(0021) [00001df6]
>>>>>>>>>
>>>>>>>>> Then I state that No DDD correctly emulated by any
>>>>>>>>> x86 emulator H can possibly reach its own [00001df6]
>>>>>>>>> instruction.
>>>>>>>>>
>>>>>>>>> To anyone having this mandatory prerequisite knowledge
>>>>>>>>> (perhaps not you) every x86 emulation of DDD by any
>>>>>>>>> x86 emulator H continually repeats the first seven lines
>>>>>>>>> of DDD until it crashes due to out-of-memory error.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The only reason being that HH, although required to halt, does
>>>>>>>> not halt, but calls DDD recursively until it is aborted.
>>>>>>>
>>>>>>> Try rereading this again and again until to understand and remember
>>>>>>> all of its words unless you fully intend to stay in rebuttal mode
>>>>>>> against the verified facts. In that case I will quit replying to
>>>>>>> your messages.
>>>>>>>
>>>>>>> <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
>>>>>>> words10/13/2022>
>>>>>>
>>>>>> Don't only cite Sipser, but try to understand the words. Try to
>>>>>> think! If he really agreed about D, he would come to the same
>>>>>> conclusion for H.
>>>>>>
>>>>>> If simulating halt decider H correctly simulates its input H
>>>>>> (as part of D)
>>>>>> until H correctly determines that its simulated H would never
>>>>>> stop running unless aborted then
>>>>>>
>>>>>> H can abort its simulation of H and correctly report that H
>>>>>> specifies a non-halting sequence of configurations.
>>>>>>
>>>>>
>>>>> It is only that DD calls HH that makes the simulated HH not halt.
>>>>>
>>>>>
>>>>
>>>> With similar logic we can say that it is only HH that simulates DD
>>>> that makes the simulated DD not halt.
>>>>
>>>
>>> HH(DD,DD)==0 Please quit lying about this.
>>>
>>
>> I never started, so it is impossible to quit.
>> HH(DD,DD)=0 means nothing else then that HH decides that 0 is the
>> correct answer for its procedure. This procedure involves the
>> simulation of HH (as part of DD).
>> It does not prove that DD(DD) halts, which would be a false negative.
>> You proved that HH, when used as a halting test, often has false
>> negatives.
>>
>> So, I repeat what you have cut out:
>>
>> The fact is that HH and DD both keep creating new instances of each
>> other. If one of them would halt, the other one would halt as well.
>> Your claim is that HH halts. If so, then DD halts as well.
>> Try to think!
>
> DD correctly determines that its own input DD would never
> stop running unless aborted.
But it is aborted. We can not base conclusions on things that do not
happen.
> It has no idea that the inner
> HH is an instance of itself. HH merely recognizes the infinite
> recursion behavior pattern.
>
There is no infinite recursion behavior pattern, because HH aborts.
If there would be an infinite recursion behavior pattern that would
prove that HH would not meet its requirement that it must halt.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-08 09:59 -0500 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41rke$2l7o9$1@dont-email.me> |
| In reply to | #106702 |
On 6/8/2024 9:36 AM, Fred. Zwarts wrote:
> Op 08.jun.2024 om 16:25 schreef olcott:
>>
>> DD correctly determines that its own input DD would never
>> stop running unless aborted.
>
> But it is aborted. We can not base conclusions on things that do not
> happen.
>
We use a kind of backwards mathematical induction to prove
that a simulated input cannot possibly stop running.
We start with looking as what the behavior would be
when an infinite number of steps are correctly simulated.
We do this in a finite number of steps by matching
non-halting behavior patterns.
void Infinite_Recursion(u32 N)
{
Infinite_Recursion(N);
}
When we verify in a finite number of steps of correct
simulation that Infinite_Recursion cannot possibly
stop running without having its simulation aborted
then HH(Infinite_Recursion, (ptr)5); correctly reports
that Infinite_Recursion never halts.
Infinite_Recursion matches one of the non-halting
behavior patterns that HH has.
>> It has no idea that the inner
>> HH is an instance of itself. HH merely recognizes the infinite
>> recursion behavior pattern.
>>
> There is no infinite recursion behavior pattern, because HH aborts.
Whenever the input would never stop running unless aborted
then HH is correct to report that and ignore everything else
in the universe.
Most computer scientists don't pay enough attention to know
that halt deciders only compute the mapping from their inputs
on the basis of the behavior specified by these inputs.
I have never heard of any computer scientist that did not make
this mistake. Professor's Hehner and Stoddart are the only
one's in the whole world that I know of that have an actual
clue that something is wrong with the halting problem.
I found out about them on my phone when I was getting
chemotherapy on my birthday in 2022.
[1] E C R Hehner. Problems with the Halting Problem, COMPUTING2011
Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe
Germany, invited, 2011 October 20-21; Advances in Computer Science and
Engineering v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf
[2] E C R Hehner. Objective and Subjective Specifications
WST Workshop on Termination, Oxford. 2018 July 18.
See https://www.cs.toronto.edu/~hehner/OSS.pdf
[3] Bill Stoddart. The Halting Paradox
20 December 2017
https://arxiv.org/abs/1906.05340
arXiv:1906.05340 [cs.LO]
> If there would be an infinite recursion behavior pattern that would
> prove that HH would not meet its requirement that it must halt.
--
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-08 11:09 -0400 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41s6k$3cg3s$7@i2pn2.org> |
| In reply to | #106708 |
On 6/8/24 10:59 AM, olcott wrote:
> On 6/8/2024 9:36 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 16:25 schreef olcott:
>>>
>>> DD correctly determines that its own input DD would never
>>> stop running unless aborted.
>>
>> But it is aborted. We can not base conclusions on things that do not
>> happen.
>>
>
> We use a kind of backwards mathematical induction to prove
> that a simulated input cannot possibly stop running.
>
> We start with looking as what the behavior would be
> when an infinite number of steps are correctly simulated.
>
> We do this in a finite number of steps by matching
> non-halting behavior patterns.
>
> void Infinite_Recursion(u32 N)
> {
> Infinite_Recursion(N);
> }
>
> When we verify in a finite number of steps of correct
> simulation that Infinite_Recursion cannot possibly
> stop running without having its simulation aborted
> then HH(Infinite_Recursion, (ptr)5); correctly reports
> that Infinite_Recursion never halts.
>
> Infinite_Recursion matches one of the non-halting
> behavior patterns that HH has.
But you can't do induction back from infinity.
Please try to show a repected source that talks about doing it that way.
You need to do induction FORWARDS for it to be valid.
>
>>> It has no idea that the inner
>>> HH is an instance of itself. HH merely recognizes the infinite
>>> recursion behavior pattern.
>>>
>> There is no infinite recursion behavior pattern, because HH aborts.
>
> Whenever the input would never stop running unless aborted
> then HH is correct to report that and ignore everything else
> in the universe.
Nope, using the wrong definition.
Note, the input needs to be a PROGRAM, and thus a specific instance. If
that instance is based on an decider that aborts and returns 0, then
that instance, when examained properly, will be seen to eventually halt
when run, which is what Halting is DEFINED to look at.
>
> Most computer scientists don't pay enough attention to know
> that halt deciders only compute the mapping from their inputs
> on the basis of the behavior specified by these inputs.
And you fail to notice that the "behavior specified by these inputs",
for a Halt Decider, is DEFINED by the behavior of the actual machine the
input represents, or equivalently, but the behavior of a UTM simulation,
which by definition, doesn't stop simulating until it gets to a final
state. This is the criteria even if the decider doesn't simulate that
far, the criteria does.
Since, given an HH(DD,DD) that returns 0, we have DD(DD) Halts, as will
UTM(DD,DD) we se that the answer for HH is just incorrect.
Your other opetion, that HH(DD,DD) doesn't abort its simulation, just
ends up with an HH that isn't a decider, so the behavior of DD doesn't
matter, it just did its job by breaking HH.
>
> I have never heard of any computer scientist that did not make
> this mistake. Professor's Hehner and Stoddart are the only
> one's in the whole world that I know of that have an actual
> clue that something is wrong with the halting problem.
Because you are stuck in a mistake of understanding the problem, and you
found a couple of people who did the same mistake.
>
> I found out about them on my phone when I was getting
> chemotherapy on my birthday in 2022.
>
> [1] E C R Hehner. Problems with the Halting Problem, COMPUTING2011
> Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe
> Germany, invited, 2011 October 20-21; Advances in Computer Science and
> Engineering v.10 n.1 p.31-60, 2013
> https://www.cs.toronto.edu/~hehner/PHP.pdf
>
> [2] E C R Hehner. Objective and Subjective Specifications
> WST Workshop on Termination, Oxford. 2018 July 18.
> See https://www.cs.toronto.edu/~hehner/OSS.pdf
>
> [3] Bill Stoddart. The Halting Paradox
> 20 December 2017
> https://arxiv.org/abs/1906.05340
> arXiv:1906.05340 [cs.LO]
>
>
>
>> If there would be an infinite recursion behavior pattern that would
>> prove that HH would not meet its requirement that it must halt.
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-08 10:44 -0400 |
| Subject | Re: At least 100 people kept denying the easily verified fact --- last communication with Richard |
| Message-ID | <v41qok$3cg3s$5@i2pn2.org> |
| In reply to | #106699 |
On 6/8/24 10:25 AM, olcott wrote:
> On 6/8/2024 9:19 AM, Fred. Zwarts wrote:
>> Op 08.jun.2024 om 16:06 schreef olcott:
>>> On 6/8/2024 9:01 AM, Fred. Zwarts wrote:
>>>> Op 08.jun.2024 om 15:50 schreef olcott:
>>>>> On 6/8/2024 8:38 AM, Fred. Zwarts wrote:
>>>>>> Op 08.jun.2024 om 15:16 schreef olcott:
>>>>>>> On 6/8/2024 7:41 AM, Fred. Zwarts wrote:
>>>>>>>> Op 08.jun.2024 om 14:20 schreef olcott:
>>>>>>>>> On 6/7/2024 11:18 PM, wij wrote:
>>>>>>>>>> On Fri, 2024-06-07 at 15:01 -0500, olcott wrote:
>>>>>>>>>>> On 6/7/2024 2:43 PM, wij wrote:
>>>>>>>>>>>> On Fri, 2024-06-07 at 14:31 -0500, olcott wrote:
>>>>>>>>>>>>> On 6/7/2024 1:57 PM, wij wrote:
>>>>>>>>>>>>>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>>>>>>> [ Followup-To: set ]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [ .... ]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That's a bit of sudden and substantial change, isn't
>>>>>>>>>>>>>>>>>> it? Less than a
>>>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>>> days ago, you were defining a correct simulation as "1
>>>>>>>>>>>>>>>>>> to N
>>>>>>>>>>>>>>>>>> instructions"
>>>>>>>>>>>>>>>>>> simulated (without ever specifying what you meant by
>>>>>>>>>>>>>>>>>> N). It seems that
>>>>>>>>>>>>>>>>>> the simulation of exactly one instruction would have
>>>>>>>>>>>>>>>>>> met your criterion.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That now seems to have changed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because I am a relatively terrible writer I must
>>>>>>>>>>>>>>>>> constantly
>>>>>>>>>>>>>>>>> improve my words on the basis of reviews.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And thus you admit that HH is not a Halt Decider,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> More dishonest deflection.
>>>>>>>>>>>>>>> The point that I made and you try to deflect using the
>>>>>>>>>>>>>>> strawman
>>>>>>>>>>>>>>> deception as a fake rebuttal is the I just proved that DD
>>>>>>>>>>>>>>> is correctly
>>>>>>>>>>>>>>> simulated by HH and this is not the same behavior as the
>>>>>>>>>>>>>>> directly
>>>>>>>>>>>>>>> executed DD(DD).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The Halting Problem asks for a program H (precisely a TM)
>>>>>>>>>>>>>> that:
>>>>>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You keep solving POOH !!! and made lots of lies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Surrender to my GUR, son.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If people are going to be dishonest about simple things
>>>>>>>>>>>>> such as the actual behavior of actual x86 code where
>>>>>>>>>>>>> they consistently deny verified facts
>>>>>>>>>>>>>
>>>>>>>>>>>>> then we certainly cannot trust these people with more
>>>>>>>>>>>>> difficult issues that require at least some slight degree
>>>>>>>>>>>>> of judgment call.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When we can show that even in the halting problem HH
>>>>>>>>>>>>> is only required to report on the behavior of DD correctly
>>>>>>>>>>>>> simulated by HH these dishonest people merely use that
>>>>>>>>>>>>> as another deflection point for their dishonesty.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The way around this that just worked is to stay diligently
>>>>>>>>>>>>> focused one one single point until the dishonest people
>>>>>>>>>>>>> finally admit that they have simply ignored all the proofs
>>>>>>>>>>>>> for three solid years.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/5/2024 10:58 PM, Richard Damon wrote:
>>>>>>>>>>>>> > On 6/5/24 11:44 PM, olcott wrote:
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>>>>>>>>>>>>> >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>>>>>>>>>>>>> >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > But, as I said, I won't acknowledge that you
>>>>>>>>>>>>> > are correct, because I am not willing to put
>>>>>>>>>>>>> > that effort into your worthless claim.
>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is the earliest version of the proof (that everyone
>>>>>>>>>>>>> has simply ignored for three solid years) that P correctly
>>>>>>>>>>>>> simulated by H would never stop running unless aborted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>> simulation
>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact that the execution trace of P derived by the executed
>>>>>>>>>>>>> H and the simulated H exactly matches the machine code of P
>>>>>>>>>>>>> proves that each instruction of P was simulated correctly and
>>>>>>>>>>>>> in the correct order this conclusively proves that P is
>>>>>>>>>>>>> correctly
>>>>>>>>>>>>> simulated by both of these instances of H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It has proved this since 2021-09-26 and everyone has made
>>>>>>>>>>>>> sure to ignore this proof so that they can maintain their
>>>>>>>>>>>>> false
>>>>>>>>>>>>> assumption.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>>>>>>>>>> stops running without having its simulation aborted by HH.
>>>>>>>>>>>>>
>>>>>>>>>>>>> _DD()
>>>>>>>>>>>>> [00001e12] 55 push ebp
>>>>>>>>>>>>> [00001e13] 8bec mov ebp,esp
>>>>>>>>>>>>> [00001e15] 51 push ecx
>>>>>>>>>>>>> [00001e16] 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>> [00001e19] 50 push eax ; push DD
>>>>>>>>>>>>> [00001e1a] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>> [00001e1d] 51 push ecx ; push DD
>>>>>>>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>>>>>>>>
>>>>>>>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>>>>>>>> by HH and simulated in the correct order.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyone claiming that HH should report on the behavior
>>>>>>>>>>>>> of the directly executed DD(DD) is requiring a violation
>>>>>>>>>>>>> of the above definition of correct simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I recalled now. You knew what the Halting Problem is. But
>>>>>>>>>>>> soon, you started to insist
>>>>>>>>>>>> POOH is correct by fabricating ...(lots of things)...
>>>>>>>>>>>> Wake up, your trick won't work.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> All the while that you insist on lying about
>>>>>>>>>>>
>>>>>>>>>>> the verified fact that DD correctly simulated by
>>>>>>>>>>> HH cannot possibly stop running without having its
>>>>>>>>>>> simulation aborted by HH.
>>>>>>>>>>>
>>>>>>>>>>> You won't get to talk to me about anything else such
>>>>>>>>>>> as why the above statement matters.
>>>>>>>>>>>
>>>>>>>>>>> If you want to choose to be a liar thus <is> the
>>>>>>>>>>> consequence that you get.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The Halting Problem asks for a program H (precisely a TM) that:
>>>>>>>>>> IF H(D,D)==1, THEN D(D) will return.
>>>>>>>>>> ELSE If H(D,D)==0, THEN D(D) will never return.
>>>>>>>>>> ELSE HP is undecidable
>>>>>>>>>>
>>>>>>>>>> What is your answer? (the last time I saw POOH, it does not
>>>>>>>>>> report anything)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I incorporate by reference
>>>>>>>>> (a) The x86 language
>>>>>>>>> (b) The notion of an x86 emulator
>>>>>>>>>
>>>>>>>>> (c) I provide this complete function
>>>>>>>>>
>>>>>>>>> void DDD(int (*x)())
>>>>>>>>> {
>>>>>>>>> HH(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _DDD()
>>>>>>>>> [00001de2] 55 push ebp
>>>>>>>>> [00001de3] 8bec mov ebp,esp
>>>>>>>>> [00001de5] 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001de8] 50 push eax ; push DD
>>>>>>>>> [00001de9] 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [00001dec] 51 push ecx ; push DD
>>>>>>>>> [00001ded] e890f5ffff call 00001382 ; call HH
>>>>>>>>> [00001df2] 83c408 add esp,+08
>>>>>>>>> [00001df5] 5d pop ebp
>>>>>>>>> [00001df6] c3 ret
>>>>>>>>> Size in bytes:(0021) [00001df6]
>>>>>>>>>
>>>>>>>>> Then I state that No DDD correctly emulated by any
>>>>>>>>> x86 emulator H can possibly reach its own [00001df6]
>>>>>>>>> instruction.
>>>>>>>>>
>>>>>>>>> To anyone having this mandatory prerequisite knowledge
>>>>>>>>> (perhaps not you) every x86 emulation of DDD by any
>>>>>>>>> x86 emulator H continually repeats the first seven lines
>>>>>>>>> of DDD until it crashes due to out-of-memory error.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The only reason being that HH, although required to halt, does
>>>>>>>> not halt, but calls DDD recursively until it is aborted.
>>>>>>>
>>>>>>> Try rereading this again and again until to understand and remember
>>>>>>> all of its words unless you fully intend to stay in rebuttal mode
>>>>>>> against the verified facts. In that case I will quit replying to
>>>>>>> your messages.
>>>>>>>
>>>>>>> <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
>>>>>>> words10/13/2022>
>>>>>>
>>>>>> Don't only cite Sipser, but try to understand the words. Try to
>>>>>> think! If he really agreed about D, he would come to the same
>>>>>> conclusion for H.
>>>>>>
>>>>>> If simulating halt decider H correctly simulates its input H
>>>>>> (as part of D)
>>>>>> until H correctly determines that its simulated H would never
>>>>>> stop running unless aborted then
>>>>>>
>>>>>> H can abort its simulation of H and correctly report that H
>>>>>> specifies a non-halting sequence of configurations.
>>>>>>
>>>>>
>>>>> It is only that DD calls HH that makes the simulated HH not halt.
>>>>>
>>>>>
>>>>
>>>> With similar logic we can say that it is only HH that simulates DD
>>>> that makes the simulated DD not halt.
>>>>
>>>
>>> HH(DD,DD)==0 Please quit lying about this.
>>>
>>
>> I never started, so it is impossible to quit.
>> HH(DD,DD)=0 means nothing else then that HH decides that 0 is the
>> correct answer for its procedure. This procedure involves the
>> simulation of HH (as part of DD).
>> It does not prove that DD(DD) halts, which would be a false negative.
>> You proved that HH, when used as a halting test, often has false
>> negatives.
>>
>> So, I repeat what you have cut out:
>>
>> The fact is that HH and DD both keep creating new instances of each
>> other. If one of them would halt, the other one would halt as well.
>> Your claim is that HH halts. If so, then DD halts as well.
>> Try to think!
>
> DD correctly determines that its own input DD would never
> stop running unless aborted. It has no idea that the inner
> HH is an instance of itself. HH merely recognizes the infinite
> recursion behavior pattern.
>
DD isn't required to "decide" anything, its job is to make HH wrong.
The HH that DD uses, as ALL HH must do, is required to determine if its
input represents a Halting Computation. If HH recognizes the infinite
recursion behavior pattern, the it isn't there as the HH that DD calls
will so that and break the pattern and return.
Thus HH can't get the correct answer, and can't be a correct halt
decider for this input.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.theory
csiph-web