Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.logic > #334663 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-05-28 11:16 -0500 |
| Last post | 2024-05-30 21:37 -0400 |
| Articles | 20 on this page of 254 — 13 participants |
Back to article view | Back to sci.logic
D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 11:16 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-28 22:04 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 21:23 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-28 23:38 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 22:49 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 07:31 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 08:49 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Alan Mackenzie <acm@muc.de> - 2024-05-29 15:40 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 11:21 -0500
Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 13:31 -0500
Re: Two dozen people were simply wrong Alan Mackenzie <acm@muc.de> - 2024-05-29 20:17 +0000
Re: Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 15:26 -0500
Re: Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 16:14 -0500
Re: Two dozen people were simply wrong (including Olcott) Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 18:57 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 20:09 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 19:17 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 20:48 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 19:59 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 21:07 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:15 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 21:24 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:24 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:48 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 21:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:55 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 22:58 -0500
Re: Olcott was simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 07:30 -0400
Re: Olcott was simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 09:04 -0500
Re: Olcott was simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 20:54 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 22:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 21:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 22:51 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 21:58 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 23:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 22:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 09:10 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 17:36 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 17:08 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 18:46 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 17:54 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 19:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 18:57 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 20:39 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 20:10 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 21:35 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 21:08 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 22:25 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 21:40 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 07:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:30 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:56 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 18:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:24 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 20:40 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:44 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 21:04 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:11 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 10:56 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:02 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 14:20 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:38 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 12:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 12:44 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:56 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:07 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 14:21 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:31 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 14:43 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:46 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:58 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 15:03 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:23 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 16:35 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 14:51 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 16:29 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 17:13 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 16:24 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 18:30 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 17:40 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 19:02 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 18:12 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down wij <wyniijj5@gmail.com> - 2024-06-02 07:25 +0800
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down wij <wyniijj5@gmail.com> - 2024-06-02 07:26 +0800
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 19:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 22:33 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 07:51 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:19 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 12:59 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 14:13 -0400
DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 13:29 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 15:05 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 14:13 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <Richard@Damon-Family.org> - 2024-06-02 15:22 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 14:34 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:11 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 15:21 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:32 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD immibis <news@immibis.com> - 2024-06-03 02:14 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 15:50 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:58 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 16:25 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 17:43 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 17:05 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 18:20 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 17:44 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 19:45 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 20:45 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 22:24 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 21:54 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 23:13 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 22:20 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 10:10 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-03 07:46 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:49 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-03 07:14 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-03 07:42 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:51 +0200
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:34 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Mikko <mikko.levanto@iki.fi> - 2024-06-03 10:33 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down wij <wyniijj5@gmail.com> - 2024-06-02 07:29 +0800
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:13 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:03 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:41 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:13 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:53 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:59 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 15:07 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:55 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:53 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 20:26 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 14:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 11:01 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Wasell <wasell@example.com> - 2024-06-01 10:36 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 09:00 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:46 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:58 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:08 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 11:18 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 12:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 11:46 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 16:29 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 15:35 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 17:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 16:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 18:30 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 17:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 19:02 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:24 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 09:47 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:24 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 13:39 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:55 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 14:01 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 09:50 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-02 14:59 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical immibis <news@immibis.com> - 2024-06-02 21:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical immibis <news@immibis.com> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 10:57 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:17 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:32 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:51 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:02 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 18:06 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:22 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:34 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 19:12 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:52 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:49 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 14:48 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-06-04 12:46 -0500
Re: Two dozen people were simply wrong immibis <news@immibis.com> - 2024-05-30 12:04 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years olcott <polcott333@gmail.com> - 2024-06-01 10:09 -0500
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:18 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years olcott <polcott333@gmail.com> - 2024-06-01 10:44 -0500
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:58 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years immibis <news@immibis.com> - 2024-06-01 20:51 +0200
Re: Deciders are ONLY accountable for their actual inputs --- immibis <news@immibis.com> - 2024-06-02 21:20 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:01 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 20:09 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:21 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 20:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:53 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 21:02 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 20:12 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 21:25 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 20:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 22:25 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 21:36 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 22:55 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 22:48 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-05-30 12:11 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-30 07:33 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-30 07:32 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 09:43 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 15:59 +0100
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 10:21 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 17:13 +0100
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 11:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 21:51 +0100
Re: D correctly simulated by H cannot possibly halt --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 16:22 -0500
Re: D correctly simulated by H cannot possibly halt --- Try to prove otherwise immibis <news@immibis.com> - 2024-05-30 23:50 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- Mike Terry olcott <polcott333@gmail.com> - 2024-05-31 09:46 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 17:20 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 10:30 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 17:58 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 12:00 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 20:50 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 14:01 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 21:32 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 15:15 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 22:59 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 16:27 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders immibis <news@immibis.com> - 2024-05-30 23:51 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:10 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 22:33 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Jeff Barnett <jbb@notatt.com> - 2024-05-30 21:48 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:52 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 23:06 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders immibis <news@immibis.com> - 2024-05-31 10:41 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:14 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 22:36 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-31 10:02 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-31 09:33 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:23 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders joes <noreply@example.com> - 2024-06-01 18:07 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-06-01 13:11 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-06-01 14:23 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-02 20:13 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3icns$3f51j$2@dont-email.me> |
| In reply to | #334908 |
Op 02.jun.2024 om 16:41 schreef olcott:
> On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
>> Op 01.jun.2024 om 21:51 schreef olcott:
>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *I will not discuss any other points with you until after
>>>>>>>>>>>>>>> you either*
>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩
>>>>>>>>>>>>>>> ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>> 08
>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite set
>>>>>>>>>>>>> of HH/DD
>>>>>>>>>>>>> pairs that match the above template never reaches past its
>>>>>>>>>>>>> own simulated
>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In this case HH is either a pure simulator that never halts or
>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>> finite number
>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>> variable.
>>>>>>>>>>>>> The pure function HH always returns the meaningless value
>>>>>>>>>>>>> of 56
>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>
>>>>>>>>>>> You can pretend that you don't understand something that you
>>>>>>>>>>> do indeed
>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>
>>>>>>>>>>> The key measure of dishonestly would be that you continue to say
>>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>>> what you
>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>
>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are asking,
>>>>>>>>>>>> though it seems that now you are admitting that your HH
>>>>>>>>>>>> doesn't actually ANSWER the question, so it isn't ACTUALL a
>>>>>>>>>>>> decider for any function except the "56" mapping.
>>>>>>>>>>>>
>>>>>>>>>>>> I will repeat the question and until you answer the question
>>>>>>>>>>>> of what that actually means, I will reply WHO CARES.
>>>>>>>>>>>>
>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>
>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what I
>>>>>>>>>>> specified*
>>>>>>>>>>>
>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have no
>>>>>>>>>>>> code past point to simulate, and thus your claim is just a LIE.
>>>>>>>>>>>>
>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>>> instance of DD, at which point we never have the 1 to
>>>>>>>>>>>> infinte number of simulatons of THAT INPUT, so your claim is
>>>>>>>>>>>> just a LIE.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>
>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>
>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why? I don't care about it.
>>>>>>>>
>>>>>>>> As I have said, the implication of your definition of "Correct
>>>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>>>> behavior of DD. (only not halted yet)
>>>>>>>>
>>>>>>>
>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>
>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>
>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>> something that is clearly meaningless.
>>>>>>
>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>> only ever be simulated by ONE given HH that only simuates for one
>>>>>> number of steps.
>>>>>>
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>> 00 int HH(ptr p, ptr i);
>>>>> 01 int DD(ptr p)
>>>>> 02 {
>>>>> 03 int Halt_Status = HH(p, p);
>>>>> 04 if (Halt_Status)
>>>>> 05 HERE: goto HERE;
>>>>> 06 return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 int main()
>>>>> 10 {
>>>>> 11 HH(DD,DD);
>>>>> 12 return 0;
>>>>> 13 }
>>>>>
>>>>> You continue to either fail to understand or seemingly more likely
>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>> HH that can possibly exist cannot possibly reach past its own line 03.
>>>>
>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>> return, otherwise the simulation of DD would go to line 04.
>>>>
>>>>>
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>
>>>>
>>>> If true: The input to HH is both DD and HH called by DD, so both DD
>>>> and HH do not halt, but keep starting new instances of each other.
>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>> halts is phantasy.
>>>
>>> I have fully operational code that proves otherwise.
>>
>> But you are unable to show the ret instruction of HH simulated by
>> itself. So, the proof is missing the crucial part.
>>
>>
>>> Any expert in the C programming language knows the
>>> same thing from the C source-code.
>>>
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 HH(DD,DD);
> 12 return 0;
> 13 }
>
>> You don't need to be an expert in C to see that if the simulated HH
>> would halt, then DD would continue to line 04.
>
> *Try and show how that can happen*
If you show how HH simulated by HH reaches its return and show the next
10 instructions. You can't and therefore we know the simulated HH does
not halt and the non-halting HH is the reason that DD does not continue.
> *You may simply lack the required prerequisite knowledge >
> DD correctly emulated by HH with an x86 emulator cannot possibly
> reach past its own machine instruction [00001c2e] in any finite
> (or infinite) number of steps of correct emulation.
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
It could if HH were a halting function as required. Then the call at
[00001c2e] would return and the next instruction would be reachable. The
reason that it is not, is that HH does not return.
(You don't need to show your x86 code. Is does not show more than the C
code.)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-02 13:32 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3idr5$3f571$3@dont-email.me> |
| In reply to | #334919 |
On 6/2/2024 1:13 PM, Fred. Zwarts wrote:
> Op 02.jun.2024 om 16:41 schreef olcott:
>> On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
>>> Op 01.jun.2024 om 21:51 schreef olcott:
>>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *I will not discuss any other points with you until
>>>>>>>>>>>>>>>> after you either*
>>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and
>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite set
>>>>>>>>>>>>>> of HH/DD
>>>>>>>>>>>>>> pairs that match the above template never reaches past its
>>>>>>>>>>>>>> own simulated
>>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In this case HH is either a pure simulator that never
>>>>>>>>>>>>>> halts or
>>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>>> finite number
>>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>>> variable.
>>>>>>>>>>>>>> The pure function HH always returns the meaningless value
>>>>>>>>>>>>>> of 56
>>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>>
>>>>>>>>>>>> You can pretend that you don't understand something that you
>>>>>>>>>>>> do indeed
>>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>>
>>>>>>>>>>>> The key measure of dishonestly would be that you continue to
>>>>>>>>>>>> say
>>>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>>>> what you
>>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>>
>>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are asking,
>>>>>>>>>>>>> though it seems that now you are admitting that your HH
>>>>>>>>>>>>> doesn't actually ANSWER the question, so it isn't ACTUALL a
>>>>>>>>>>>>> decider for any function except the "56" mapping.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will repeat the question and until you answer the
>>>>>>>>>>>>> question of what that actually means, I will reply WHO CARES.
>>>>>>>>>>>>>
>>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>>
>>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what I
>>>>>>>>>>>> specified*
>>>>>>>>>>>>
>>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have
>>>>>>>>>>>>> no code past point to simulate, and thus your claim is just
>>>>>>>>>>>>> a LIE.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>>>> instance of DD, at which point we never have the 1 to
>>>>>>>>>>>>> infinte number of simulatons of THAT INPUT, so your claim
>>>>>>>>>>>>> is just a LIE.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>
>>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>>
>>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why? I don't care about it.
>>>>>>>>>
>>>>>>>>> As I have said, the implication of your definition of "Correct
>>>>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>>>>> behavior of DD. (only not halted yet)
>>>>>>>>>
>>>>>>>>
>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>>
>>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>>
>>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>>> something that is clearly meaningless.
>>>>>>>
>>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>>> only ever be simulated by ONE given HH that only simuates for one
>>>>>>> number of steps.
>>>>>>>
>>>>>>
>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>> 00 int HH(ptr p, ptr i);
>>>>>> 01 int DD(ptr p)
>>>>>> 02 {
>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>> 04 if (Halt_Status)
>>>>>> 05 HERE: goto HERE;
>>>>>> 06 return Halt_Status;
>>>>>> 07 }
>>>>>> 08
>>>>>> 09 int main()
>>>>>> 10 {
>>>>>> 11 HH(DD,DD);
>>>>>> 12 return 0;
>>>>>> 13 }
>>>>>>
>>>>>> You continue to either fail to understand or seemingly more likely
>>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>>> HH that can possibly exist cannot possibly reach past its own line
>>>>>> 03.
>>>>>
>>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>>> return, otherwise the simulation of DD would go to line 04.
>>>>>
>>>>>>
>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>
>>>>>
>>>>> If true: The input to HH is both DD and HH called by DD, so both DD
>>>>> and HH do not halt, but keep starting new instances of each other.
>>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>>> halts is phantasy.
>>>>
>>>> I have fully operational code that proves otherwise.
>>>
>>> But you are unable to show the ret instruction of HH simulated by
>>> itself. So, the proof is missing the crucial part.
>>>
>>>
>>>> Any expert in the C programming language knows the
>>>> same thing from the C source-code.
>>>>
>>>
>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C
>> 00 int HH(ptr p, ptr i);
>> 01 int DD(ptr p)
>> 02 {
>> 03 int Halt_Status = HH(p, p);
>> 04 if (Halt_Status)
>> 05 HERE: goto HERE;
>> 06 return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11 HH(DD,DD);
>> 12 return 0;
>> 13 }
>>
>>> You don't need to be an expert in C to see that if the simulated HH
>>> would halt, then DD would continue to line 04.
>>
>> *Try and show how that can happen*
>
> If you show how HH simulated by HH reaches its return and show the next
> 10 instructions. You can't and therefore we know the simulated HH does
> not halt and the non-halting HH is the reason that DD does not continue.
>
>> *You may simply lack the required prerequisite knowledge >
>> DD correctly emulated by HH with an x86 emulator cannot possibly
>> reach past its own machine instruction [00001c2e] in any finite
>> (or infinite) number of steps of correct emulation.
>>
>> _DD()
>> [00001c22] 55 push ebp
>> [00001c23] 8bec mov ebp,esp
>> [00001c25] 51 push ecx
>> [00001c26] 8b4508 mov eax,[ebp+08]
>> [00001c29] 50 push eax ; push DD 1c22
>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>> [00001c2d] 51 push ecx ; push DD 1c22
>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>> [00001c33] 83c408 add esp,+08
>> [00001c36] 8945fc mov [ebp-04],eax
>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>> [00001c3d] 7402 jz 00001c41
>> [00001c3f] ebfe jmp 00001c3f
>> [00001c41] 8b45fc mov eax,[ebp-04]
>> [00001c44] 8be5 mov esp,ebp
>> [00001c46] 5d pop ebp
>> [00001c47] c3 ret
>> Size in bytes:(0038) [00001c47]
>
> It could if HH were a halting function as required. Then the call at
> [00001c2e] would return and the next instruction would be reachable. The
> reason that it is not, is that HH does not return.
>
> (You don't need to show your x86 code. Is does not show more than the C
> code.)
You simply fail to comprehend that recursive simulation is isomorphic
to infinite recursion. That may be because you may have no idea what
infinite recursion is.
--
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-02 20:49 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3ierl$3f51j$8@dont-email.me> |
| In reply to | #334924 |
Op 02.jun.2024 om 20:32 schreef olcott:
> On 6/2/2024 1:13 PM, Fred. Zwarts wrote:
>> Op 02.jun.2024 om 16:41 schreef olcott:
>>> On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
>>>> Op 01.jun.2024 om 21:51 schreef olcott:
>>>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *I will not discuss any other points with you until
>>>>>>>>>>>>>>>>> after you either*
>>>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and
>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>>> in C
>>>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite
>>>>>>>>>>>>>>> set of HH/DD
>>>>>>>>>>>>>>> pairs that match the above template never reaches past
>>>>>>>>>>>>>>> its own simulated
>>>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In this case HH is either a pure simulator that never
>>>>>>>>>>>>>>> halts or
>>>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>>>> finite number
>>>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>>>> variable.
>>>>>>>>>>>>>>> The pure function HH always returns the meaningless value
>>>>>>>>>>>>>>> of 56
>>>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can pretend that you don't understand something that
>>>>>>>>>>>>> you do indeed
>>>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The key measure of dishonestly would be that you continue
>>>>>>>>>>>>> to say
>>>>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>>>>> what you
>>>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are
>>>>>>>>>>>>>> asking, though it seems that now you are admitting that
>>>>>>>>>>>>>> your HH doesn't actually ANSWER the question, so it isn't
>>>>>>>>>>>>>> ACTUALL a decider for any function except the "56" mapping.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will repeat the question and until you answer the
>>>>>>>>>>>>>> question of what that actually means, I will reply WHO CARES.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what
>>>>>>>>>>>>> I specified*
>>>>>>>>>>>>>
>>>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have
>>>>>>>>>>>>>> no code past point to simulate, and thus your claim is
>>>>>>>>>>>>>> just a LIE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>>>>> instance of DD, at which point we never have the 1 to
>>>>>>>>>>>>>> infinte number of simulatons of THAT INPUT, so your claim
>>>>>>>>>>>>>> is just a LIE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>>>
>>>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Why? I don't care about it.
>>>>>>>>>>
>>>>>>>>>> As I have said, the implication of your definition of "Correct
>>>>>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>>>>>> behavior of DD. (only not halted yet)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>>>
>>>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>>>
>>>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>>>> something that is clearly meaningless.
>>>>>>>>
>>>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>>>> only ever be simulated by ONE given HH that only simuates for
>>>>>>>> one number of steps.
>>>>>>>>
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>> 01 int DD(ptr p)
>>>>>>> 02 {
>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>> 04 if (Halt_Status)
>>>>>>> 05 HERE: goto HERE;
>>>>>>> 06 return Halt_Status;
>>>>>>> 07 }
>>>>>>> 08
>>>>>>> 09 int main()
>>>>>>> 10 {
>>>>>>> 11 HH(DD,DD);
>>>>>>> 12 return 0;
>>>>>>> 13 }
>>>>>>>
>>>>>>> You continue to either fail to understand or seemingly more likely
>>>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>>>> HH that can possibly exist cannot possibly reach past its own
>>>>>>> line 03.
>>>>>>
>>>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>>>> return, otherwise the simulation of DD would go to line 04.
>>>>>>
>>>>>>>
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>
>>>>>>
>>>>>> If true: The input to HH is both DD and HH called by DD, so both
>>>>>> DD and HH do not halt, but keep starting new instances of each other.
>>>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>>>> halts is phantasy.
>>>>>
>>>>> I have fully operational code that proves otherwise.
>>>>
>>>> But you are unable to show the ret instruction of HH simulated by
>>>> itself. So, the proof is missing the crucial part.
>>>>
>>>>
>>>>> Any expert in the C programming language knows the
>>>>> same thing from the C source-code.
>>>>>
>>>>
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int HH(ptr p, ptr i);
>>> 01 int DD(ptr p)
>>> 02 {
>>> 03 int Halt_Status = HH(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11 HH(DD,DD);
>>> 12 return 0;
>>> 13 }
>>>
>>>> You don't need to be an expert in C to see that if the simulated HH
>>>> would halt, then DD would continue to line 04.
>>>
>>> *Try and show how that can happen*
>>
>> If you show how HH simulated by HH reaches its return and show the
>> next 10 instructions. You can't and therefore we know the simulated HH
>> does not halt and the non-halting HH is the reason that DD does not
>> continue.
>>
>>> *You may simply lack the required prerequisite knowledge >
>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>> reach past its own machine instruction [00001c2e] in any finite
>>> (or infinite) number of steps of correct emulation.
>>>
>>> _DD()
>>> [00001c22] 55 push ebp
>>> [00001c23] 8bec mov ebp,esp
>>> [00001c25] 51 push ecx
>>> [00001c26] 8b4508 mov eax,[ebp+08]
>>> [00001c29] 50 push eax ; push DD 1c22
>>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>>> [00001c2d] 51 push ecx ; push DD 1c22
>>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>>> [00001c33] 83c408 add esp,+08
>>> [00001c36] 8945fc mov [ebp-04],eax
>>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>>> [00001c3d] 7402 jz 00001c41
>>> [00001c3f] ebfe jmp 00001c3f
>>> [00001c41] 8b45fc mov eax,[ebp-04]
>>> [00001c44] 8be5 mov esp,ebp
>>> [00001c46] 5d pop ebp
>>> [00001c47] c3 ret
>>> Size in bytes:(0038) [00001c47]
>>
>> It could if HH were a halting function as required. Then the call at
>> [00001c2e] would return and the next instruction would be reachable.
>> The reason that it is not, is that HH does not return.
>>
>> (You don't need to show your x86 code. Is does not show more than the
>> C code.)
>
> You simply fail to comprehend that recursive simulation is isomorphic
> to infinite recursion. That may be because you may have no idea what
> infinite recursion is.
>
It looks as if you do not understand that recursive simulation means
infinite simulation, so that the simulation does not halt. This is the
reason why HH simulated by itself does not reach its final state. Is
that even too difficult for you to understand?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-02 13:53 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3if3l$3f571$8@dont-email.me> |
| In reply to | #334927 |
On 6/2/2024 1:49 PM, Fred. Zwarts wrote:
> Op 02.jun.2024 om 20:32 schreef olcott:
>> On 6/2/2024 1:13 PM, Fred. Zwarts wrote:
>>> Op 02.jun.2024 om 16:41 schreef olcott:
>>>> On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
>>>>> Op 01.jun.2024 om 21:51 schreef olcott:
>>>>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *I will not discuss any other points with you until
>>>>>>>>>>>>>>>>>> after you either*
>>>>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and
>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>>>> in C
>>>>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite
>>>>>>>>>>>>>>>> set of HH/DD
>>>>>>>>>>>>>>>> pairs that match the above template never reaches past
>>>>>>>>>>>>>>>> its own simulated
>>>>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In this case HH is either a pure simulator that never
>>>>>>>>>>>>>>>> halts or
>>>>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>>>>> finite number
>>>>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>>>>> variable.
>>>>>>>>>>>>>>>> The pure function HH always returns the meaningless
>>>>>>>>>>>>>>>> value of 56
>>>>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You can pretend that you don't understand something that
>>>>>>>>>>>>>> you do indeed
>>>>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The key measure of dishonestly would be that you continue
>>>>>>>>>>>>>> to say
>>>>>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>>>>>> what you
>>>>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are
>>>>>>>>>>>>>>> asking, though it seems that now you are admitting that
>>>>>>>>>>>>>>> your HH doesn't actually ANSWER the question, so it isn't
>>>>>>>>>>>>>>> ACTUALL a decider for any function except the "56" mapping.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will repeat the question and until you answer the
>>>>>>>>>>>>>>> question of what that actually means, I will reply WHO
>>>>>>>>>>>>>>> CARES.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what
>>>>>>>>>>>>>> I specified*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have
>>>>>>>>>>>>>>> no code past point to simulate, and thus your claim is
>>>>>>>>>>>>>>> just a LIE.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>>>>>> instance of DD, at which point we never have the 1 to
>>>>>>>>>>>>>>> infinte number of simulatons of THAT INPUT, so your claim
>>>>>>>>>>>>>>> is just a LIE.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>>>>> We can't even say that you forgot these details from one
>>>>>>>>>>>>>> reply
>>>>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>>>>
>>>>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot
>>>>>>>>>>>> possibly
>>>>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Why? I don't care about it.
>>>>>>>>>>>
>>>>>>>>>>> As I have said, the implication of your definition of
>>>>>>>>>>> "Correct SImulation" means that this says NOTHING about the
>>>>>>>>>>> halting behavior of DD. (only not halted yet)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>>>>
>>>>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>>>>
>>>>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>>>>> something that is clearly meaningless.
>>>>>>>>>
>>>>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>>>>> only ever be simulated by ONE given HH that only simuates for
>>>>>>>>> one number of steps.
>>>>>>>>>
>>>>>>>>
>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>> 01 int DD(ptr p)
>>>>>>>> 02 {
>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>> 04 if (Halt_Status)
>>>>>>>> 05 HERE: goto HERE;
>>>>>>>> 06 return Halt_Status;
>>>>>>>> 07 }
>>>>>>>> 08
>>>>>>>> 09 int main()
>>>>>>>> 10 {
>>>>>>>> 11 HH(DD,DD);
>>>>>>>> 12 return 0;
>>>>>>>> 13 }
>>>>>>>>
>>>>>>>> You continue to either fail to understand or seemingly more likely
>>>>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>>>>> HH that can possibly exist cannot possibly reach past its own
>>>>>>>> line 03.
>>>>>>>
>>>>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>>>>> return, otherwise the simulation of DD would go to line 04.
>>>>>>>
>>>>>>>>
>>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>>
>>>>>>>
>>>>>>> If true: The input to HH is both DD and HH called by DD, so both
>>>>>>> DD and HH do not halt, but keep starting new instances of each
>>>>>>> other.
>>>>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>>>>> halts is phantasy.
>>>>>>
>>>>>> I have fully operational code that proves otherwise.
>>>>>
>>>>> But you are unable to show the ret instruction of HH simulated by
>>>>> itself. So, the proof is missing the crucial part.
>>>>>
>>>>>
>>>>>> Any expert in the C programming language knows the
>>>>>> same thing from the C source-code.
>>>>>>
>>>>>
>>>>
>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>> 00 int HH(ptr p, ptr i);
>>>> 01 int DD(ptr p)
>>>> 02 {
>>>> 03 int Halt_Status = HH(p, p);
>>>> 04 if (Halt_Status)
>>>> 05 HERE: goto HERE;
>>>> 06 return Halt_Status;
>>>> 07 }
>>>> 08
>>>> 09 int main()
>>>> 10 {
>>>> 11 HH(DD,DD);
>>>> 12 return 0;
>>>> 13 }
>>>>
>>>>> You don't need to be an expert in C to see that if the simulated HH
>>>>> would halt, then DD would continue to line 04.
>>>>
>>>> *Try and show how that can happen*
>>>
>>> If you show how HH simulated by HH reaches its return and show the
>>> next 10 instructions. You can't and therefore we know the simulated
>>> HH does not halt and the non-halting HH is the reason that DD does
>>> not continue.
>>>
>>>> *You may simply lack the required prerequisite knowledge >
>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>> reach past its own machine instruction [00001c2e] in any finite
>>>> (or infinite) number of steps of correct emulation.
>>>>
>>>> _DD()
>>>> [00001c22] 55 push ebp
>>>> [00001c23] 8bec mov ebp,esp
>>>> [00001c25] 51 push ecx
>>>> [00001c26] 8b4508 mov eax,[ebp+08]
>>>> [00001c29] 50 push eax ; push DD 1c22
>>>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>>>> [00001c2d] 51 push ecx ; push DD 1c22
>>>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>>>> [00001c33] 83c408 add esp,+08
>>>> [00001c36] 8945fc mov [ebp-04],eax
>>>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>>>> [00001c3d] 7402 jz 00001c41
>>>> [00001c3f] ebfe jmp 00001c3f
>>>> [00001c41] 8b45fc mov eax,[ebp-04]
>>>> [00001c44] 8be5 mov esp,ebp
>>>> [00001c46] 5d pop ebp
>>>> [00001c47] c3 ret
>>>> Size in bytes:(0038) [00001c47]
>>>
>>> It could if HH were a halting function as required. Then the call at
>>> [00001c2e] would return and the next instruction would be reachable.
>>> The reason that it is not, is that HH does not return.
>>>
>>> (You don't need to show your x86 code. Is does not show more than the
>>> C code.)
>>
>> You simply fail to comprehend that recursive simulation is isomorphic
>> to infinite recursion. That may be because you may have no idea what
>> infinite recursion is.
>>
>
> It looks as if you do not understand that recursive simulation means
> infinite simulation,
On 10/13/2022 11:29:23 AM
*MIT Professor Michael Sipser agreed this verbatim paragraph is correct*
(He has neither reviewed nor agreed to anything else in this paper)
<Professor Sipser agreed>
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.
</Professor Sipser agreed>
> so that the simulation does not halt. This is the
> reason why HH simulated by itself does not reach its final state. Is
> that even too difficult for you to understand?
*You have to actually pay attention to what I say*
--
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-02 20:59 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3ifel$3f51j$13@dont-email.me> |
| In reply to | #334928 |
Op 02.jun.2024 om 20:53 schreef olcott:
> On 6/2/2024 1:49 PM, Fred. Zwarts wrote:
>> Op 02.jun.2024 om 20:32 schreef olcott:
>>> On 6/2/2024 1:13 PM, Fred. Zwarts wrote:
>>>> Op 02.jun.2024 om 16:41 schreef olcott:
>>>>> On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
>>>>>> Op 01.jun.2024 om 21:51 schreef olcott:
>>>>>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>>>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *I will not discuss any other points with you until
>>>>>>>>>>>>>>>>>>> after you either*
>>>>>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and
>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in
>>>>>>>>>>>>>>>>>>> recursive simulation for
>>>>>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And until you answer the question of what that
>>>>>>>>>>>>>>>>>> actually means, I will reply WHO CARES.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int
>>>>>>>>>>>>>>>>> function in C
>>>>>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite
>>>>>>>>>>>>>>>>> set of HH/DD
>>>>>>>>>>>>>>>>> pairs that match the above template never reaches past
>>>>>>>>>>>>>>>>> its own simulated
>>>>>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In this case HH is either a pure simulator that never
>>>>>>>>>>>>>>>>> halts or
>>>>>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>>>>>> finite number
>>>>>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>>>>>> variable.
>>>>>>>>>>>>>>>>> The pure function HH always returns the meaningless
>>>>>>>>>>>>>>>>> value of 56
>>>>>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You can pretend that you don't understand something that
>>>>>>>>>>>>>>> you do indeed
>>>>>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The key measure of dishonestly would be that you continue
>>>>>>>>>>>>>>> to say
>>>>>>>>>>>>>>> that you don't understand yet never ever point out
>>>>>>>>>>>>>>> exactly what you
>>>>>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are
>>>>>>>>>>>>>>>> asking, though it seems that now you are admitting that
>>>>>>>>>>>>>>>> your HH doesn't actually ANSWER the question, so it
>>>>>>>>>>>>>>>> isn't ACTUALL a decider for any function except the "56"
>>>>>>>>>>>>>>>> mapping.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I will repeat the question and until you answer the
>>>>>>>>>>>>>>>> question of what that actually means, I will reply WHO
>>>>>>>>>>>>>>>> CARES.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly
>>>>>>>>>>>>>>> what I specified*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we
>>>>>>>>>>>>>>>> have no code past point to simulate, and thus your claim
>>>>>>>>>>>>>>>> is just a LIE.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a
>>>>>>>>>>>>>>>> given instance of DD, at which point we never have the 1
>>>>>>>>>>>>>>>> to infinte number of simulatons of THAT INPUT, so your
>>>>>>>>>>>>>>>> claim is just a LIE.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>>>>>> We can't even say that you forgot these details from one
>>>>>>>>>>>>>>> reply
>>>>>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>>>>>
>>>>>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot
>>>>>>>>>>>>> possibly
>>>>>>>>>>>>> reach past its own machine instruction [00001c2e] in any
>>>>>>>>>>>>> finite
>>>>>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Why? I don't care about it.
>>>>>>>>>>>>
>>>>>>>>>>>> As I have said, the implication of your definition of
>>>>>>>>>>>> "Correct SImulation" means that this says NOTHING about the
>>>>>>>>>>>> halting behavior of DD. (only not halted yet)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>>>>>
>>>>>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>>>>>
>>>>>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>>>>>> something that is clearly meaningless.
>>>>>>>>>>
>>>>>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>>>>>> only ever be simulated by ONE given HH that only simuates for
>>>>>>>>>> one number of steps.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>> 02 {
>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>> 06 return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>> 08
>>>>>>>>> 09 int main()
>>>>>>>>> 10 {
>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>> 12 return 0;
>>>>>>>>> 13 }
>>>>>>>>>
>>>>>>>>> You continue to either fail to understand or seemingly more likely
>>>>>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>>>>>> HH that can possibly exist cannot possibly reach past its own
>>>>>>>>> line 03.
>>>>>>>>
>>>>>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>>>>>> return, otherwise the simulation of DD would go to line 04.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>>>
>>>>>>>>
>>>>>>>> If true: The input to HH is both DD and HH called by DD, so both
>>>>>>>> DD and HH do not halt, but keep starting new instances of each
>>>>>>>> other.
>>>>>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>>>>>> halts is phantasy.
>>>>>>>
>>>>>>> I have fully operational code that proves otherwise.
>>>>>>
>>>>>> But you are unable to show the ret instruction of HH simulated by
>>>>>> itself. So, the proof is missing the crucial part.
>>>>>>
>>>>>>
>>>>>>> Any expert in the C programming language knows the
>>>>>>> same thing from the C source-code.
>>>>>>>
>>>>>>
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>> 00 int HH(ptr p, ptr i);
>>>>> 01 int DD(ptr p)
>>>>> 02 {
>>>>> 03 int Halt_Status = HH(p, p);
>>>>> 04 if (Halt_Status)
>>>>> 05 HERE: goto HERE;
>>>>> 06 return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 int main()
>>>>> 10 {
>>>>> 11 HH(DD,DD);
>>>>> 12 return 0;
>>>>> 13 }
>>>>>
>>>>>> You don't need to be an expert in C to see that if the simulated
>>>>>> HH would halt, then DD would continue to line 04.
>>>>>
>>>>> *Try and show how that can happen*
>>>>
>>>> If you show how HH simulated by HH reaches its return and show the
>>>> next 10 instructions. You can't and therefore we know the simulated
>>>> HH does not halt and the non-halting HH is the reason that DD does
>>>> not continue.
>>>>
>>>>> *You may simply lack the required prerequisite knowledge >
>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>> (or infinite) number of steps of correct emulation.
>>>>>
>>>>> _DD()
>>>>> [00001c22] 55 push ebp
>>>>> [00001c23] 8bec mov ebp,esp
>>>>> [00001c25] 51 push ecx
>>>>> [00001c26] 8b4508 mov eax,[ebp+08]
>>>>> [00001c29] 50 push eax ; push DD 1c22
>>>>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>>>>> [00001c2d] 51 push ecx ; push DD 1c22
>>>>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>>>>> [00001c33] 83c408 add esp,+08
>>>>> [00001c36] 8945fc mov [ebp-04],eax
>>>>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>>>>> [00001c3d] 7402 jz 00001c41
>>>>> [00001c3f] ebfe jmp 00001c3f
>>>>> [00001c41] 8b45fc mov eax,[ebp-04]
>>>>> [00001c44] 8be5 mov esp,ebp
>>>>> [00001c46] 5d pop ebp
>>>>> [00001c47] c3 ret
>>>>> Size in bytes:(0038) [00001c47]
>>>>
>>>> It could if HH were a halting function as required. Then the call at
>>>> [00001c2e] would return and the next instruction would be reachable.
>>>> The reason that it is not, is that HH does not return.
>>>>
>>>> (You don't need to show your x86 code. Is does not show more than
>>>> the C code.)
>>>
>>> You simply fail to comprehend that recursive simulation is isomorphic
>>> to infinite recursion. That may be because you may have no idea what
>>> infinite recursion is.
>>>
>>
>> It looks as if you do not understand that recursive simulation means
>> infinite simulation,
>
> On 10/13/2022 11:29:23 AM
> *MIT Professor Michael Sipser agreed this verbatim paragraph is correct*
> (He has neither reviewed nor agreed to anything else in this paper)
>
> <Professor Sipser agreed>
> 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.
> </Professor Sipser agreed>
>
>> so that the simulation does not halt. This is the reason why HH
>> simulated by itself does not reach its final state. Is that even too
>> difficult for you to understand?
>
> *You have to actually pay attention to what I say*
>
So, no rebuttal.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-02 15:07 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3ift2$2qu72$12@i2pn2.org> |
| In reply to | #334924 |
On 6/2/24 2:32 PM, olcott wrote:
> On 6/2/2024 1:13 PM, Fred. Zwarts wrote:
>> Op 02.jun.2024 om 16:41 schreef olcott:
>>> On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
>>>> Op 01.jun.2024 om 21:51 schreef olcott:
>>>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *I will not discuss any other points with you until
>>>>>>>>>>>>>>>>> after you either*
>>>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and
>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>>> in C
>>>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite
>>>>>>>>>>>>>>> set of HH/DD
>>>>>>>>>>>>>>> pairs that match the above template never reaches past
>>>>>>>>>>>>>>> its own simulated
>>>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In this case HH is either a pure simulator that never
>>>>>>>>>>>>>>> halts or
>>>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>>>> finite number
>>>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>>>> variable.
>>>>>>>>>>>>>>> The pure function HH always returns the meaningless value
>>>>>>>>>>>>>>> of 56
>>>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can pretend that you don't understand something that
>>>>>>>>>>>>> you do indeed
>>>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The key measure of dishonestly would be that you continue
>>>>>>>>>>>>> to say
>>>>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>>>>> what you
>>>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are
>>>>>>>>>>>>>> asking, though it seems that now you are admitting that
>>>>>>>>>>>>>> your HH doesn't actually ANSWER the question, so it isn't
>>>>>>>>>>>>>> ACTUALL a decider for any function except the "56" mapping.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will repeat the question and until you answer the
>>>>>>>>>>>>>> question of what that actually means, I will reply WHO CARES.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what
>>>>>>>>>>>>> I specified*
>>>>>>>>>>>>>
>>>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have
>>>>>>>>>>>>>> no code past point to simulate, and thus your claim is
>>>>>>>>>>>>>> just a LIE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>>>>> instance of DD, at which point we never have the 1 to
>>>>>>>>>>>>>> infinte number of simulatons of THAT INPUT, so your claim
>>>>>>>>>>>>>> is just a LIE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>>>
>>>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Why? I don't care about it.
>>>>>>>>>>
>>>>>>>>>> As I have said, the implication of your definition of "Correct
>>>>>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>>>>>> behavior of DD. (only not halted yet)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>>>
>>>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>>>
>>>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>>>> something that is clearly meaningless.
>>>>>>>>
>>>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>>>> only ever be simulated by ONE given HH that only simuates for
>>>>>>>> one number of steps.
>>>>>>>>
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>> 01 int DD(ptr p)
>>>>>>> 02 {
>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>> 04 if (Halt_Status)
>>>>>>> 05 HERE: goto HERE;
>>>>>>> 06 return Halt_Status;
>>>>>>> 07 }
>>>>>>> 08
>>>>>>> 09 int main()
>>>>>>> 10 {
>>>>>>> 11 HH(DD,DD);
>>>>>>> 12 return 0;
>>>>>>> 13 }
>>>>>>>
>>>>>>> You continue to either fail to understand or seemingly more likely
>>>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>>>> HH that can possibly exist cannot possibly reach past its own
>>>>>>> line 03.
>>>>>>
>>>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>>>> return, otherwise the simulation of DD would go to line 04.
>>>>>>
>>>>>>>
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>
>>>>>>
>>>>>> If true: The input to HH is both DD and HH called by DD, so both
>>>>>> DD and HH do not halt, but keep starting new instances of each other.
>>>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>>>> halts is phantasy.
>>>>>
>>>>> I have fully operational code that proves otherwise.
>>>>
>>>> But you are unable to show the ret instruction of HH simulated by
>>>> itself. So, the proof is missing the crucial part.
>>>>
>>>>
>>>>> Any expert in the C programming language knows the
>>>>> same thing from the C source-code.
>>>>>
>>>>
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int HH(ptr p, ptr i);
>>> 01 int DD(ptr p)
>>> 02 {
>>> 03 int Halt_Status = HH(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11 HH(DD,DD);
>>> 12 return 0;
>>> 13 }
>>>
>>>> You don't need to be an expert in C to see that if the simulated HH
>>>> would halt, then DD would continue to line 04.
>>>
>>> *Try and show how that can happen*
>>
>> If you show how HH simulated by HH reaches its return and show the
>> next 10 instructions. You can't and therefore we know the simulated HH
>> does not halt and the non-halting HH is the reason that DD does not
>> continue.
>>
>>> *You may simply lack the required prerequisite knowledge >
>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>> reach past its own machine instruction [00001c2e] in any finite
>>> (or infinite) number of steps of correct emulation.
>>>
>>> _DD()
>>> [00001c22] 55 push ebp
>>> [00001c23] 8bec mov ebp,esp
>>> [00001c25] 51 push ecx
>>> [00001c26] 8b4508 mov eax,[ebp+08]
>>> [00001c29] 50 push eax ; push DD 1c22
>>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>>> [00001c2d] 51 push ecx ; push DD 1c22
>>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>>> [00001c33] 83c408 add esp,+08
>>> [00001c36] 8945fc mov [ebp-04],eax
>>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>>> [00001c3d] 7402 jz 00001c41
>>> [00001c3f] ebfe jmp 00001c3f
>>> [00001c41] 8b45fc mov eax,[ebp-04]
>>> [00001c44] 8be5 mov esp,ebp
>>> [00001c46] 5d pop ebp
>>> [00001c47] c3 ret
>>> Size in bytes:(0038) [00001c47]
>>
>> It could if HH were a halting function as required. Then the call at
>> [00001c2e] would return and the next instruction would be reachable.
>> The reason that it is not, is that HH does not return.
>>
>> (You don't need to show your x86 code. Is does not show more than the
>> C code.)
>
> You simply fail to comprehend that recursive simulation is isomorphic
> to infinite recursion. That may be because you may have no idea what
> infinite recursion is.
>
UNCONDITION recursive simulation is isomorphic to infinite recursion.
HH does not do UNCONDITIONAL recursive simulation (at least not those
that answers) and thus your logic is shows to be INVALID.
Like most of your logic has been.
You are just proving your ignorance to the whole world
[toc] | [prev] | [next] | [standalone]
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-01 20:55 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3fqrj$2tc3s$7@dont-email.me> |
| In reply to | #334838 |
On 1/06/24 19:27, olcott wrote: > *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT* > DD correctly emulated by HH with an x86 emulator cannot possibly > reach past its own machine instruction [00001c2e] in any finite > number of steps of correct emulation. You just told me, in another message, that HH(DD,DD) halts. After HH(DD,DD) halts, DD gets to the next machine instruction.
[toc] | [prev] | [next] | [standalone]
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-01 20:53 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3fqns$2tc3s$4@dont-email.me> |
| In reply to | #334827 |
On 1/06/24 18:13, olcott wrote:
> On 6/1/2024 10:56 AM, Richard Damon wrote:
>> On 6/1/24 11:30 AM, olcott wrote:
>>>
>>> *I will not discuss any other points with you until after you either*
>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>> simulated by embedded_H remain stuck in recursive simulation for
>>> 1 to ∞ of correct simulation or
>>>
>>> (b) Correctly prove otherwise.
>>
>> And until you answer the question of what that actually means, I will
>> reply WHO CARES.
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 HH(DD,DD);
> 12 return 0;
> 13 }
>
> Every DD correctly simulated by any HH of the infinite set of HH/DD
> pairs that match the above template never reaches past its own simulated
> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>
> In this case HH is either a pure simulator that never halts or
> HH is a pure function that stops simulating after some finite number
> of simulated lines. The line count is stored in a local variable.
> The pure function HH always returns the meaningless value of 56
> after it stops simulating.
56 is a nonzero number. In C, nonzero numbers are 'true'. Returning 56
means that DD(DD) halts, which is incorrect if HH returns 56.
>
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-01 20:26 +0000 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3g06i$2o13h$17@i2pn2.org> |
| In reply to | #334827 |
Am Sat, 01 Jun 2024 11:13:10 -0500 schrieb olcott:
> On 6/1/2024 10:56 AM, Richard Damon wrote:
>> On 6/1/24 11:30 AM, olcott wrote:
>>>
>>> *I will not discuss any other points with you until after you either*
>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩ ⟨Ĥ⟩
>>> correctly
>>> simulated by embedded_H remain stuck in recursive simulation
>>> for 1 to ∞ of correct simulation or
>>>
>>> (b) Correctly prove otherwise.
>>
>> And until you answer the question of what that actually means, I will
>> reply WHO CARES.
>>
>>
> typedef int (*ptr)(); // ptr is pointer to int function in C 00
> int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08 09 int main()
> 10 {
> 11 HH(DD,DD);
> 12 return 0;
> 13 }
>
> Every DD correctly simulated by any HH of the infinite set of HH/DD
> pairs that match the above template never reaches past its own simulated
> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>
> In this case HH is either a pure simulator that never halts or HH is a
> pure function that stops simulating after some finite number of
> simulated lines. The line count is stored in a local variable.
> The pure function HH always returns the meaningless value of 56 after it
> stops simulating.
Didn't you forbid additional parameters?
56 evaluates as True, so D never returns.
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-01 15:32 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3g0h4$2v3lp$1@dont-email.me> |
| In reply to | #334872 |
On 6/1/2024 3:26 PM, joes wrote:
> Am Sat, 01 Jun 2024 11:13:10 -0500 schrieb olcott:
>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>
>>>> *I will not discuss any other points with you until after you either*
>>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> correctly
>>>> simulated by embedded_H remain stuck in recursive simulation
>>>> for 1 to ∞ of correct simulation or
>>>>
>>>> (b) Correctly prove otherwise.
>>>
>>> And until you answer the question of what that actually means, I will
>>> reply WHO CARES.
>>>
>>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C 00
>> int HH(ptr p, ptr i);
>> 01 int DD(ptr p)
>> 02 {
>> 03 int Halt_Status = HH(p, p);
>> 04 if (Halt_Status)
>> 05 HERE: goto HERE;
>> 06 return Halt_Status;
>> 07 }
>> 08 09 int main()
>> 10 {
>> 11 HH(DD,DD);
>> 12 return 0;
>> 13 }
>>
>> Every DD correctly simulated by any HH of the infinite set of HH/DD
>> pairs that match the above template never reaches past its own simulated
>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>
>> In this case HH is either a pure simulator that never halts or HH is a
>> pure function that stops simulating after some finite number of
>> simulated lines. The line count is stored in a local variable.
>> The pure function HH always returns the meaningless value of 56 after it
>> stops simulating.
> Didn't you forbid additional parameters?
> 56 evaluates as True, so D never returns.
>
Disingenuous reply ignored.
Pages 4-5 of
*The 2021-09-26 version of my first paper on simulating halt deciders*
*Halting problem undecidability and infinitely nested simulation*
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_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 | immibis <news@immibis.com> |
|---|---|
| Date | 2024-06-01 14:49 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3f5d9$2ph3j$6@dont-email.me> |
| In reply to | #334798 |
On 1/06/24 04:08, olcott wrote: > > *AS LONG AS 1 to ∞ steps of* > ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach their > own simulated final state of ⟨Ĥ.qn⟩ they can
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-01 11:01 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3eo18$2mn41$3@dont-email.me> |
| In reply to | #334796 |
Op 01.jun.2024 om 03:10 schreef olcott: > On 5/31/2024 7:39 PM, Richard Damon wrote: >> On 5/31/24 7:57 PM, olcott wrote: >>> On 5/31/2024 6:33 PM, Richard Damon wrote: >>>> On 5/31/24 6:54 PM, olcott wrote: >>>>> On 5/31/2024 5:46 PM, Richard Damon wrote: >>>>>> On 5/31/24 6:08 PM, olcott wrote: >>>>>>> On 5/31/2024 4:36 PM, Richard Damon wrote: >>>>>>>> On 5/31/24 10:10 AM, olcott wrote: >>>>>>>>> On 5/31/2024 6:16 AM, Richard Damon wrote: >>>>>>>>>> On 5/30/24 11:27 PM, olcott wrote: >>>>>>>>>>> Try and show how HH using an x86 emulator can correctly emulate >>>>>>>>>>> the following x86 machine code such that DD reaches its own >>>>>>>>>>> machine address 00001c47. >>>>>>>>>> >>>>>>>>>> Why should I, since that isn't what I was saying. >>>>>>>>>> >>>>>>>>> >>>>>>>>> *To me that looks like you know that* >>>>>>>>> *you have been busted in a lie and are backing down* >>>>>>>> >>>>>>>> no, YOU are LYING RIGHT HERE AND NOW. >>>>>>>> >>>>>>>> Prove that I said that the simulation by HH made it there, or >>>>>>>> admit to being a DAMNED LIAR. >>>>>>>> >>>>>>>> What I have been saying is the the DIRECT EXDCUTION of DD, and >>>>>>>> the CORRECT (and complete) simulation of the input to HH by an >>>>>>>> actual UTM will get there. >>>>>>>> >>>>>>> >>>>>>> That has always been the dishonest dodge strawman deception >>>>>>> CHANGE-THE-SUBJECT fake rebuttal regarding >>>>>>> the behavior of DD correctly simulated by pure function HH. >>>>>> >>>>>> But it is your talking about the "correctly simulated by HH" that >>>>>> is the dishonest dodge, >>>>> >>>>> Try and show how HH using an x86 emulator can correctly emulate >>>>> the following x86 machine code such that DD reaches its own >>>>> machine address 00001c47. >>>> >>>> Never said it could. But haven't looked hard enough to be willing to >>>> say it can't, but then, who cares, it doesn't say a thing about the >>>> real halting problem, since H's simulation isn't "correct" by a >>>> definition that relates simulation to non-halting behavior, >>>> >>> >>> "...the Turing machine will halt whenever it enters a final state." >>> Linz(1990:234) >> >> Right, and that is talking about runnig the Turing Machine, not >> simulating a representation of it. >> > > DD correctly simulated by HH cannot possibly reach its own simulated > final state. This is conclusively proven beyond all possible doubt > by the x86 machine code of DD. > > You can lie about this and try to get away with changing the subject. > What you cannot do is show that it is not true. > Similarly: HH correctly simulated by HH cannot possibly reach its own simulated final state. This is conclusively proven beyond all possible doubt. You can lie about this and try to get away with changing the subject. What you cannot do is show that it is not true. So your HH that simulates and halts is just phantasy.
[toc] | [prev] | [next] | [standalone]
| From | Wasell <wasell@example.com> |
|---|---|
| Date | 2024-06-01 10:36 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <MPG.40c4fbcb474992459896fd@reader.eternal-september.org> |
| In reply to | #334794 |
On Fri, 31 May 2024 18:57:57 -0500, in article <v3do66$2ejq2$1@dont-email.me>,
olcott wrote:
>
> On 5/31/2024 6:33 PM, Richard Damon wrote:
[...]
>> Never said it could. But haven't looked hard enough to be willing to say
>> it can't, but then, who cares, it doesn't say a thing about the real
>> halting problem, since H's simulation isn't "correct" by a definition
>> that relates simulation to non-halting behavior,
>
> "...the Turing machine will halt whenever it enters a final state."
> Linz(1990:234)
>
> *If DD correctly simulated by HH can't possibly reach its own*
> *final state then DD correctly simulated by HH is non-halting*
You keep using this quote as if it means that the /only/ way a TM
can halt, is if it enters a final state. You never quote the
context:
"A Turing machine is said to halt whenever it reaches a
configuration for which \delta is not defined; this is possible
because \delta is a partial function. In fact, we will assume that
no transitions are defined for any final state, so the Turing
machine will halt whenever it enters a final state."
(p. 227 in my copy)
This means that a TM /will/ halt if it enters a final state, but it
can also halt in other states. This interpretation is confirmed in
other places in Linz:
"The machine can halt in a nonfinal state or it can enter an
infinite loop and never halt. [...] we halt in a nonfinal state.
[...] the machine will halt in the nonfinal state q_0 , since
\delta(q_0,1) is undefined." (p. 232)
"[...] the computation will halt in a nonfinal state." (p. 233)
"Other input not in the language will also lead to a nonfinal
halting state" (p. 234)
"[...] that will halt in a nonfinal state q_n if x < y." (p. 237)
etc, etc.
Can I expect you to never use this deceptive out-of-context quote
ever again?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-01 09:00 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3f9ha$2qh0t$1@dont-email.me> |
| In reply to | #334802 |
On 6/1/2024 3:36 AM, Wasell wrote:
> On Fri, 31 May 2024 18:57:57 -0500, in article <v3do66$2ejq2$1@dont-email.me>,
> olcott wrote:
>>
>> On 5/31/2024 6:33 PM, Richard Damon wrote:
>
> [...]
>
>>> Never said it could. But haven't looked hard enough to be willing to say
>>> it can't, but then, who cares, it doesn't say a thing about the real
>>> halting problem, since H's simulation isn't "correct" by a definition
>>> that relates simulation to non-halting behavior,
>>
>> "...the Turing machine will halt whenever it enters a final state."
>> Linz(1990:234)
>>
>> *If DD correctly simulated by HH can't possibly reach its own*
>> *final state then DD correctly simulated by HH is non-halting*
>
> You keep using this quote as if it means that the /only/ way a TM
> can halt, is if it enters a final state. You never quote the
> context:
>
> "A Turing machine is said to halt whenever it reaches a
> configuration for which \delta is not defined; this is possible
> because \delta is a partial function. In fact, we will assume that
> no transitions are defined for any final state, so the Turing
> machine will halt whenever it enters a final state."
> (p. 227 in my copy)
>
> This means that a TM /will/ halt if it enters a final state, but it
> can also halt in other states. This interpretation is confirmed in
> other places in Linz:
>
> "The machine can halt in a nonfinal state or it can enter an
> infinite loop and never halt. [...] we halt in a nonfinal state.
> [...] the machine will halt in the nonfinal state q_0 , since
> \delta(q_0,1) is undefined." (p. 232)
>
> "[...] the computation will halt in a nonfinal state." (p. 233)
>
> "Other input not in the language will also lead to a nonfinal
> halting state" (p. 234)
>
> "[...] that will halt in a nonfinal state q_n if x < y." (p. 237)
>
> etc, etc.
>
> Can I expect you to never use this deceptive out-of-context quote
> ever again?
DD correctly simulated by HH remains stuck in recursive simulation
all the time it is simulated even when an infinite number of steps
are simulated.
According to the words that you quoted it would be more accurate to
provide a longer definition. I will attempt that yet this may be too
difficult for my short-attention space reviewers.
"δ is the transition function" (Linz:1990:233) ...
"A Turing machine is said to halt whenever it reaches a
configuration for which δ is not defined; (Linz:1990:234)
DD correctly simulated by HH never reaches any point where δ
is not defined. My target audience of software engineers may be
dumbfounded by that. Software engineers will not allow false
assumptions to override verified facts.
DD correctly simulated by HH has behavior that is isomorphic
to Infinite_Recursion simulated by HH.
void Infinite_Recursion(u32 N)
{
Infinite_Recursion(N);
}
Since the idea of a simulating halt decider is brand new with me
there is not any preexisting literature on simulating halt deciders.
The above proves that we cannot construe that stopping running
because of stopping being simulated is any kind of halting behavior.
Introduction to the Theory of Computation, by Michael Sipser
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
On 10/13/2022 11:29:23 AM
MIT Professor Michael Sipser agreed that these verbatim words are correct
(He has neither reviewed nor agreed to anything else in this paper)
<Sipser agreed>
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.
</Sipser agreed>
Because my reviewers tend to be much more interested in rebuttal (even
when this rebuttal directly contradicts verified facts) I must make
my words unequivocal and clear. Even when make my words unequivocally
prove my point with verified facts they still disagree.
After three years of discussion with Richard on the one point that DD
correctly simulated by HH never reaches its own final state he finally
admitted that he just doesn't.
I had to confront him with the x86 machine code of DD to get him to
concede that he doesn't know. This took three years.
Prior to confronting him with this machine code he (and two dozen
other people) persistently disagreed with what a correct simulation
is. Now that the machine code is presented no one can get away with
saying that DD correctly simulated by HH can possibly reach its own
machine address of 00001c47 (or any other point where δ is undefined).
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
It is clear that DD correctly simulated by HH using an x86 emulator
cannot possibly reach past its own line 03 for 1 to ∞ steps of correct
simulation.
Four experts in the C language concurred with my own expert assessment.
It really is dead obvious to anyone with sufficient knowledge of the C
programming language thus all those that disagree could only be playing
trollish head games.
Finally when confronted with the x86 machine language of DD where lying
would look ridiculously foolish Richard backed down and admitted that
he just doesn't know.
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
--
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-01 11:46 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3ffpc$2n53n$3@i2pn2.org> |
| In reply to | #334808 |
On 6/1/24 10:00 AM, olcott wrote:
> On 6/1/2024 3:36 AM, Wasell wrote:
>> On Fri, 31 May 2024 18:57:57 -0500, in article
>> <v3do66$2ejq2$1@dont-email.me>,
>> olcott wrote:
>>>
>>> On 5/31/2024 6:33 PM, Richard Damon wrote:
>>
>> [...]
>>
>>>> Never said it could. But haven't looked hard enough to be willing to
>>>> say
>>>> it can't, but then, who cares, it doesn't say a thing about the real
>>>> halting problem, since H's simulation isn't "correct" by a definition
>>>> that relates simulation to non-halting behavior,
>>>
>>> "...the Turing machine will halt whenever it enters a final state."
>>> Linz(1990:234)
>>>
>>> *If DD correctly simulated by HH can't possibly reach its own*
>>> *final state then DD correctly simulated by HH is non-halting*
>>
>> You keep using this quote as if it means that the /only/ way a TM
>> can halt, is if it enters a final state. You never quote the
>> context:
>>
>> "A Turing machine is said to halt whenever it reaches a
>> configuration for which \delta is not defined; this is possible
>> because \delta is a partial function. In fact, we will assume that
>> no transitions are defined for any final state, so the Turing
>> machine will halt whenever it enters a final state."
>> (p. 227 in my copy)
>>
>> This means that a TM /will/ halt if it enters a final state, but it
>> can also halt in other states. This interpretation is confirmed in
>> other places in Linz:
>>
>> "The machine can halt in a nonfinal state or it can enter an
>> infinite loop and never halt. [...] we halt in a nonfinal state.
>> [...] the machine will halt in the nonfinal state q_0 , since
>> \delta(q_0,1) is undefined." (p. 232)
>>
>> "[...] the computation will halt in a nonfinal state." (p. 233)
>>
>> "Other input not in the language will also lead to a nonfinal
>> halting state" (p. 234)
>>
>> "[...] that will halt in a nonfinal state q_n if x < y." (p. 237)
>>
>> etc, etc.
>>
>> Can I expect you to never use this deceptive out-of-context quote
>> ever again?
>
> DD correctly simulated by HH remains stuck in recursive simulation
> all the time it is simulated even when an infinite number of steps
> are simulated.
So, are you admitting that HH just gets stuck and doesn't answer when
asked HH(DD,DD)?
>
> According to the words that you quoted it would be more accurate to
> provide a longer definition. I will attempt that yet this may be too
> difficult for my short-attention space reviewers.
>
> "δ is the transition function" (Linz:1990:233) ...
> "A Turing machine is said to halt whenever it reaches a
> configuration for which δ is not defined; (Linz:1990:234)
>
> DD correctly simulated by HH never reaches any point where δ
> is not defined. My target audience of software engineers may be
> dumbfounded by that. Software engineers will not allow false
> assumptions to override verified facts.
So,
>
> DD correctly simulated by HH has behavior that is isomorphic
> to Infinite_Recursion simulated by HH.
Only if you admit your HH will never abort its simulation, at which
point it us HH that has the behavior isomorphic to Infinite_Recursion.
After all, once DD calls HH, the code never gets back to actually
executiong any steps of DD, so the DD outside of HH can't get stuck in
the infinite recursion, only the part in HH, which means that it is HH
that got caught in the infinite recursion.
>
> void Infinite_Recursion(u32 N)
> {
> Infinite_Recursion(N);
> }
>
> Since the idea of a simulating halt decider is brand new with me
> there is not any preexisting literature on simulating halt deciders.
Note, "new to me", it is not "new"
>
> The above proves that we cannot construe that stopping running
> because of stopping being simulated is any kind of halting behavior.
>
Right, but stopping being simulated also does not indicated non-halting
behavior.
>
> Introduction to the Theory of Computation, by Michael Sipser
> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>
> On 10/13/2022 11:29:23 AM
> MIT Professor Michael Sipser agreed that these verbatim words are correct
> (He has neither reviewed nor agreed to anything else in this paper)
>
> <Sipser agreed>
> 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.
> </Sipser agreed>
So ONLY IF H DOES correctly simulate its input, which means it will
never abort its input, can H abort its simulation.
So, you have to figure out how to both SIMULATE FOREVER and abort your
simulation,
>
> Because my reviewers tend to be much more interested in rebuttal (even
> when this rebuttal directly contradicts verified facts) I must make
> my words unequivocal and clear. Even when make my words unequivocally
> prove my point with verified facts they still disagree.
>
> After three years of discussion with Richard on the one point that DD
> correctly simulated by HH never reaches its own final state he finally
> admitted that he just doesn't.
When did I recently agree to that?
My earlier agreement years ago was based on "Correct-Simulation" being
the canonical (to computaiton theory) definition of Correct Simulation,
which means non-aborted.
And since all of that is based on a non-canonical definition of
simulation which means that it doesn't actually indicate non-halting,
the staement is irrelevent.
>
> I had to confront him with the x86 machine code of DD to get him to
> concede that he doesn't know. This took three years.
And where did I agree to it?
>
> Prior to confronting him with this machine code he (and two dozen
> other people) persistently disagreed with what a correct simulation
> is. Now that the machine code is presented no one can get away with
> saying that DD correctly simulated by HH can possibly reach its own
> machine address of 00001c47 (or any other point where δ is undefined).
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> It is clear that DD correctly simulated by HH using an x86 emulator
> cannot possibly reach past its own line 03 for 1 to ∞ steps of correct
> simulation.
And I showed that there can exist an HH that can do that unless you add
restirctions to what HH is, which you keep on dropping.
And you have a problem of definitions.
Is HH simulating a "templeate" DD, in which case, what does it simulate
for the call to HH, since there is no code for HH in the template,
or is HH simulating an instance of the template, DD, in which case each
number of steps is a diffferent instance, none of which shows that DD is
actually non-halting, just that each one didn't halt yet, but if HH
aborts and returns 0, we can show it WILL halt.
>
> Four experts in the C language concurred with my own expert assessment.
> It really is dead obvious to anyone with sufficient knowledge of the C
> programming language thus all those that disagree could only be playing
> trollish head games.
Fallacy of arguement by authority, particularly using people who clearly
don't understand what compuation theory is.
>
> Finally when confronted with the x86 machine language of DD where lying
> would look ridiculously foolish Richard backed down and admitted that
> he just doesn't know.
So, do you want to answer the questions about the definition of what you
are asking for, or are YOU afraid that if you admit to which one you are
using you can be shown to be a liar.
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
>
The above code, if used as the TOTAL definition of what is to be done,
i.e DD is just a template, can NOT be simulated past the call HH
instruction, and thus your claim of 1 to infinity instructions is a LIE,
as it can not be simulated for more than 8 instructions.
If you include a version of HH, then that simulation only applies for
that version of H, and that simulation will only proceed for exactly
some N steps, and then it WILL be aborted, as that is all that given HH
will do,
It has been shown that if you pair that DD with an specific HH, then
give that paired description to UTM, it WILL reach a final state if that
HH(DD,DD) returns 0.
Thus, that answer can not be correct.
If the arguement is that THIS HH couldn't reach the final state in its
simulation, then by the exact same logic, an HH that simulates exactly
one step and then aborts, and if that wasn't the ret opcode says the
input is non-halting would be just as correct, and thus your "criteria"
is basically meaningless.
Different HH's paired to DD give diffferent inputs, so it is INVALID
LOGIC to talk about them having meaning for this input.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-01 10:58 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3fgfb$2riae$2@dont-email.me> |
| In reply to | #334818 |
On 6/1/2024 10:46 AM, Richard Damon wrote: > On 6/1/24 10:00 AM, olcott wrote: >> DD correctly simulated by HH remains stuck in recursive simulation >> all the time it is simulated even when an infinite number of steps >> are simulated. > > So, are you admitting that HH just gets stuck and doesn't answer when > asked HH(DD,DD)? > Every DD correctly simulated by any HH remains stuck in recursive simulation for 1 to ∞ steps of correct simulation. As I have repeatedly told you hundreds of times DD correctly simulated by pure simulator HH never gets past its own line 03 and this HH does not halt. Also DD correctly simulated by pure function HH never gets past its own line 03 and THIS HH DOES HALT. If you really can't remember that from one post to the next I suggest that you print that out so that you can see it immediately before making any reply. -- 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-01 12:08 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3fh1a$2n53o$5@i2pn2.org> |
| In reply to | #334823 |
On 6/1/24 11:58 AM, olcott wrote: > On 6/1/2024 10:46 AM, Richard Damon wrote: >> On 6/1/24 10:00 AM, olcott wrote: >> DD correctly simulated by HH >> remains stuck in recursive simulation >>> all the time it is simulated even when an infinite number of steps >>> are simulated. >> >> So, are you admitting that HH just gets stuck and doesn't answer when >> asked HH(DD,DD)? >> > > Every DD correctly simulated by any HH remains stuck in recursive > simulation for 1 to ∞ steps of correct simulation. So? Since you definition of "Correct Simulation" is non-canonical, that doesn't mean anything. And you still haven't defined what you mean by this DD correctly simulated by HH, and thus which why you have lied abut the 1 to ∞ steps of correct simulation. If DD is a template, then you can't simulate DD past the call HH instruction and thus don't get anywhere near to infinity. If DD is a instance of the template, then each instance is only simulated for exactly on value of number of steps, so you are not talking about the same thing in the two parts of your statement and thus are making a type error. > > As I have repeatedly told you hundreds of times DD correctly > simulated by pure simulator HH never gets past its own line 03 > and this HH does not halt. So, when are you going to answer the question of what you mean by that to make it clear which part of your claim is the lie? > > Also DD correctly simulated by pure function HH never gets past > its own line 03 and THIS HH DOES HALT. And who cares about the fact that DD didn't halt before its simulation was aborted? > > If you really can't remember that from one post to the next I suggest > that you print that out so that you can see it immediately before making > any reply. > Maybe you should answer the question put before you and not just be arguing with yourself. Repeating non-responsive replies just shows that you don't know how to continue the discussion with an actual answer, because you. know you have been caught in a lie.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-01 11:18 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical |
| Message-ID | <v3fhkr$2rsbs$2@dont-email.me> |
| In reply to | #334826 |
On 6/1/2024 11:08 AM, Richard Damon wrote: > On 6/1/24 11:58 AM, olcott wrote: >> On 6/1/2024 10:46 AM, Richard Damon wrote: >>> On 6/1/24 10:00 AM, olcott wrote: >> DD correctly simulated by HH >>> remains stuck in recursive simulation >>>> all the time it is simulated even when an infinite number of steps >>>> are simulated. >>> >>> So, are you admitting that HH just gets stuck and doesn't answer when >>> asked HH(DD,DD)? >>> >> >> Every DD correctly simulated by any HH remains stuck in recursive >> simulation for 1 to ∞ steps of correct simulation. > > So? Since you definition of "Correct Simulation" is non-canonical, that > doesn't mean anything. > *When the "canonical" definition tries to get away with refuting this* DD correctly emulated by HH with an x86 emulator cannot possibly reach past its own machine instruction [00001c2e] in any finite number of steps of correct emulation. *Then the "canonical" definition is empirically proven to be incorrect* _DD() [00001c22] 55 push ebp [00001c23] 8bec mov ebp,esp [00001c25] 51 push ecx [00001c26] 8b4508 mov eax,[ebp+08] [00001c29] 50 push eax ; push DD 1c22 [00001c2a] 8b4d08 mov ecx,[ebp+08] [00001c2d] 51 push ecx ; push DD 1c22 [00001c2e] e80ff7ffff call 00001342 ; call HH [00001c33] 83c408 add esp,+08 [00001c36] 8945fc mov [ebp-04],eax [00001c39] 837dfc00 cmp dword [ebp-04],+00 [00001c3d] 7402 jz 00001c41 [00001c3f] ebfe jmp 00001c3f [00001c41] 8b45fc mov eax,[ebp-04] [00001c44] 8be5 mov esp,ebp [00001c46] 5d pop ebp [00001c47] c3 ret Size in bytes:(0038) [00001c47] -- 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-01 12:33 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical |
| Message-ID | <v3fig4$2n53n$6@i2pn2.org> |
| In reply to | #334828 |
On 6/1/24 12:18 PM, olcott wrote: > On 6/1/2024 11:08 AM, Richard Damon wrote: >> On 6/1/24 11:58 AM, olcott wrote: >>> On 6/1/2024 10:46 AM, Richard Damon wrote: >>>> On 6/1/24 10:00 AM, olcott wrote: >> DD correctly simulated by HH >>>> remains stuck in recursive simulation >>>>> all the time it is simulated even when an infinite number of steps >>>>> are simulated. >>>> >>>> So, are you admitting that HH just gets stuck and doesn't answer >>>> when asked HH(DD,DD)? >>>> >>> >>> Every DD correctly simulated by any HH remains stuck in recursive >>> simulation for 1 to ∞ steps of correct simulation. >> >> So? Since you definition of "Correct Simulation" is non-canonical, >> that doesn't mean anything. >> > > *When the "canonical" definition tries to get away with refuting this* > > DD correctly emulated by HH with an x86 emulator cannot possibly > reach past its own machine instruction [00001c2e] in any finite > number of steps of correct emulation. No, it doesn't "Refute" that, it just says your statement is meaningless. Aborted simulations just don't directly tell you if the machine being simulated is non-halting. If you are too stupid to understand that, it is your own problem. > > *Then the "canonical" definition is empirically proven to be incorrect* IMPOSSIBLE. I guess you are admitting you don't know what a DEFINITION is, so of course you whole logic system is meaningless, BUY DEFINITION. Remeber, YOU AGREED that D(D) Halts when H(D,D) returns 0, but you claim that H must still be correct ingiving the wrong answer. THAT is the foundation of your logic, that LIES can be TRUE if you try to define them to be, which just means your world is all just a fantasy that bears no resemblence to reality. Of course, some day, maybe soon, you will see the results of that, and weep. > > _DD() > [00001c22] 55 push ebp > [00001c23] 8bec mov ebp,esp > [00001c25] 51 push ecx > [00001c26] 8b4508 mov eax,[ebp+08] > [00001c29] 50 push eax ; push DD 1c22 > [00001c2a] 8b4d08 mov ecx,[ebp+08] > [00001c2d] 51 push ecx ; push DD 1c22 > [00001c2e] e80ff7ffff call 00001342 ; call HH > [00001c33] 83c408 add esp,+08 > [00001c36] 8945fc mov [ebp-04],eax > [00001c39] 837dfc00 cmp dword [ebp-04],+00 > [00001c3d] 7402 jz 00001c41 > [00001c3f] ebfe jmp 00001c3f > [00001c41] 8b45fc mov eax,[ebp-04] > [00001c44] 8be5 mov esp,ebp > [00001c46] 5d pop ebp > [00001c47] c3 ret > Size in bytes:(0038) [00001c47] >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-01 11:46 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical |
| Message-ID | <v3fj8h$2rsbs$6@dont-email.me> |
| In reply to | #334833 |
On 6/1/2024 11:33 AM, Richard Damon wrote: > On 6/1/24 12:18 PM, olcott wrote: >> On 6/1/2024 11:08 AM, Richard Damon wrote: >>> On 6/1/24 11:58 AM, olcott wrote: >>>> On 6/1/2024 10:46 AM, Richard Damon wrote: >>>>> On 6/1/24 10:00 AM, olcott wrote: >> DD correctly simulated by HH >>>>> remains stuck in recursive simulation >>>>>> all the time it is simulated even when an infinite number of steps >>>>>> are simulated. >>>>> >>>>> So, are you admitting that HH just gets stuck and doesn't answer >>>>> when asked HH(DD,DD)? >>>>> >>>> >>>> Every DD correctly simulated by any HH remains stuck in recursive >>>> simulation for 1 to ∞ steps of correct simulation. >>> >>> So? Since you definition of "Correct Simulation" is non-canonical, >>> that doesn't mean anything. >>> >> >> *When the "canonical" definition tries to get away with refuting this* >> >> DD correctly emulated by HH with an x86 emulator cannot possibly >> reach past its own machine instruction [00001c2e] in any finite >> number of steps of correct emulation. > > No, it doesn't "Refute" that, *Then what I said stands unrefuted* *Then what I said stands unrefuted* *Then what I said stands unrefuted* *We can't move on to any other point until* (a) You acknowledge that my above statement about the behavior of the x86 machine code of DD is irrefutable and applies to the C source code version of DD and applies to the Linz proof. (b) You correctly refute what I said above about the behavior of the x86 machine code of DD. >> >> _DD() >> [00001c22] 55 push ebp >> [00001c23] 8bec mov ebp,esp >> [00001c25] 51 push ecx >> [00001c26] 8b4508 mov eax,[ebp+08] >> [00001c29] 50 push eax ; push DD 1c22 >> [00001c2a] 8b4d08 mov ecx,[ebp+08] >> [00001c2d] 51 push ecx ; push DD 1c22 >> [00001c2e] e80ff7ffff call 00001342 ; call HH >> [00001c33] 83c408 add esp,+08 >> [00001c36] 8945fc mov [ebp-04],eax >> [00001c39] 837dfc00 cmp dword [ebp-04],+00 >> [00001c3d] 7402 jz 00001c41 >> [00001c3f] ebfe jmp 00001c3f >> [00001c41] 8b45fc mov eax,[ebp-04] >> [00001c44] 8be5 mov esp,ebp >> [00001c46] 5d pop ebp >> [00001c47] c3 ret >> Size in bytes:(0038) [00001c47] >> > -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | sci.logic
csiph-web