Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #105649 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-05-28 11:16 -0500 |
| Last post | 2024-06-03 13:36 +0300 |
| Articles | 20 on this page of 361 — 14 participants |
Back to article view | Back to comp.theory
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 Mikko <mikko.levanto@iki.fi> - 2024-05-29 12:14 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 08:24 -0500
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 joes <noreply@example.com> - 2024-05-30 09:11 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-30 08:11 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-05-30 19:58 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets 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 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 Mikko <mikko.levanto@iki.fi> - 2024-05-31 11:51 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-05-31 11:15 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-05-31 16:12 +0300
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 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:17 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-29 18:08 +0100
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 12:32 -0500
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 13:08 -0500
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 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 Ben Bacarisse <ben@bsb.me.uk> - 2024-05-29 19:14 +0100
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:25 -0500
Re: Two dozen people were simply wrong Python <python@invalid.org> - 2024-05-29 22:54 +0200
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 joes <noreply@example.com> - 2024-05-30 09:08 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 08:21 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-05-31 11:08 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- Mike Terry olcott <polcott333@gmail.com> - 2024-05-31 10:04 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-05-30 10:40 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 08:31 -0500
Re: Two dozen people were 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 joes <noreply@example.com> - 2024-06-02 09:18 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:54 -0500
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 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 "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 Mikko <mikko.levanto@iki.fi> - 2024-06-02 11:29 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:08 -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 Mikko <mikko.levanto@iki.fi> - 2024-06-03 12:44 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-03 08:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Mikko <mikko.levanto@iki.fi> - 2024-06-03 17:35 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-03 13:19 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:51 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -0400
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 --- joes <noreply@example.com> - 2024-06-02 09:36 +0000
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 09:58 -0500
Re: Olcott is simply wrong --- Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:16 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:37 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:51 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:57 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 21:01 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 14:10 -0500
Re: Two dozen people were simply wrong --- Richard Damon <richard@damon-family.org> - 2024-06-02 15:18 -0400
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 09:37 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-03 07:24 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:53 +0200
Re: Two dozen people were simply wrong --- Richard Damon <richard@damon-family.org> - 2024-06-02 15:08 -0400
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 10:02 -0500
Re: Two dozen people were simply wrong --- joes <noreply@example.com> - 2024-06-02 17:55 +0000
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:08 -0500
Re: Two dozen people were simply wrong --- Richard Damon <richard@damon-family.org> - 2024-06-02 14:18 -0400
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:36 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:42 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:53 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:58 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 09:40 +0200
Re: Two dozen people were simply wrong --- Alan Mackenzie <acm@muc.de> - 2024-06-02 21:02 +0000
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 joes <noreply@example.com> - 2024-06-01 19:04 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:01 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 23:35 +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 joes <noreply@example.com> - 2024-06-01 18:59 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 18:41 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:45 -0500
Re: Two dozen people were simply right --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-02 09:46 +0000
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 Mikko <mikko.levanto@iki.fi> - 2024-05-31 11:30 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-31 10:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-06-03 13:03 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-06-03 08:16 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-06-03 17:49 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-06-03 13:20 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-06-04 11:40 +0300
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 --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-05-31 11:22 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-31 10:07 -0500
Re: H is an incorrect x86 emulator immibis <news@immibis.com> - 2024-05-30 12:24 +0200
Re: Two dozen people were simply wrong immibis <news@immibis.com> - 2024-05-30 12:04 +0200
Re: Two dozen people were simply wrong Mikko <mikko.levanto@iki.fi> - 2024-06-01 11:23 +0300
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: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years joes <noreply@example.com> - 2024-06-01 19:02 +0000
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years olcott <polcott333@gmail.com> - 2024-06-01 14:58 -0500
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years Richard Damon <richard@damon-family.org> - 2024-06-01 16:28 -0400
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years immibis <news@immibis.com> - 2024-06-01 23:36 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:28 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years immibis <news@immibis.com> - 2024-06-02 12:56 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years Mikko <mikko.levanto@iki.fi> - 2024-06-02 11:08 +0300
Re: Deciders are ONLY accountable for their actual inputs --- olcott <polcott333@gmail.com> - 2024-06-02 08:56 -0500
Re: Deciders are ONLY accountable for their actual inputs --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:39 +0200
Re: Deciders are ONLY accountable for their actual inputs --- olcott <polcott333@gmail.com> - 2024-06-02 13:46 -0500
Re: Deciders are ONLY accountable for their actual inputs --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:57 +0200
Re: Deciders are ONLY accountable for their actual inputs --- olcott <polcott333@gmail.com> - 2024-06-02 14:03 -0500
Re: Deciders are ONLY accountable for their actual inputs --- Richard Damon <richard@damon-family.org> - 2024-06-02 15:16 -0400
Re: Deciders are ONLY accountable for their actual inputs --- immibis <news@immibis.com> - 2024-06-02 21:20 +0200
Re: Deciders are ONLY accountable for their actual inputs --- immibis <news@immibis.com> - 2024-06-02 21:24 +0200
Re: Deciders are ONLY accountable for their actual inputs --- Richard Damon <richard@damon-family.org> - 2024-06-02 15:01 -0400
Re: Deciders are ONLY accountable for their actual inputs --- Mikko <mikko.levanto@iki.fi> - 2024-06-03 13:13 +0300
Re: Deciders are ONLY accountable for their actual inputs --- olcott <polcott333@gmail.com> - 2024-06-03 08:17 -0500
Re: Deciders are ONLY accountable for their actual inputs --- Mikko <mikko.levanto@iki.fi> - 2024-06-03 17:39 +0300
Re: Deciders are ONLY accountable for their actual inputs --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:55 +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 --- 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
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-05-31 16:10 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-31 10:44 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-06-01 11:20 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-06-01 09:52 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-06-01 11:08 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets joes <noreply@example.com> - 2024-06-01 18:56 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-06-01 14:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-06-01 16:29 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-06-01 23:36 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets joes <noreply@example.com> - 2024-06-02 09:24 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-06-02 09:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-06-02 11:24 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-06-02 09:04 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-06-03 13:36 +0300
Page 4 of 19 — ← Prev page 1 2 3 [4] 5 6 … 19 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 21:32 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38ogh$1grj4$1@dont-email.me> |
| In reply to | #105723 |
On 5/29/2024 9:27 PM, Richard Damon wrote:
> On 5/29/24 9:48 PM, olcott wrote:
>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>> On 5/29/24 9:15 PM, olcott wrote:
>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you
>>>>>>>>>>>>>> not to cite his
>>>>>>>>>>>>>> name as a back up for your points. Why do you keep doing it?
>>>>>>>>>>>>>
>>>>>>>>>>>>> He does it to try to rope more people in. It's the same
>>>>>>>>>>>>> ploy as
>>>>>>>>>>>>> insulting people by name. It's hard to ignore being
>>>>>>>>>>>>> maligned in public
>>>>>>>>>>>>> by a fool.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>>>>
>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> I really did believe that Ben Bacarisse was lying when I
>>>>>>>>>>>> said it.
>>>>>>>>>>>>
>>>>>>>>>>>> At the time I was talking about the easily verified fact of
>>>>>>>>>>>> the actual
>>>>>>>>>>>> execution trace of fully operational code and everyone was
>>>>>>>>>>>> denying the
>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>
>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>> 02 {
>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>> 07 }
>>>>>>>>>>>> 08
>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>> 10 {
>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>> 13 }
>>>>>>>>>>>>
>>>>>>>>>>>> It turns out that two dozen people are easily proven wrong when
>>>>>>>>>>>> they claimed that the correct simulation of the input to H(D,D)
>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> How is that?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> When D is correctly simulated by H using an x86 emulator the
>>>>>>>>>>>> only
>>>>>>>>>>>> way that the emulated D can reach its own emulated final state
>>>>>>>>>>>> at line 06 and halt is
>>>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong order
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an
>>>>>>>>>>> input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right the execution trace of D simulated by pure function H using
>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>>>>
>>>>>>>>> So, you aren't going to resolve the question but just keep up
>>>>>>>>> with your contradiction that H is simulating a template (that
>>>>>>>>> doesn't HAVE any instrucitons of H in it) but also DOES
>>>>>>>>> simulate those non-existance instructions by LYING about what
>>>>>>>>> it does and simulating a SPECIFIC instance that it LIES behaves
>>>>>>>>> just like DIFFERENT specific instatces.
>>>>>>>>
>>>>>>>> I will give you the benefit of the doubt and call that an honest
>>>>>>>> misunderstanding. I have much more empathy for you now that I found
>>>>>>>> that Linz really did say words that you could construe as you did.
>>>>>>>>
>>>>>>>> The infinite set of every H/D pair specified by the template
>>>>>>>> where D is correctly simulated by pure simulator H or pure function
>>>>>>>> H never has any D reach its own simulated final state and halt.
>>>>>>>
>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>>>
>>>>>>> This seems to be your blind spot.
>>>>>>
>>>>>> ∃H ∈ Turing_Machines
>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>> ∀y ∈ Finite_Strings
>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>
>>>>>> Not really the above formalization does not can cannot
>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>
>>>>>
>>>>> Then what is x representing?
>>>>
>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>> behavior. The term: "representing" is inaccurate.
>>>>
>>>
>>> No, it specifies the machine, and thus, though that, the behavior.
>>>
>>
>> If we assume that a decider takes an actual Turing machine as its
>> input that is correct otherwise that is one level of indirection
>> away from what we are really looking at.
>>
>> The people have perpetuated this mistake for many decades never
>> actually made it not a mistake.
>>
>
> You need to define what you mean by "Indirection", because you aren't
> using it in the normal manner.
>
I have conclusively proven that the behavior of the correct
simulation of the x86 code of D by pure function H has
different behavior than the direct execution of D(D).
> A complete representation of the Turing Machine is NOT a level of
> Indirection.
>
> Using a "Name" to represent that full description, THAT would be
> indirection.
>
> The x86 code for your functions isn't a level of indirection from the
> function itself.
>
> A word with the address of the function would be.
--
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-05-29 22:55 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38pr0$2fohv$6@i2pn2.org> |
| In reply to | #105724 |
On 5/29/24 10:32 PM, olcott wrote:
> On 5/29/2024 9:27 PM, Richard Damon wrote:
>> On 5/29/24 9:48 PM, olcott wrote:
>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you
>>>>>>>>>>>>>>> not to cite his
>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep doing
>>>>>>>>>>>>>>> it?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> He does it to try to rope more people in. It's the same
>>>>>>>>>>>>>> ploy as
>>>>>>>>>>>>>> insulting people by name. It's hard to ignore being
>>>>>>>>>>>>>> maligned in public
>>>>>>>>>>>>>> by a fool.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>>>>>
>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> I really did believe that Ben Bacarisse was lying when I
>>>>>>>>>>>>> said it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> At the time I was talking about the easily verified fact of
>>>>>>>>>>>>> the actual
>>>>>>>>>>>>> execution trace of fully operational code and everyone was
>>>>>>>>>>>>> denying the
>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>> 08
>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>
>>>>>>>>>>>>> It turns out that two dozen people are easily proven wrong
>>>>>>>>>>>>> when
>>>>>>>>>>>>> they claimed that the correct simulation of the input to
>>>>>>>>>>>>> H(D,D)
>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> How is that?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> When D is correctly simulated by H using an x86 emulator
>>>>>>>>>>>>> the only
>>>>>>>>>>>>> way that the emulated D can reach its own emulated final state
>>>>>>>>>>>>> at line 06 and halt is
>>>>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong order
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an
>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Right the execution trace of D simulated by pure function H
>>>>>>>>>>> using
>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>>>>>
>>>>>>>>>> So, you aren't going to resolve the question but just keep up
>>>>>>>>>> with your contradiction that H is simulating a template (that
>>>>>>>>>> doesn't HAVE any instrucitons of H in it) but also DOES
>>>>>>>>>> simulate those non-existance instructions by LYING about what
>>>>>>>>>> it does and simulating a SPECIFIC instance that it LIES
>>>>>>>>>> behaves just like DIFFERENT specific instatces.
>>>>>>>>>
>>>>>>>>> I will give you the benefit of the doubt and call that an honest
>>>>>>>>> misunderstanding. I have much more empathy for you now that I
>>>>>>>>> found
>>>>>>>>> that Linz really did say words that you could construe as you did.
>>>>>>>>>
>>>>>>>>> The infinite set of every H/D pair specified by the template
>>>>>>>>> where D is correctly simulated by pure simulator H or pure
>>>>>>>>> function
>>>>>>>>> H never has any D reach its own simulated final state and halt.
>>>>>>>>
>>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>>>>
>>>>>>>> This seems to be your blind spot.
>>>>>>>
>>>>>>> ∃H ∈ Turing_Machines
>>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>>> ∀y ∈ Finite_Strings
>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>
>>>>>>> Not really the above formalization does not can cannot
>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>
>>>>>>
>>>>>> Then what is x representing?
>>>>>
>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>> behavior. The term: "representing" is inaccurate.
>>>>>
>>>>
>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>
>>>
>>> If we assume that a decider takes an actual Turing machine as its
>>> input that is correct otherwise that is one level of indirection
>>> away from what we are really looking at.
>>>
>>> The people have perpetuated this mistake for many decades never
>>> actually made it not a mistake.
>>>
>>
>> You need to define what you mean by "Indirection", because you aren't
>> using it in the normal manner.
>>
>
> I have conclusively proven that the behavior of the correct
> simulation of the x86 code of D by pure function H has
> different behavior than the direct execution of D(D).
But the question isn't about the "Correcgt Simulation" and especially
based on YOUR definition. So you haven't proven ANYTHING about the
question except that you don't understand it and are just an ignorant
pathological liar with a reckless disregard for the trutn.
You are just showing that you have successfully brainwashed yourself
into beleiving your own lies.
>
>> A complete representation of the Turing Machine is NOT a level of
>> Indirection.
>>
>> Using a "Name" to represent that full description, THAT would be
>> indirection.
>>
>> The x86 code for your functions isn't a level of indirection from the
>> function itself.
>>
>> A word with the address of the function would be.
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 22:58 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38thu$1hf5c$2@dont-email.me> |
| In reply to | #105727 |
On 5/29/2024 9:55 PM, Richard Damon wrote:
> On 5/29/24 10:32 PM, olcott wrote:
>> On 5/29/2024 9:27 PM, Richard Damon wrote:
>>> On 5/29/24 9:48 PM, olcott wrote:
>>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you
>>>>>>>>>>>>>>>> not to cite his
>>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep
>>>>>>>>>>>>>>>> doing it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> He does it to try to rope more people in. It's the same
>>>>>>>>>>>>>>> ploy as
>>>>>>>>>>>>>>> insulting people by name. It's hard to ignore being
>>>>>>>>>>>>>>> maligned in public
>>>>>>>>>>>>>>> by a fool.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really did believe that Ben Bacarisse was lying when I
>>>>>>>>>>>>>> said it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At the time I was talking about the easily verified fact
>>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>>> execution trace of fully operational code and everyone was
>>>>>>>>>>>>>> denying the
>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It turns out that two dozen people are easily proven wrong
>>>>>>>>>>>>>> when
>>>>>>>>>>>>>> they claimed that the correct simulation of the input to
>>>>>>>>>>>>>> H(D,D)
>>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> How is that?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> When D is correctly simulated by H using an x86 emulator
>>>>>>>>>>>>>> the only
>>>>>>>>>>>>>> way that the emulated D can reach its own emulated final
>>>>>>>>>>>>>> state
>>>>>>>>>>>>>> at line 06 and halt is
>>>>>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong order
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an
>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Right the execution trace of D simulated by pure function H
>>>>>>>>>>>> using
>>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>>>>>>
>>>>>>>>>>> So, you aren't going to resolve the question but just keep up
>>>>>>>>>>> with your contradiction that H is simulating a template (that
>>>>>>>>>>> doesn't HAVE any instrucitons of H in it) but also DOES
>>>>>>>>>>> simulate those non-existance instructions by LYING about what
>>>>>>>>>>> it does and simulating a SPECIFIC instance that it LIES
>>>>>>>>>>> behaves just like DIFFERENT specific instatces.
>>>>>>>>>>
>>>>>>>>>> I will give you the benefit of the doubt and call that an honest
>>>>>>>>>> misunderstanding. I have much more empathy for you now that I
>>>>>>>>>> found
>>>>>>>>>> that Linz really did say words that you could construe as you
>>>>>>>>>> did.
>>>>>>>>>>
>>>>>>>>>> The infinite set of every H/D pair specified by the template
>>>>>>>>>> where D is correctly simulated by pure simulator H or pure
>>>>>>>>>> function
>>>>>>>>>> H never has any D reach its own simulated final state and halt.
>>>>>>>>>
>>>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>>>>>
>>>>>>>>> This seems to be your blind spot.
>>>>>>>>
>>>>>>>> ∃H ∈ Turing_Machines
>>>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>>>> ∀y ∈ Finite_Strings
>>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>>
>>>>>>>> Not really the above formalization does not can cannot
>>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>>
>>>>>>>
>>>>>>> Then what is x representing?
>>>>>>
>>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>>> behavior. The term: "representing" is inaccurate.
>>>>>>
>>>>>
>>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>>
>>>>
>>>> If we assume that a decider takes an actual Turing machine as its
>>>> input that is correct otherwise that is one level of indirection
>>>> away from what we are really looking at.
>>>>
>>>> The people have perpetuated this mistake for many decades never
>>>> actually made it not a mistake.
>>>>
>>>
>>> You need to define what you mean by "Indirection", because you aren't
>>> using it in the normal manner.
>>>
>>
>> I have conclusively proven that the behavior of the correct
>> simulation of the x86 code of D by pure function H has
>> different behavior than the direct execution of D(D).
>
> But the question isn't about the "Correcgt Simulation" and especially
> based on YOUR definition. So you haven't proven ANYTHING about the
> question except that you don't understand it and are just an ignorant
> pathological liar with a reckless disregard for the trutn.
>
> You are just showing that you have successfully brainwashed yourself
> into beleiving your own lies.
>
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int H(ptr p, ptr i);
01 int D(ptr p)
02 {
03 int Halt_Status = H(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 H(D,D);
12 return 0;
13 }
Like I said *Try and Prove otherwise*
The actual fully operational code DOES INVOKE RECURSIVE SIMULATION.
Begin Local Halt Decider Simulation Execution Trace Stored at:113075
[00001c22][00113061][00113065] 55 push ebp
[00001c23][00113061][00113065] 8bec mov ebp,esp
[00001c25][0011305d][00103031] 51 push ecx
[00001c26][0011305d][00103031] 8b4508 mov eax,[ebp+08]
[00001c29][00113059][00001c22] 50 push eax ; push DD
[00001c2a][00113059][00001c22] 8b4d08 mov ecx,[ebp+08]
[00001c2d][00113055][00001c22] 51 push ecx ; push DD
[00001c2e][00113051][00001c33] e80ff7ffff call 00001342 ; call HH
New slave_stack at:14da95
[00001c22][0015da89][0015da8d] 55 push ebp
[00001c23][0015da89][0015da8d] 8bec mov ebp,esp
[00001c25][0015da85][0014da59] 51 push ecx
[00001c26][0015da85][0014da59] 8b4508 mov eax,[ebp+08]
[00001c29][0015da81][00001c22] 50 push eax ; push DD
[00001c2a][0015da81][00001c22] 8b4d08 mov ecx,[ebp+08]
[00001c2d][0015da7d][00001c22] 51 push ecx ; push DD
[00001c2e][0015da79][00001c33] e80ff7ffff call 00001342 ; call HH
Local Halt Decider: Recursive Simulation Detected Simulation Stopped
--
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-05-30 07:30 -0400 |
| Subject | Re: Olcott was simply wrong --- Try to prove otherwise |
| Message-ID | <v39o04$2h667$1@i2pn2.org> |
| In reply to | #105729 |
On 5/29/24 11:58 PM, olcott wrote:
> On 5/29/2024 9:55 PM, Richard Damon wrote:
>> On 5/29/24 10:32 PM, olcott wrote:
>>> On 5/29/2024 9:27 PM, Richard Damon wrote:
>>>> On 5/29/24 9:48 PM, olcott wrote:
>>>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked
>>>>>>>>>>>>>>>>> you not to cite his
>>>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep
>>>>>>>>>>>>>>>>> doing it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> He does it to try to rope more people in. It's the same
>>>>>>>>>>>>>>>> ploy as
>>>>>>>>>>>>>>>> insulting people by name. It's hard to ignore being
>>>>>>>>>>>>>>>> maligned in public
>>>>>>>>>>>>>>>> by a fool.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I really did believe that Ben Bacarisse was lying when I
>>>>>>>>>>>>>>> said it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> At the time I was talking about the easily verified fact
>>>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>>>> execution trace of fully operational code and everyone
>>>>>>>>>>>>>>> was denying the
>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>>> in C
>>>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It turns out that two dozen people are easily proven
>>>>>>>>>>>>>>> wrong when
>>>>>>>>>>>>>>> they claimed that the correct simulation of the input to
>>>>>>>>>>>>>>> H(D,D)
>>>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How is that?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When D is correctly simulated by H using an x86 emulator
>>>>>>>>>>>>>>> the only
>>>>>>>>>>>>>>> way that the emulated D can reach its own emulated final
>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>> at line 06 and halt is
>>>>>>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong order
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an
>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right the execution trace of D simulated by pure function H
>>>>>>>>>>>>> using
>>>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>>>>>> simulated final state and halt or the simulation of the
>>>>>>>>>>>>> machine
>>>>>>>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>>>>>>>
>>>>>>>>>>>> So, you aren't going to resolve the question but just keep
>>>>>>>>>>>> up with your contradiction that H is simulating a template
>>>>>>>>>>>> (that doesn't HAVE any instrucitons of H in it) but also
>>>>>>>>>>>> DOES simulate those non-existance instructions by LYING
>>>>>>>>>>>> about what it does and simulating a SPECIFIC instance that
>>>>>>>>>>>> it LIES behaves just like DIFFERENT specific instatces.
>>>>>>>>>>>
>>>>>>>>>>> I will give you the benefit of the doubt and call that an honest
>>>>>>>>>>> misunderstanding. I have much more empathy for you now that I
>>>>>>>>>>> found
>>>>>>>>>>> that Linz really did say words that you could construe as you
>>>>>>>>>>> did.
>>>>>>>>>>>
>>>>>>>>>>> The infinite set of every H/D pair specified by the template
>>>>>>>>>>> where D is correctly simulated by pure simulator H or pure
>>>>>>>>>>> function
>>>>>>>>>>> H never has any D reach its own simulated final state and halt.
>>>>>>>>>>
>>>>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>>>>>>
>>>>>>>>>> This seems to be your blind spot.
>>>>>>>>>
>>>>>>>>> ∃H ∈ Turing_Machines
>>>>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>>>>> ∀y ∈ Finite_Strings
>>>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>>>
>>>>>>>>> Not really the above formalization does not can cannot
>>>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then what is x representing?
>>>>>>>
>>>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>>>> behavior. The term: "representing" is inaccurate.
>>>>>>>
>>>>>>
>>>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>>>
>>>>>
>>>>> If we assume that a decider takes an actual Turing machine as its
>>>>> input that is correct otherwise that is one level of indirection
>>>>> away from what we are really looking at.
>>>>>
>>>>> The people have perpetuated this mistake for many decades never
>>>>> actually made it not a mistake.
>>>>>
>>>>
>>>> You need to define what you mean by "Indirection", because you
>>>> aren't using it in the normal manner.
>>>>
>>>
>>> I have conclusively proven that the behavior of the correct
>>> simulation of the x86 code of D by pure function H has
>>> different behavior than the direct execution of D(D).
>>
>> But the question isn't about the "Correcgt Simulation" and especially
>> based on YOUR definition. So you haven't proven ANYTHING about the
>> question except that you don't understand it and are just an ignorant
>> pathological liar with a reckless disregard for the trutn.
>>
>> You are just showing that you have successfully brainwashed yourself
>> into beleiving your own lies.
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int H(ptr p, ptr i);
> 01 int D(ptr p)
> 02 {
> 03 int Halt_Status = H(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 H(D,D);
> 12 return 0;
> 13 }
>
> Like I said *Try and Prove otherwise*
> The actual fully operational code DOES INVOKE RECURSIVE SIMULATION.
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:113075
> [00001c22][00113061][00113065] 55 push ebp
> [00001c23][00113061][00113065] 8bec mov ebp,esp
> [00001c25][0011305d][00103031] 51 push ecx
> [00001c26][0011305d][00103031] 8b4508 mov eax,[ebp+08]
> [00001c29][00113059][00001c22] 50 push eax ; push DD
> [00001c2a][00113059][00001c22] 8b4d08 mov ecx,[ebp+08]
> [00001c2d][00113055][00001c22] 51 push ecx ; push DD
> [00001c2e][00113051][00001c33] e80ff7ffff call 00001342 ; call HH
> New slave_stack at:14da95
The following doesn't actually happen per your latest definitions.
call HH needs be followed by the instructions of HH that are being
simulated.
I guess you are just admitting that you are nothing but a LIAR.
Maybe you just don't understand what the words you use actuually mean.
> [00001c22][0015da89][0015da8d] 55 push ebp
> [00001c23][0015da89][0015da8d] 8bec mov ebp,esp
> [00001c25][0015da85][0014da59] 51 push ecx
> [00001c26][0015da85][0014da59] 8b4508 mov eax,[ebp+08]
> [00001c29][0015da81][00001c22] 50 push eax ; push DD
> [00001c2a][0015da81][00001c22] 8b4d08 mov ecx,[ebp+08]
> [00001c2d][0015da7d][00001c22] 51 push ecx ; push DD
> [00001c2e][0015da79][00001c33] e80ff7ffff call 00001342 ; call HH
> Local Halt Decider: Recursive Simulation Detected Simulation Stopped
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-30 09:04 -0500 |
| Subject | Re: Olcott was simply wrong --- Try to prove otherwise |
| Message-ID | <v3a11j$1ni4n$1@dont-email.me> |
| In reply to | #105740 |
On 5/30/2024 6:30 AM, Richard Damon wrote:
> On 5/29/24 11:58 PM, olcott wrote:
>> On 5/29/2024 9:55 PM, Richard Damon wrote:
>>> On 5/29/24 10:32 PM, olcott wrote:
>>>> On 5/29/2024 9:27 PM, Richard Damon wrote:
>>>>> On 5/29/24 9:48 PM, olcott wrote:
>>>>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked
>>>>>>>>>>>>>>>>>> you not to cite his
>>>>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep
>>>>>>>>>>>>>>>>>> doing it?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> He does it to try to rope more people in. It's the
>>>>>>>>>>>>>>>>> same ploy as
>>>>>>>>>>>>>>>>> insulting people by name. It's hard to ignore being
>>>>>>>>>>>>>>>>> maligned in public
>>>>>>>>>>>>>>>>> by a fool.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I really did believe that Ben Bacarisse was lying when I
>>>>>>>>>>>>>>>> said it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> At the time I was talking about the easily verified fact
>>>>>>>>>>>>>>>> of the actual
>>>>>>>>>>>>>>>> execution trace of fully operational code and everyone
>>>>>>>>>>>>>>>> was denying the
>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>>>> in C
>>>>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It turns out that two dozen people are easily proven
>>>>>>>>>>>>>>>> wrong when
>>>>>>>>>>>>>>>> they claimed that the correct simulation of the input to
>>>>>>>>>>>>>>>> H(D,D)
>>>>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How is that?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When D is correctly simulated by H using an x86 emulator
>>>>>>>>>>>>>>>> the only
>>>>>>>>>>>>>>>> way that the emulated D can reach its own emulated final
>>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>>> at line 06 and halt is
>>>>>>>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong
>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of
>>>>>>>>>>>>>>> an input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right the execution trace of D simulated by pure function
>>>>>>>>>>>>>> H using
>>>>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its
>>>>>>>>>>>>>> own
>>>>>>>>>>>>>> simulated final state and halt or the simulation of the
>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, you aren't going to resolve the question but just keep
>>>>>>>>>>>>> up with your contradiction that H is simulating a template
>>>>>>>>>>>>> (that doesn't HAVE any instrucitons of H in it) but also
>>>>>>>>>>>>> DOES simulate those non-existance instructions by LYING
>>>>>>>>>>>>> about what it does and simulating a SPECIFIC instance that
>>>>>>>>>>>>> it LIES behaves just like DIFFERENT specific instatces.
>>>>>>>>>>>>
>>>>>>>>>>>> I will give you the benefit of the doubt and call that an
>>>>>>>>>>>> honest
>>>>>>>>>>>> misunderstanding. I have much more empathy for you now that
>>>>>>>>>>>> I found
>>>>>>>>>>>> that Linz really did say words that you could construe as
>>>>>>>>>>>> you did.
>>>>>>>>>>>>
>>>>>>>>>>>> The infinite set of every H/D pair specified by the template
>>>>>>>>>>>> where D is correctly simulated by pure simulator H or pure
>>>>>>>>>>>> function
>>>>>>>>>>>> H never has any D reach its own simulated final state and halt.
>>>>>>>>>>>
>>>>>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>>>>>>>
>>>>>>>>>>> This seems to be your blind spot.
>>>>>>>>>>
>>>>>>>>>> ∃H ∈ Turing_Machines
>>>>>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>>>>>> ∀y ∈ Finite_Strings
>>>>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>>>>
>>>>>>>>>> Not really the above formalization does not can cannot
>>>>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then what is x representing?
>>>>>>>>
>>>>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>>>>> behavior. The term: "representing" is inaccurate.
>>>>>>>>
>>>>>>>
>>>>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>>>>
>>>>>>
>>>>>> If we assume that a decider takes an actual Turing machine as its
>>>>>> input that is correct otherwise that is one level of indirection
>>>>>> away from what we are really looking at.
>>>>>>
>>>>>> The people have perpetuated this mistake for many decades never
>>>>>> actually made it not a mistake.
>>>>>>
>>>>>
>>>>> You need to define what you mean by "Indirection", because you
>>>>> aren't using it in the normal manner.
>>>>>
>>>>
>>>> I have conclusively proven that the behavior of the correct
>>>> simulation of the x86 code of D by pure function H has
>>>> different behavior than the direct execution of D(D).
>>>
>>> But the question isn't about the "Correcgt Simulation" and especially
>>> based on YOUR definition. So you haven't proven ANYTHING about the
>>> question except that you don't understand it and are just an ignorant
>>> pathological liar with a reckless disregard for the trutn.
>>>
>>> You are just showing that you have successfully brainwashed yourself
>>> into beleiving your own lies.
>>>
>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C
>> 00 int H(ptr p, ptr i);
>> 01 int D(ptr p)
>> 02 {
>> 03 int Halt_Status = H(p, p);
>> 04 if (Halt_Status)
>> 05 HERE: goto HERE;
>> 06 return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11 H(D,D);
>> 12 return 0;
>> 13 }
>>
>> Like I said *Try and Prove otherwise*
>> The actual fully operational code DOES INVOKE RECURSIVE SIMULATION.
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:113075
>> [00001c22][00113061][00113065] 55 push ebp
>> [00001c23][00113061][00113065] 8bec mov ebp,esp
>> [00001c25][0011305d][00103031] 51 push ecx
>> [00001c26][0011305d][00103031] 8b4508 mov eax,[ebp+08]
>> [00001c29][00113059][00001c22] 50 push eax ; push DD
>> [00001c2a][00113059][00001c22] 8b4d08 mov ecx,[ebp+08]
>> [00001c2d][00113055][00001c22] 51 push ecx ; push DD
>> [00001c2e][00113051][00001c33] e80ff7ffff call 00001342 ; call HH
>> New slave_stack at:14da95
>
> The following doesn't actually happen per your latest definitions.
>
Sure it does try and prove otherwise.
> call HH needs be followed by the instructions of HH that are being
> simulated.
>
It does I just screen out the 250 pages of them so that we
can see exactly what D is doing. We have no actual need to
see these pages because the fact that D is correctly simulated
by H is proven by the provided execution trace of D.
> I guess you are just admitting that you are nothing but a LIAR.
>
*Please quit calling me a Liar. Others here have called you out on this*
Calling me a liar without even being able to point out any mistake is a
pitiful lack of professional decorum.
The professional way to handle this is this:
I believe that you are mistaken here is the mistake and
here are the reasons why I believe it is a mistake.
In some cases just calling someone a liar without even showing
that they are incorrect could result in monetary damages.
This just cost Fox "fake" news $787 million.
> Maybe you just don't understand what the words you use actuually mean.
>
What I actually found (and it was very reassuring) is that *you* don't
know what my words mean. It is very reassuring because now I know what
I was mistaking for head games and deception on your part was actually
ordinary misunderstanding.
*Don't call me a liar, and don't even say that I am incorrect*
*until after you point out the exact error AND and provide the*
*complete reasoning why you believe it is an error*
On the very rare occasions where you did this we found that it
was your own misunderstanding all along.
--
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-05-30 21:37 -0400 |
| Subject | Re: Olcott was simply wrong --- Try to prove otherwise |
| Message-ID | <v3b9kl$2im02$2@i2pn2.org> |
| In reply to | #105750 |
On 5/30/24 10:04 AM, olcott wrote:
> On 5/30/2024 6:30 AM, Richard Damon wrote:
>> On 5/29/24 11:58 PM, olcott wrote:
>>> On 5/29/2024 9:55 PM, Richard Damon wrote:
>>>> On 5/29/24 10:32 PM, olcott wrote:
>>>>> On 5/29/2024 9:27 PM, Richard Damon wrote:
>>>>>> On 5/29/24 9:48 PM, olcott wrote:
>>>>>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>>>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked
>>>>>>>>>>>>>>>>>>> you not to cite his
>>>>>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep
>>>>>>>>>>>>>>>>>>> doing it?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> He does it to try to rope more people in. It's the
>>>>>>>>>>>>>>>>>> same ploy as
>>>>>>>>>>>>>>>>>> insulting people by name. It's hard to ignore being
>>>>>>>>>>>>>>>>>> maligned in public
>>>>>>>>>>>>>>>>>> by a fool.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I really did believe that Ben Bacarisse was lying when
>>>>>>>>>>>>>>>>> I said it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> At the time I was talking about the easily verified
>>>>>>>>>>>>>>>>> fact of the actual
>>>>>>>>>>>>>>>>> execution trace of fully operational code and everyone
>>>>>>>>>>>>>>>>> was denying the
>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int
>>>>>>>>>>>>>>>>> function in C
>>>>>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It turns out that two dozen people are easily proven
>>>>>>>>>>>>>>>>> wrong when
>>>>>>>>>>>>>>>>> they claimed that the correct simulation of the input
>>>>>>>>>>>>>>>>> to H(D,D)
>>>>>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> How is that?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When D is correctly simulated by H using an x86
>>>>>>>>>>>>>>>>> emulator the only
>>>>>>>>>>>>>>>>> way that the emulated D can reach its own emulated
>>>>>>>>>>>>>>>>> final state
>>>>>>>>>>>>>>>>> at line 06 and halt is
>>>>>>>>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong
>>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition
>>>>>>>>>>>>>>>> that allow the relating of a "Simulation" to the
>>>>>>>>>>>>>>>> behavior of an input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right the execution trace of D simulated by pure function
>>>>>>>>>>>>>>> H using
>>>>>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach
>>>>>>>>>>>>>>> its own
>>>>>>>>>>>>>>> simulated final state and halt or the simulation of the
>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you aren't going to resolve the question but just keep
>>>>>>>>>>>>>> up with your contradiction that H is simulating a template
>>>>>>>>>>>>>> (that doesn't HAVE any instrucitons of H in it) but also
>>>>>>>>>>>>>> DOES simulate those non-existance instructions by LYING
>>>>>>>>>>>>>> about what it does and simulating a SPECIFIC instance that
>>>>>>>>>>>>>> it LIES behaves just like DIFFERENT specific instatces.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will give you the benefit of the doubt and call that an
>>>>>>>>>>>>> honest
>>>>>>>>>>>>> misunderstanding. I have much more empathy for you now that
>>>>>>>>>>>>> I found
>>>>>>>>>>>>> that Linz really did say words that you could construe as
>>>>>>>>>>>>> you did.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The infinite set of every H/D pair specified by the template
>>>>>>>>>>>>> where D is correctly simulated by pure simulator H or pure
>>>>>>>>>>>>> function
>>>>>>>>>>>>> H never has any D reach its own simulated final state and
>>>>>>>>>>>>> halt.
>>>>>>>>>>>>
>>>>>>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>>>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>>>>>>>>
>>>>>>>>>>>> This seems to be your blind spot.
>>>>>>>>>>>
>>>>>>>>>>> ∃H ∈ Turing_Machines
>>>>>>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>>>>>>> ∀y ∈ Finite_Strings
>>>>>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>>>>>
>>>>>>>>>>> Not really the above formalization does not can cannot
>>>>>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then what is x representing?
>>>>>>>>>
>>>>>>>>> x <is> a finite string Turing machine description that
>>>>>>>>> SPECIFIES behavior. The term: "representing" is inaccurate.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>>>>>
>>>>>>>
>>>>>>> If we assume that a decider takes an actual Turing machine as its
>>>>>>> input that is correct otherwise that is one level of indirection
>>>>>>> away from what we are really looking at.
>>>>>>>
>>>>>>> The people have perpetuated this mistake for many decades never
>>>>>>> actually made it not a mistake.
>>>>>>>
>>>>>>
>>>>>> You need to define what you mean by "Indirection", because you
>>>>>> aren't using it in the normal manner.
>>>>>>
>>>>>
>>>>> I have conclusively proven that the behavior of the correct
>>>>> simulation of the x86 code of D by pure function H has
>>>>> different behavior than the direct execution of D(D).
>>>>
>>>> But the question isn't about the "Correcgt Simulation" and
>>>> especially based on YOUR definition. So you haven't proven ANYTHING
>>>> about the question except that you don't understand it and are just
>>>> an ignorant pathological liar with a reckless disregard for the trutn.
>>>>
>>>> You are just showing that you have successfully brainwashed yourself
>>>> into beleiving your own lies.
>>>>
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int H(ptr p, ptr i);
>>> 01 int D(ptr p)
>>> 02 {
>>> 03 int Halt_Status = H(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11 H(D,D);
>>> 12 return 0;
>>> 13 }
>>>
>>> Like I said *Try and Prove otherwise*
>>> The actual fully operational code DOES INVOKE RECURSIVE SIMULATION.
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:113075
>>> [00001c22][00113061][00113065] 55 push ebp
>>> [00001c23][00113061][00113065] 8bec mov ebp,esp
>>> [00001c25][0011305d][00103031] 51 push ecx
>>> [00001c26][0011305d][00103031] 8b4508 mov eax,[ebp+08]
>>> [00001c29][00113059][00001c22] 50 push eax ; push DD
>>> [00001c2a][00113059][00001c22] 8b4d08 mov ecx,[ebp+08]
>>> [00001c2d][00113055][00001c22] 51 push ecx ; push DD
>>> [00001c2e][00113051][00001c33] e80ff7ffff call 00001342 ; call HH
>>> New slave_stack at:14da95
>>
>> The following doesn't actually happen per your latest definitions.
>>
>
> Sure it does try and prove otherwise.
Since YOUR DEFINITION of a correct simulation says it follows the exact
sequence of x86 instructions, GOING INTO H.
So, the call HH must be followd
>
>> call HH needs be followed by the instructions of HH that are being
>> simulated.
>>
>
> It does I just screen out the 250 pages of them so that we
> can see exactly what D is doing. We have no actual need to
> see these pages because the fact that D is correctly simulated
> by H is proven by the provided execution trace of D.
And thus you LIE and commit logic errors as the two are not equivalent.
>
>> I guess you are just admitting that you are nothing but a LIAR.
>>
>
> *Please quit calling me a Liar. Others here have called you out on this*
> Calling me a liar without even being able to point out any mistake is a
> pitiful lack of professional decorum.
I will point out that YOU started it.
>
> The professional way to handle this is this:
> I believe that you are mistaken here is the mistake and
> here are the reasons why I believe it is a mistake.
But you don't listen to that.
Tell you want, if you will start actually ANSWERING the errors pointed
out, and stop just repeating your FALSE STATEMENTS, I will stop calling
you a LIAR, (but will continue to point out statement you make that are
clear lies, if they have already been pointed out in the past, so it
can't be an "honest mistake"
Note, you need to make a clear and unambigous promise to not repeat
statments that have had errors pointed out in them, EVEN IF YOU DON'T
SEE THE ERROR, until that is resolved.
No claiming you can't get side-tracked, if your arguement depends on a
statement that has been questioned, you can't just leave that behind.
Note, this means you can't say the refutation is just wrong because you
must be right, you need to SHOW why you are right, with ACTUAL SOURCES
for you claims.
>
> In some cases just calling someone a liar without even showing
> that they are incorrect could result in monetary damages.
> This just cost Fox "fake" news $787 million.
Except that every time I have called you a liar, it is after pointing
out the lie you have repeated.
>
>> Maybe you just don't understand what the words you use actuually mean.
>>
>
> What I actually found (and it was very reassuring) is that *you* don't
> know what my words mean. It is very reassuring because now I know what
> I was mistaking for head games and deception on your part was actually
> ordinary misunderstanding.
I don't think YOU know what your words mean. You clearly don't know what
the words mean as terms of the art.
>
> *Don't call me a liar, and don't even say that I am incorrect*
> *until after you point out the exact error AND and provide the*
> *complete reasoning why you believe it is an error*
I have, many times, and you just ignore it.
>
> On the very rare occasions where you did this we found that it
> was your own misunderstanding all along.
>
Nope.
I will point out that you have admitted to having a mental disorder that
gives you incorrect and only partial understanding of the world around
you. It is incumberant on YOU to be mindful of this and not just ignore
the facts that you don't want to face.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-05-30 09:08 +0000 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v39fll$2grvb$2@i2pn2.org> |
| In reply to | #105724 |
Am Wed, 29 May 2024 21:32:49 -0500 schrieb olcott:
> On 5/29/2024 9:27 PM, Richard Damon wrote:
>> On 5/29/24 9:48 PM, olcott wrote:
>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you
>>>>>>>>>>>>>>> not to cite his
>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep doing it?
>>>>>>>>>>>>> It turns out that two dozen people are easily proven wrong when
>>>>>>>>>>>>> they claimed that the correct simulation of the input to H(D,D)
>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>
>>>>>>>>>>>> How is that?
>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an
>>>>>>>>>>>> input.
>>>>>>>>>>> Right the execution trace of D simulated by pure function H using
>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>>>>>> language of D is incorrect or in the wrong order.
Or aborts prematurely.
>>>>>>>>>> So, you aren't going to resolve the question but just keep up
>>>>>>>>>> with your contradiction that H is simulating a template (that
>>>>>>>>>> doesn't HAVE any instrucitons of H in it) but also DOES
>>>>>>>>>> simulate those non-existance instructions by LYING about what
>>>>>>>>>> it does and simulating a SPECIFIC instance that it LIES behaves
>>>>>>>>>> just like DIFFERENT specific instatces.
>>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>>> behavior of the actual PROGRAM/MACHINE D
Which should be the same.
>>>>>>>> This seems to be your blind spot.
>>>>>>> ∃H ∈ Turing_Machines
>>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>>> ∀y ∈ Finite_Strings
>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>
>>>>>>> Not really the above formalization does not can cannot
>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>
>>>>>> Then what is x representing?
>>>>>
>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>> behavior. The term: "representing" is inaccurate.
What’s the difference?
>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>
>>> If we assume that a decider takes an actual Turing machine as its
>>> input that is correct otherwise that is one level of indirection
>>> away from what we are really looking at.
>>>
>>> The people have perpetuated this mistake for many decades never
>>> actually made it not a mistake.
>> You need to define what you mean by "Indirection", because you aren't
>> using it in the normal manner.
>
> I have conclusively proven that the behavior of the correct
> simulation of the x86 code of D by pure function H has
> different behavior than the direct execution of D(D).
Then H is not a correct simulator.
--
joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-30 08:21 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v39uh1$1mtd9$4@dont-email.me> |
| In reply to | #105732 |
On 5/30/2024 4:08 AM, joes wrote:
> Am Wed, 29 May 2024 21:32:49 -0500 schrieb olcott:
>> On 5/29/2024 9:27 PM, Richard Damon wrote:
>>> On 5/29/24 9:48 PM, olcott wrote:
>>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you
>>>>>>>>>>>>>>>> not to cite his
>>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep doing it?
>
>>>>>>>>>>>>>> It turns out that two dozen people are easily proven wrong when
>>>>>>>>>>>>>> they claimed that the correct simulation of the input to H(D,D)
>>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>>
>>>>>>>>>>>>> How is that?
>
>>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an
>>>>>>>>>>>>> input.
>>>>>>>>>>>> Right the execution trace of D simulated by pure function H using
>>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>>>>>>> language of D is incorrect or in the wrong order.
> Or aborts prematurely.
>
It has already been acknowledged when D is correctly simulated by
pure simulator H that D never reaches its own simulated final state
and halts after an infinite number of steps of correct simulation.
When an infinite number of steps is not enough then less than an
infinite number of steps cannot help.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-05-31 11:08 +0300 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3c0il$256o0$1@dont-email.me> |
| In reply to | #105732 |
On 2024-05-30 09:08:05 +0000, joes said:
> Am Wed, 29 May 2024 21:32:49 -0500 schrieb olcott:
>> On 5/29/2024 9:27 PM, Richard Damon wrote:
>>> On 5/29/24 9:48 PM, olcott wrote:
>>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you
>>>>>>>>>>>>>>>> not to cite his
>>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep doing it?
>
>>>>>>>>>>>>>> It turns out that two dozen people are easily proven wrong when
>>>>>>>>>>>>>> they claimed that the correct simulation of the input to H(D,D)
>>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>>
>>>>>>>>>>>>> How is that?
>
>>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an
>>>>>>>>>>>>> input.
>>>>>>>>>>>> Right the execution trace of D simulated by pure function H using
>>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>>>>>>> language of D is incorrect or in the wrong order.
> Or aborts prematurely.
>
>>>>>>>>>>> So, you aren't going to resolve the question but just keep up
>>>>>>>>>>> with your contradiction that H is simulating a template (that
>>>>>>>>>>> doesn't HAVE any instrucitons of H in it) but also DOES
>>>>>>>>>>> simulate those non-existance instructions by LYING about what
>>>>>>>>>>> it does and simulating a SPECIFIC instance that it LIES behaves
>>>>>>>>>>> just like DIFFERENT specific instatces.
>
>>>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>>>> behavior of the actual PROGRAM/MACHINE D
> Which should be the same.
>>>>>>>>> This seems to be your blind spot.
>
>>>>>>>> ∃H ∈ Turing_Machines
>>>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>>>> ∀y ∈ Finite_Strings
>>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>>
>>>>>>>> Not really the above formalization does not can cannot
>>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>>
>>>>>>> Then what is x representing?
>>>>>>
>>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>>> behavior. The term: "representing" is inaccurate.
> What’s the difference?
>
>>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>>
>>>> If we assume that a decider takes an actual Turing machine as its
>>>> input that is correct otherwise that is one level of indirection
>>>> away from what we are really looking at.
>>>>
>>>> The people have perpetuated this mistake for many decades never
>>>> actually made it not a mistake.
>
>
>>> You need to define what you mean by "Indirection", because you aren't
>>> using it in the normal manner.
>>
>> I have conclusively proven that the behavior of the correct
>> simulation of the x86 code of D by pure function H has
>> different behavior than the direct execution of D(D).
> Then H is not a correct simulator.
Either that or the correct simulation of the x86 of D by pure function
H does not exists. If you ensure that H is not a pure functin or
that H never performs a correct simulation of D you can say whatever
you want about the impossible simulation, for example that it
is yellow.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-31 10:04 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- Mike Terry |
| Message-ID | <v3cotd$297ao$1@dont-email.me> |
| In reply to | #105801 |
On 5/31/2024 3:08 AM, Mikko wrote:
> On 2024-05-30 09:08:05 +0000, joes said:
>
>> Am Wed, 29 May 2024 21:32:49 -0500 schrieb olcott:
>>> On 5/29/2024 9:27 PM, Richard Damon wrote:
>>>> On 5/29/24 9:48 PM, olcott wrote:
>>>>> On 5/29/2024 8:24 PM, Richard Damon wrote:
>>>>>> On 5/29/24 9:15 PM, olcott wrote:
>>>>>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>>>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you
>>>>>>>>>>>>>>>>> not to cite his
>>>>>>>>>>>>>>>>> name as a back up for your points. Why do you keep
>>>>>>>>>>>>>>>>> doing it?
>>
>>>>>>>>>>>>>>> It turns out that two dozen people are easily proven
>>>>>>>>>>>>>>> wrong when
>>>>>>>>>>>>>>> they claimed that the correct simulation of the input to
>>>>>>>>>>>>>>> H(D,D)
>>>>>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How is that?
>>
>>>>>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an
>>>>>>>>>>>>>> input.
>>>>>>>>>>>>> Right the execution trace of D simulated by pure function H
>>>>>>>>>>>>> using
>>>>>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>>>>>> simulated final state and halt or the simulation of the
>>>>>>>>>>>>> machine
>>>>>>>>>>>>> language of D is incorrect or in the wrong order.
>> Or aborts prematurely.
>>
>>>>>>>>>>>> So, you aren't going to resolve the question but just keep up
>>>>>>>>>>>> with your contradiction that H is simulating a template (that
>>>>>>>>>>>> doesn't HAVE any instrucitons of H in it) but also DOES
>>>>>>>>>>>> simulate those non-existance instructions by LYING about what
>>>>>>>>>>>> it does and simulating a SPECIFIC instance that it LIES behaves
>>>>>>>>>>>> just like DIFFERENT specific instatces.
>>
>>>>>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>>>>>> behavior of the actual PROGRAM/MACHINE D
>> Which should be the same.
>>>>>>>>>> This seems to be your blind spot.
>>
>>>>>>>>> ∃H ∈ Turing_Machines
>>>>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>>>>> ∀y ∈ Finite_Strings
>>>>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>>>>
>>>>>>>>> Not really the above formalization does not can cannot
>>>>>>>>> specify Turing Machines as the input to any decider H.
>>>>>>>>>
>>>>>>>> Then what is x representing?
>>>>>>>
>>>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>>>> behavior. The term: "representing" is inaccurate.
>> What’s the difference?
>>
>>>>>> No, it specifies the machine, and thus, though that, the behavior.
>>>>>>
>>>>> If we assume that a decider takes an actual Turing machine as its
>>>>> input that is correct otherwise that is one level of indirection
>>>>> away from what we are really looking at.
>>>>>
>>>>> The people have perpetuated this mistake for many decades never
>>>>> actually made it not a mistake.
>>
>>
>>>> You need to define what you mean by "Indirection", because you aren't
>>>> using it in the normal manner.
>>>
>>> I have conclusively proven that the behavior of the correct
>>> simulation of the x86 code of D by pure function H has
>>> different behavior than the direct execution of D(D).
>> Then H is not a correct simulator.
>
> Either that or the correct simulation of the x86 of D by pure function
> H does not exists. If you ensure that H is not a pure functin or
> that H never performs a correct simulation of D you can say whatever
> you want about the impossible simulation, for example that it
> is yellow.
>
*I proved that Mike Terry is wrong and he simply ignored the proof*
*I proved that Mike Terry is wrong and he simply ignored the proof*
*I proved that Mike Terry is wrong and he simply ignored the proof*
http://al.howardknight.net/?STYPE=msgid&MSGI=%3CS8CcnRadHexfe8X7nZ2dnZfqnPqdnZ2d%40brightview.co.uk%3E+
"...the Turing machine will halt whenever it enters a final state."
Linz(1990:234)
DD correctly emulated by HH with an x86 emulator cannot possibly
reach its own final state at machine address 00001c47 in any finite
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]
*The Provably Correct Execution Trace that Mike Terry Ignored*
*The Provably Correct Execution Trace that Mike Terry Ignored*
*The Provably Correct Execution Trace that Mike Terry Ignored*
Begin Local Halt Decider Simulation Execution Trace Stored at:113075
[00001c22][00113061][00113065] 55 push ebp
[00001c23][00113061][00113065] 8bec mov ebp,esp
[00001c25][0011305d][00103031] 51 push ecx
[00001c26][0011305d][00103031] 8b4508 mov eax,[ebp+08]
[00001c29][00113059][00001c22] 50 push eax ; push DD
[00001c2a][00113059][00001c22] 8b4d08 mov ecx,[ebp+08]
[00001c2d][00113055][00001c22] 51 push ecx ; push DD
[00001c2e][00113051][00001c33] e80ff7ffff call 00001342 ; call HH
New slave_stack at:14da95
[00001c22][0015da89][0015da8d] 55 push ebp
[00001c23][0015da89][0015da8d] 8bec mov ebp,esp
[00001c25][0015da85][0014da59] 51 push ecx
[00001c26][0015da85][0014da59] 8b4508 mov eax,[ebp+08]
[00001c29][0015da81][00001c22] 50 push eax ; push DD
[00001c2a][0015da81][00001c22] 8b4d08 mov ecx,[ebp+08]
[00001c2d][0015da7d][00001c22] 51 push ecx ; push DD
[00001c2e][0015da79][00001c33] e80ff7ffff call 00001342 ; call HH
Local Halt Decider: Recursive Simulation Detected Simulation Stopped
*The Execution Trace is proven to be correct on the basis of*
*the fact that the above x86 machine language instructions of DD*
*are correctly emulated by HH in their correct order*
"...the Turing machine will halt whenever it enters a final state."
Linz(1990:234)
DD correctly emulated by HH with an x86 emulator cannot possibly
reach its own final state at machine address 00001c47 in any finite
number of steps of correct emulation.
*Here is the C version*
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 }
DD correctly simulated by pure function HH cannot possibly reach
its own final state at line 06 in any finite number of steps of correct
simulation.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-05-30 10:40 +0300 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v39agi$1jiql$1@dont-email.me> |
| In reply to | #105715 |
On 2024-05-30 01:15:21 +0000, olcott said:
> On 5/29/2024 8:07 PM, Richard Damon wrote:
>> On 5/29/24 8:59 PM, olcott wrote:
>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>
>>>>>>>>>>> How about a bit of respect? Mike specifically asked you not to cite his
>>>>>>>>>>> name as a back up for your points. Why do you keep doing it?
>>>>>>>>>>
>>>>>>>>>> He does it to try to rope more people in. It's the same ploy as
>>>>>>>>>> insulting people by name. It's hard to ignore being maligned in public
>>>>>>>>>> by a fool.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> I really did believe that Ben Bacarisse was lying when I said it.
>>>>>>>>>
>>>>>>>>> At the time I was talking about the easily verified fact of the actual
>>>>>>>>> execution trace of fully operational code and everyone was denying the
>>>>>>>>> easily verified facts.
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>> 01 int D(ptr p)
>>>>>>>>> 02 {
>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>> 06 return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>> 08
>>>>>>>>> 09 int main()
>>>>>>>>> 10 {
>>>>>>>>> 11 H(D,D);
>>>>>>>>> 12 return 0;
>>>>>>>>> 13 }
>>>>>>>>>
>>>>>>>>> It turns out that two dozen people are easily proven wrong when
>>>>>>>>> they claimed that the correct simulation of the input to H(D,D)
>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>
>>>>>>>>
>>>>>>>> How is that?
>>>>>>>>
>>>>>>>>
>>>>>>>>> When D is correctly simulated by H using an x86 emulator the only
>>>>>>>>> way that the emulated D can reach its own emulated final state
>>>>>>>>> at line 06 and halt is
>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong order
>>>>>>>>>
>>>>>>>>
>>>>>>>> Which isn't a "Correct Simulation" by the definition that allow the
>>>>>>>> relating of a "Simulation" to the behavior of an input.
>>>>>>>>
>>>>>>>
>>>>>>> Right the execution trace of D simulated by pure function H using
>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>
>>>>>> So, you aren't going to resolve the question but just keep up with your
>>>>>> contradiction that H is simulating a template (that doesn't HAVE any
>>>>>> instrucitons of H in it) but also DOES simulate those non-existance
>>>>>> instructions by LYING about what it does and simulating a SPECIFIC
>>>>>> instance that it LIES behaves just like DIFFERENT specific instatces.
>>>>>
>>>>> I will give you the benefit of the doubt and call that an honest
>>>>> misunderstanding. I have much more empathy for you now that I found
>>>>> that Linz really did say words that you could construe as you did.
>>>>>
>>>>> The infinite set of every H/D pair specified by the template
>>>>> where D is correctly simulated by pure simulator H or pure function
>>>>> H never has any D reach its own simulated final state and halt.
>>>>
>>>> But the question ISN'T about the SIMULATED D, but about the behavior of
>>>> the actual PROGRAM/MACHINE D
>>>>
>>>> This seems to be your blind spot.
>>>
>>> ∃H ∈ Turing_Machines
>>> ∀x ∈ Turing_Machines_Descriptions
>>> ∀y ∈ Finite_Strings
>>> such that H(x,y) = Halts(x,y)
>>>
>>> Not really the above formalization does not can cannot
>>> specify Turing Machines as the input to any decider H.
>>>
>>
>> Then what is x representing?
>
> x <is> a finite string Turing machine description that SPECIFIES
> behavior. The term: "representing" is inaccurate.
No, x is a description of the Turing machine that specifies the behaviour
that H is required to report. The maning of x is that there is a universal
Turing machine that, when given x and y, simulates what the described
Turing machine does when given y. Therefore, you may reformulate the
requirement:
∀x ∈ Turing_Machines_Descriptions
∀y ∈ Finite_Strings
H(x,y) returns "yes" if UTM(x,y) halts and "no" otherwise.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-30 08:31 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v39v3h$1mtd9$5@dont-email.me> |
| In reply to | #105731 |
On 5/30/2024 2:40 AM, Mikko wrote:
> On 2024-05-30 01:15:21 +0000, olcott said:
>
>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>> On 5/29/24 8:59 PM, olcott wrote:
>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>
>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you not
>>>>>>>>>>>> to cite his
>>>>>>>>>>>> name as a back up for your points. Why do you keep doing it?
>>>>>>>>>>>
>>>>>>>>>>> He does it to try to rope more people in. It's the same ploy as
>>>>>>>>>>> insulting people by name. It's hard to ignore being maligned
>>>>>>>>>>> in public
>>>>>>>>>>> by a fool.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> I really did believe that Ben Bacarisse was lying when I said it.
>>>>>>>>>>
>>>>>>>>>> At the time I was talking about the easily verified fact of
>>>>>>>>>> the actual
>>>>>>>>>> execution trace of fully operational code and everyone was
>>>>>>>>>> denying the
>>>>>>>>>> easily verified facts.
>>>>>>>>>>
>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>> 02 {
>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>> 07 }
>>>>>>>>>> 08
>>>>>>>>>> 09 int main()
>>>>>>>>>> 10 {
>>>>>>>>>> 11 H(D,D);
>>>>>>>>>> 12 return 0;
>>>>>>>>>> 13 }
>>>>>>>>>>
>>>>>>>>>> It turns out that two dozen people are easily proven wrong when
>>>>>>>>>> they claimed that the correct simulation of the input to H(D,D)
>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> How is that?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> When D is correctly simulated by H using an x86 emulator the only
>>>>>>>>>> way that the emulated D can reach its own emulated final state
>>>>>>>>>> at line 06 and halt is
>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong order
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which isn't a "Correct Simulation" by the definition that allow
>>>>>>>>> the relating of a "Simulation" to the behavior of an input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right the execution trace of D simulated by pure function H using
>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>>
>>>>>>> So, you aren't going to resolve the question but just keep up
>>>>>>> with your contradiction that H is simulating a template (that
>>>>>>> doesn't HAVE any instrucitons of H in it) but also DOES simulate
>>>>>>> those non-existance instructions by LYING about what it does and
>>>>>>> simulating a SPECIFIC instance that it LIES behaves just like
>>>>>>> DIFFERENT specific instatces.
>>>>>>
>>>>>> I will give you the benefit of the doubt and call that an honest
>>>>>> misunderstanding. I have much more empathy for you now that I found
>>>>>> that Linz really did say words that you could construe as you did.
>>>>>>
>>>>>> The infinite set of every H/D pair specified by the template
>>>>>> where D is correctly simulated by pure simulator H or pure function
>>>>>> H never has any D reach its own simulated final state and halt.
>>>>>
>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>
>>>>> This seems to be your blind spot.
>>>>
>>>> ∃H ∈ Turing_Machines
>>>> ∀x ∈ Turing_Machines_Descriptions
>>>> ∀y ∈ Finite_Strings
>>>> such that H(x,y) = Halts(x,y)
>>>>
>>>> Not really the above formalization does not can cannot
>>>> specify Turing Machines as the input to any decider H.
>>>>
>>>
>>> Then what is x representing?
>>
>> x <is> a finite string Turing machine description that SPECIFIES
>> behavior. The term: "representing" is inaccurate.
>
> No, x is a description of the Turing machine that specifies the behaviour
> that H is required to report.
That is what I said.
> The maning of x is that there is a universal
> Turing machine that, when given x and y, simulates what the described
> Turing machine does when given y.
Yes that is also correct.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When embedded_H is a UTM then it never halts.
When embedded_H is a simulating halt decider then its correctly
simulated input never reaches its own simulated final state of
⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
input as non-halting.
> Therefore, you may reformulate the
> requirement:
>
> ∀x ∈ Turing_Machines_Descriptions
> ∀y ∈ Finite_Strings
> H(x,y) returns "yes" if UTM(x,y) halts and "no" otherwise.
>
Not quite.
--
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-05-30 21:37 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3b9kj$2im02$1@i2pn2.org> |
| In reply to | #105747 |
On 5/30/24 9:31 AM, olcott wrote:
> On 5/30/2024 2:40 AM, Mikko wrote:
>> On 2024-05-30 01:15:21 +0000, olcott said:
>>
>>> On 5/29/2024 8:07 PM, Richard Damon wrote:
>>>> On 5/29/24 8:59 PM, olcott wrote:
>>>>> On 5/29/2024 7:48 PM, Richard Damon wrote:
>>>>>> On 5/29/24 8:17 PM, olcott wrote:
>>>>>>> On 5/29/2024 7:09 PM, Richard Damon wrote:
>>>>>>>> On 5/29/24 7:57 PM, olcott wrote:
>>>>>>>>> On 5/29/2024 6:47 PM, Richard Damon wrote:
>>>>>>>>>> On 5/29/24 2:31 PM, olcott wrote:
>>>>>>>>>>> On 5/29/2024 1:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> How about a bit of respect? Mike specifically asked you
>>>>>>>>>>>>> not to cite his
>>>>>>>>>>>>> name as a back up for your points. Why do you keep doing it?
>>>>>>>>>>>>
>>>>>>>>>>>> He does it to try to rope more people in. It's the same
>>>>>>>>>>>> ploy as
>>>>>>>>>>>> insulting people by name. It's hard to ignore being
>>>>>>>>>>>> maligned in public
>>>>>>>>>>>> by a fool.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Thanks for validating my simplified encoding of the Linz*
>>>>>>>>>>>
>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> I really did believe that Ben Bacarisse was lying when I said
>>>>>>>>>>> it.
>>>>>>>>>>>
>>>>>>>>>>> At the time I was talking about the easily verified fact of
>>>>>>>>>>> the actual
>>>>>>>>>>> execution trace of fully operational code and everyone was
>>>>>>>>>>> denying the
>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>
>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>> 02 {
>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>> 07 }
>>>>>>>>>>> 08
>>>>>>>>>>> 09 int main()
>>>>>>>>>>> 10 {
>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>> 12 return 0;
>>>>>>>>>>> 13 }
>>>>>>>>>>>
>>>>>>>>>>> It turns out that two dozen people are easily proven wrong when
>>>>>>>>>>> they claimed that the correct simulation of the input to H(D,D)
>>>>>>>>>>> is the behavior of int main() { D(D); }
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How is that?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> When D is correctly simulated by H using an x86 emulator the
>>>>>>>>>>> only
>>>>>>>>>>> way that the emulated D can reach its own emulated final state
>>>>>>>>>>> at line 06 and halt is
>>>>>>>>>>> (a) The x86 machine code of D is emulated incorrectly
>>>>>>>>>>> (b) The x86 machine code of D is emulated in the wrong order
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Which isn't a "Correct Simulation" by the definition that
>>>>>>>>>> allow the relating of a "Simulation" to the behavior of an input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right the execution trace of D simulated by pure function H using
>>>>>>>>> an x86 emulator must show that D cannot possibly reach its own
>>>>>>>>> simulated final state and halt or the simulation of the machine
>>>>>>>>> language of D is incorrect or in the wrong order.
>>>>>>>>
>>>>>>>> So, you aren't going to resolve the question but just keep up
>>>>>>>> with your contradiction that H is simulating a template (that
>>>>>>>> doesn't HAVE any instrucitons of H in it) but also DOES simulate
>>>>>>>> those non-existance instructions by LYING about what it does and
>>>>>>>> simulating a SPECIFIC instance that it LIES behaves just like
>>>>>>>> DIFFERENT specific instatces.
>>>>>>>
>>>>>>> I will give you the benefit of the doubt and call that an honest
>>>>>>> misunderstanding. I have much more empathy for you now that I found
>>>>>>> that Linz really did say words that you could construe as you did.
>>>>>>>
>>>>>>> The infinite set of every H/D pair specified by the template
>>>>>>> where D is correctly simulated by pure simulator H or pure function
>>>>>>> H never has any D reach its own simulated final state and halt.
>>>>>>
>>>>>> But the question ISN'T about the SIMULATED D, but about the
>>>>>> behavior of the actual PROGRAM/MACHINE D
>>>>>>
>>>>>> This seems to be your blind spot.
>>>>>
>>>>> ∃H ∈ Turing_Machines
>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>> ∀y ∈ Finite_Strings
>>>>> such that H(x,y) = Halts(x,y)
>>>>>
>>>>> Not really the above formalization does not can cannot
>>>>> specify Turing Machines as the input to any decider H.
>>>>>
>>>>
>>>> Then what is x representing?
>>>
>>> x <is> a finite string Turing machine description that SPECIFIES
>>> behavior. The term: "representing" is inaccurate.
>>
>> No, x is a description of the Turing machine that specifies the behaviour
>> that H is required to report.
>
> That is what I said.
Note, the string doesn't DIRECTLY specify behavior, but only indirectly
as a description/representation of the Turing Mach
>
>> The maning of x is that there is a universal
>> Turing machine that, when given x and y, simulates what the described
>> Turing machine does when given y.
>
> Yes that is also correct.
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> When embedded_H is a UTM then it never halts.
But it isn't unless H is also a UTM, and then H never returns.
You like to keep returning to that deception.
>
> When embedded_H is a simulating halt decider then its correctly
> simulated input never reaches its own simulated final state of
> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
> input as non-halting.
Except that isn't what the question is, the question is what the actual
behavior of the machine described, or equivalently, the simulation by a
REAL UTM (one that never stops till done).
As has been shown, H / embedded_H can't be that and answer, so either
your embedded_H needs to answer about a simulation done by a different
machine (which seems beyond your understanding) or you just don't have a
valid criteria to use.
>
>
>> Therefore, you may reformulate the
>> requirement:
>>
>> ∀x ∈ Turing_Machines_Descriptions
>> ∀y ∈ Finite_Strings
>> H(x,y) returns "yes" if UTM(x,y) halts and "no" otherwise.
>>
>
> Not quite.
>
YES, QUITE. UTM(x,y) is what Halts(x,y) would return.
Note, the answer Halts(x,y) can't be dependent on the decider that is
looking at the input, so it can't be based on that machines "correct
simulation" if that can differ on the machines deciding (as your H and
H1 have shown) so that CAN'T be the proper definition.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-30 20:54 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3bale$222n5$1@dont-email.me> |
| In reply to | #105777 |
On 5/30/2024 8:37 PM, Richard Damon wrote: > On 5/30/24 9:31 AM, olcott wrote: >> On 5/30/2024 2:40 AM, Mikko wrote: >>> On 2024-05-30 01:15:21 +0000, olcott said: >>>> x <is> a finite string Turing machine description that SPECIFIES >>>> behavior. The term: "representing" is inaccurate. >>> >>> No, x is a description of the Turing machine that specifies the >>> behaviour >>> that H is required to report. >> >> That is what I said. > > Note, the string doesn't DIRECTLY specify behavior, but only indirectly > as a description/representation of the Turing Mach > The string directly SPECIFIES behavior to a UTM or to any TM based on a UTM. >> >>> The maning of x is that there is a universal >>> Turing machine that, when given x and y, simulates what the described >>> Turing machine does when given y. >> >> Yes that is also correct. > > > >> >> When Ĥ is applied to ⟨Ĥ⟩ >> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >> >> When embedded_H is a UTM then it never halts. > > But it isn't unless H is also a UTM, and then H never returns. > > You like to keep returning to that deception. > >> >> When embedded_H is a simulating halt decider then its correctly >> simulated input never reaches its own simulated final state of >> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its >> input as non-halting. > > Except that isn't what the question is, the question is what the actual > behavior of the machine described, or equivalently, the simulation by a > REAL UTM (one that never stops till done). When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and embedded_H is not a decider. When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H never reaches its own simulated final state of ⟨Ĥ.qn⟩ in any finite number of steps and after these finite steps embedded_H halts. *I am going to stop here and not respond to anything else* *that you say until AFTER this one point is fully resolved* -- 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-05-30 22:15 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3bbs2$2im01$1@i2pn2.org> |
| In reply to | #105784 |
On 5/30/24 9:54 PM, olcott wrote: > On 5/30/2024 8:37 PM, Richard Damon wrote: >> On 5/30/24 9:31 AM, olcott wrote: >>> On 5/30/2024 2:40 AM, Mikko wrote: >>>> On 2024-05-30 01:15:21 +0000, olcott said: > >>>>> x <is> a finite string Turing machine description that SPECIFIES >>>>> behavior. The term: "representing" is inaccurate. >>>> >>>> No, x is a description of the Turing machine that specifies the >>>> behaviour >>>> that H is required to report. >>> >>> That is what I said. >> >> Note, the string doesn't DIRECTLY specify behavior, but only >> indirectly as a description/representation of the Turing Mach >> > > The string directly SPECIFIES behavior to a UTM or to > any TM based on a UTM. By telling that UTM information about the state-transition table of the machine. Note, the description of the machine doesn't depend on the input given to it, so it needs to fully specify how to recreate the behavior of the machine for ALL inputs (an infinite number of them) in a finite string. > >>> >>>> The maning of x is that there is a universal >>>> Turing machine that, when given x and y, simulates what the described >>>> Turing machine does when given y. >>> >>> Yes that is also correct. >> >> >> >>> >>> When Ĥ is applied to ⟨Ĥ⟩ >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>> >>> When embedded_H is a UTM then it never halts. >> >> But it isn't unless H is also a UTM, and then H never returns. >> >> You like to keep returning to that deception. >> >>> >>> When embedded_H is a simulating halt decider then its correctly >>> simulated input never reaches its own simulated final state of >>> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its >>> input as non-halting. >> >> Except that isn't what the question is, the question is what the >> actual behavior of the machine described, or equivalently, the >> simulation by a REAL UTM (one that never stops till done). > > When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and embedded_H is > not a decider. Right, that is YOUR delema. You can't make H / embedded_H a UTM without making it not a decider, thus "Correct Simulation by H" can't be the answer, since H can't do both. > > When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated > by embedded_H never reaches its own simulated final state of ⟨Ĥ.qn⟩ in > any finite number of steps and after these finite steps embedded_H > halts. Then its simulation isn't "correct" per the definitions that relate simulation to behavior. > > *I am going to stop here and not respond to anything else* > *that you say until AFTER this one point is fully resolved* > And you need to understand that if you change the UTM to abort its simulation, it is no longer a UTM and has lost that property that its simulation reveals the behavior of the input.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-30 21:32 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3bcre$22a8n$1@dont-email.me> |
| In reply to | #105785 |
On 5/30/2024 9:15 PM, Richard Damon wrote:
> On 5/30/24 9:54 PM, olcott wrote:
>> On 5/30/2024 8:37 PM, Richard Damon wrote:
>>> On 5/30/24 9:31 AM, olcott wrote:
>>>> On 5/30/2024 2:40 AM, Mikko wrote:
>>>>> On 2024-05-30 01:15:21 +0000, olcott said:
>>
>>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>>> behavior. The term: "representing" is inaccurate.
>>>>>
>>>>> No, x is a description of the Turing machine that specifies the
>>>>> behaviour
>>>>> that H is required to report.
>>>>
>>>> That is what I said.
>>>
>>> Note, the string doesn't DIRECTLY specify behavior, but only
>>> indirectly as a description/representation of the Turing Mach
>>>
>>
>> The string directly SPECIFIES behavior to a UTM or to
>> any TM based on a UTM.
>
> By telling that UTM information about the state-transition table of the
> machine.
>
> Note, the description of the machine doesn't depend on the input given
> to it, so it needs to fully specify how to recreate the behavior of the
> machine for ALL inputs (an infinite number of them) in a finite string.
>
>>
>>>>
>>>>> The maning of x is that there is a universal
>>>>> Turing machine that, when given x and y, simulates what the described
>>>>> Turing machine does when given y.
>>>>
>>>> Yes that is also correct.
>>>
>>>
>>>
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> When embedded_H is a UTM then it never halts.
>>>
>>> But it isn't unless H is also a UTM, and then H never returns.
>>>
>>> You like to keep returning to that deception.
>>>
>>>>
>>>> When embedded_H is a simulating halt decider then its correctly
>>>> simulated input never reaches its own simulated final state of
>>>> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
>>>> input as non-halting.
>>>
>>> Except that isn't what the question is, the question is what the
>>> actual behavior of the machine described, or equivalently, the
>>> simulation by a REAL UTM (one that never stops till done).
>>
>> When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and embedded_H is
>> not a decider.
>
> Right, that is YOUR delema. You can't make H / embedded_H a UTM without
> making it not a decider, thus "Correct Simulation by H" can't be the
> answer, since H can't do both.
>
>>
>> When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
>> by embedded_H never reaches its own simulated final state of ⟨Ĥ.qn⟩ in
>> any finite number of steps and after these finite steps embedded_H
>> halts.
>
> Then its simulation isn't "correct" per the definitions that relate
> simulation to behavior.
>
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 }
In other words you are insisting that every correct simulation
of DD by HH must simulate the following x86 machine code of DD
*incorrectly or in the incorrect order* because the following
machine code proves that DD correctly simulated by HH cannot
possibly reach its own machine address of 00001c47.
_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]
*I am going to stop here and not respond to anything else*
*that you say until AFTER this one point is fully resolved*
--
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-05-30 22:51 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3bduk$2im01$2@i2pn2.org> |
| In reply to | #105786 |
On 5/30/24 10:32 PM, olcott wrote:
> On 5/30/2024 9:15 PM, Richard Damon wrote:
>> On 5/30/24 9:54 PM, olcott wrote:
>>> On 5/30/2024 8:37 PM, Richard Damon wrote:
>>>> On 5/30/24 9:31 AM, olcott wrote:
>>>>> On 5/30/2024 2:40 AM, Mikko wrote:
>>>>>> On 2024-05-30 01:15:21 +0000, olcott said:
>>>
>>>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>>>> behavior. The term: "representing" is inaccurate.
>>>>>>
>>>>>> No, x is a description of the Turing machine that specifies the
>>>>>> behaviour
>>>>>> that H is required to report.
>>>>>
>>>>> That is what I said.
>>>>
>>>> Note, the string doesn't DIRECTLY specify behavior, but only
>>>> indirectly as a description/representation of the Turing Mach
>>>>
>>>
>>> The string directly SPECIFIES behavior to a UTM or to
>>> any TM based on a UTM.
>>
>> By telling that UTM information about the state-transition table of
>> the machine.
>>
>> Note, the description of the machine doesn't depend on the input given
>> to it, so it needs to fully specify how to recreate the behavior of
>> the machine for ALL inputs (an infinite number of them) in a finite
>> string.
>>
>>>
>>>>>
>>>>>> The maning of x is that there is a universal
>>>>>> Turing machine that, when given x and y, simulates what the described
>>>>>> Turing machine does when given y.
>>>>>
>>>>> Yes that is also correct.
>>>>
>>>>
>>>>
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> When embedded_H is a UTM then it never halts.
>>>>
>>>> But it isn't unless H is also a UTM, and then H never returns.
>>>>
>>>> You like to keep returning to that deception.
>>>>
>>>>>
>>>>> When embedded_H is a simulating halt decider then its correctly
>>>>> simulated input never reaches its own simulated final state of
>>>>> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
>>>>> input as non-halting.
>>>>
>>>> Except that isn't what the question is, the question is what the
>>>> actual behavior of the machine described, or equivalently, the
>>>> simulation by a REAL UTM (one that never stops till done).
>>>
>>> When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and embedded_H is
>>> not a decider.
>>
>> Right, that is YOUR delema. You can't make H / embedded_H a UTM
>> without making it not a decider, thus "Correct Simulation by H" can't
>> be the answer, since H can't do both.
>>
>>>
>>> When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
>>> by embedded_H never reaches its own simulated final state of ⟨Ĥ.qn⟩ in
>>> any finite number of steps and after these finite steps embedded_H
>>> halts.
>>
>> Then its simulation isn't "correct" per the definitions that relate
>> simulation to behavior.
>>
>
> 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 }
>
> In other words you are insisting that every correct simulation
> of DD by HH must simulate the following x86 machine code of DD
> *incorrectly or in the incorrect order* because the following
> machine code proves that DD correctly simulated by HH cannot
> possibly reach its own machine address of 00001c47.
It is "Incorrect" in that it is incomplete.
Note, the CODE, when run, reaches that state, if HH returns the answer
(as it must to be a decider).
The PARTIAL simulation that HH has been programmed to do, doesn't reach
that point, even though the COMPLETE AND CORRECT simulation of that same
input by a UTM (where DD still calls the HH that does abort and return)
will reach that point.
You are just stuck in your deception of trying to change the meaning of
"Correct Simulation".
>
> _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]
>
> *I am going to stop here and not respond to anything else*
> *that you say until AFTER this one point is fully resolved*
>
>
So, are you going to stop LYING about what I am saying?
I never said that HH does an incorrect partial simulation, a simulation
that mis-simulates any of the instructions that it actually simulates.
Your TRACES show the error of not following the call to HH, and thus
your TRACES are LIES, and my memory is that your code of H actually has
checks that do what you show, becuase it just doesn't simulate the
instrucitons after the call.
So, if HH actually does what you claim, you need to present the output
of what it does, and that would be simulating the actual instructions of
HH. If that is too long to post in the newsgroup, post that ACTUAL trace
on a web site.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-30 21:58 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3bedb$22f8h$1@dont-email.me> |
| In reply to | #105787 |
On 5/30/2024 9:51 PM, Richard Damon wrote:
> On 5/30/24 10:32 PM, olcott wrote:
>> On 5/30/2024 9:15 PM, Richard Damon wrote:
>>> On 5/30/24 9:54 PM, olcott wrote:
>>>> On 5/30/2024 8:37 PM, Richard Damon wrote:
>>>>> On 5/30/24 9:31 AM, olcott wrote:
>>>>>> On 5/30/2024 2:40 AM, Mikko wrote:
>>>>>>> On 2024-05-30 01:15:21 +0000, olcott said:
>>>>
>>>>>>>> x <is> a finite string Turing machine description that SPECIFIES
>>>>>>>> behavior. The term: "representing" is inaccurate.
>>>>>>>
>>>>>>> No, x is a description of the Turing machine that specifies the
>>>>>>> behaviour
>>>>>>> that H is required to report.
>>>>>>
>>>>>> That is what I said.
>>>>>
>>>>> Note, the string doesn't DIRECTLY specify behavior, but only
>>>>> indirectly as a description/representation of the Turing Mach
>>>>>
>>>>
>>>> The string directly SPECIFIES behavior to a UTM or to
>>>> any TM based on a UTM.
>>>
>>> By telling that UTM information about the state-transition table of
>>> the machine.
>>>
>>> Note, the description of the machine doesn't depend on the input
>>> given to it, so it needs to fully specify how to recreate the
>>> behavior of the machine for ALL inputs (an infinite number of them)
>>> in a finite string.
>>>
>>>>
>>>>>>
>>>>>>> The maning of x is that there is a universal
>>>>>>> Turing machine that, when given x and y, simulates what the
>>>>>>> described
>>>>>>> Turing machine does when given y.
>>>>>>
>>>>>> Yes that is also correct.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> When embedded_H is a UTM then it never halts.
>>>>>
>>>>> But it isn't unless H is also a UTM, and then H never returns.
>>>>>
>>>>> You like to keep returning to that deception.
>>>>>
>>>>>>
>>>>>> When embedded_H is a simulating halt decider then its correctly
>>>>>> simulated input never reaches its own simulated final state of
>>>>>> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
>>>>>> input as non-halting.
>>>>>
>>>>> Except that isn't what the question is, the question is what the
>>>>> actual behavior of the machine described, or equivalently, the
>>>>> simulation by a REAL UTM (one that never stops till done).
>>>>
>>>> When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and embedded_H is
>>>> not a decider.
>>>
>>> Right, that is YOUR delema. You can't make H / embedded_H a UTM
>>> without making it not a decider, thus "Correct Simulation by H" can't
>>> be the answer, since H can't do both.
>>>
>>>>
>>>> When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
>>>> by embedded_H never reaches its own simulated final state of ⟨Ĥ.qn⟩ in
>>>> any finite number of steps and after these finite steps embedded_H
>>>> halts.
>>>
>>> Then its simulation isn't "correct" per the definitions that relate
>>> simulation to behavior.
>>>
>>
>> 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 }
>>
>> In other words you are insisting that every correct simulation
>> of DD by HH must simulate the following x86 machine code of DD
>> *incorrectly or in the incorrect order* because the following
>> machine code proves that DD correctly simulated by HH cannot
>> possibly reach its own machine address of 00001c47.
>
> It is "Incorrect" in that it is incomplete.
>
You already acknowledged that DD correctly simulated by pure simulator
HH never reaches its own simulated final state so you already know that
a complete simulation does not help.
*Try and show how you are not lying*
_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]
*I am going to stop here and not respond to anything else*
*that you say until AFTER this one point is fully resolved*
--
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-05-30 23:15 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3bfbm$2im01$3@i2pn2.org> |
| In reply to | #105788 |
On 5/30/24 10:58 PM, olcott wrote:
> On 5/30/2024 9:51 PM, Richard Damon wrote:
>> On 5/30/24 10:32 PM, olcott wrote:
>>> On 5/30/2024 9:15 PM, Richard Damon wrote:
>>>> On 5/30/24 9:54 PM, olcott wrote:
>>>>> On 5/30/2024 8:37 PM, Richard Damon wrote:
>>>>>> On 5/30/24 9:31 AM, olcott wrote:
>>>>>>> On 5/30/2024 2:40 AM, Mikko wrote:
>>>>>>>> On 2024-05-30 01:15:21 +0000, olcott said:
>>>>>
>>>>>>>>> x <is> a finite string Turing machine description that
>>>>>>>>> SPECIFIES behavior. The term: "representing" is inaccurate.
>>>>>>>>
>>>>>>>> No, x is a description of the Turing machine that specifies the
>>>>>>>> behaviour
>>>>>>>> that H is required to report.
>>>>>>>
>>>>>>> That is what I said.
>>>>>>
>>>>>> Note, the string doesn't DIRECTLY specify behavior, but only
>>>>>> indirectly as a description/representation of the Turing Mach
>>>>>>
>>>>>
>>>>> The string directly SPECIFIES behavior to a UTM or to
>>>>> any TM based on a UTM.
>>>>
>>>> By telling that UTM information about the state-transition table of
>>>> the machine.
>>>>
>>>> Note, the description of the machine doesn't depend on the input
>>>> given to it, so it needs to fully specify how to recreate the
>>>> behavior of the machine for ALL inputs (an infinite number of them)
>>>> in a finite string.
>>>>
>>>>>
>>>>>>>
>>>>>>>> The maning of x is that there is a universal
>>>>>>>> Turing machine that, when given x and y, simulates what the
>>>>>>>> described
>>>>>>>> Turing machine does when given y.
>>>>>>>
>>>>>>> Yes that is also correct.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> When embedded_H is a UTM then it never halts.
>>>>>>
>>>>>> But it isn't unless H is also a UTM, and then H never returns.
>>>>>>
>>>>>> You like to keep returning to that deception.
>>>>>>
>>>>>>>
>>>>>>> When embedded_H is a simulating halt decider then its correctly
>>>>>>> simulated input never reaches its own simulated final state of
>>>>>>> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
>>>>>>> input as non-halting.
>>>>>>
>>>>>> Except that isn't what the question is, the question is what the
>>>>>> actual behavior of the machine described, or equivalently, the
>>>>>> simulation by a REAL UTM (one that never stops till done).
>>>>>
>>>>> When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and embedded_H is
>>>>> not a decider.
>>>>
>>>> Right, that is YOUR delema. You can't make H / embedded_H a UTM
>>>> without making it not a decider, thus "Correct Simulation by H"
>>>> can't be the answer, since H can't do both.
>>>>
>>>>>
>>>>> When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>>>> simulated
>>>>> by embedded_H never reaches its own simulated final state of ⟨Ĥ.qn⟩ in
>>>>> any finite number of steps and after these finite steps embedded_H
>>>>> halts.
>>>>
>>>> Then its simulation isn't "correct" per the definitions that relate
>>>> simulation to behavior.
>>>>
>>>
>>> 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 }
>>>
>>> In other words you are insisting that every correct simulation
>>> of DD by HH must simulate the following x86 machine code of DD
>>> *incorrectly or in the incorrect order* because the following
>>> machine code proves that DD correctly simulated by HH cannot
>>> possibly reach its own machine address of 00001c47.
>>
>> It is "Incorrect" in that it is incomplete.
>>
>
> You already acknowledged that DD correctly simulated by pure simulator
> HH never reaches its own simulated final state so you already know that
> a complete simulation does not help.
Sure does, since those are different cases.
Maybe you don't understand what it means to give the DD that calls the
HH that aborts to an actual True Simulator, verse making HH a pure
simulator/
>
> *Try and show how you are not lying*
>
> _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]
>
> *I am going to stop here and not respond to anything else*
> *that you say until AFTER this one point is fully resolved*
>
So, since HH is a pure function, if ANY HH(DD,DD) returns 0, then when
this DD calls HH(DD,DD) then it will return 0 and DD will halt.
Your problem is you keep on changing what DD calls, which just means you
don't know what it means to be actually simulating a program.
Since you claim that HH, when it simulated DD, will trace that call in
DD into HH, that call to HH must ALWAYS go into HH, even when we pass
this description of DD to a UTM.
Remember, the criteria ISN'T making a new template instance based on a
UTM, but the SAME INSTANCE, which is still bound to HH, to the UTM, and
thus it WILL see the actual behavior of HH, which is to simulate for
awhile, abort its internal simulation of DD, and then return to its
calling DD and it halting.
You are just showing either a totolly lack of understanding of what you
are talking about, our are just being intentionally deceptive and lying
about what actually happens.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-30 22:27 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v3bg39$22o6m$1@dont-email.me> |
| In reply to | #105791 |
On 5/30/2024 10:15 PM, Richard Damon wrote:
> On 5/30/24 10:58 PM, olcott wrote:
>> On 5/30/2024 9:51 PM, Richard Damon wrote:
>>> On 5/30/24 10:32 PM, olcott wrote:
>>>> On 5/30/2024 9:15 PM, Richard Damon wrote:
>>>>> On 5/30/24 9:54 PM, olcott wrote:
>>>>>> On 5/30/2024 8:37 PM, Richard Damon wrote:
>>>>>>> On 5/30/24 9:31 AM, olcott wrote:
>>>>>>>> On 5/30/2024 2:40 AM, Mikko wrote:
>>>>>>>>> On 2024-05-30 01:15:21 +0000, olcott said:
>>>>>>
>>>>>>>>>> x <is> a finite string Turing machine description that
>>>>>>>>>> SPECIFIES behavior. The term: "representing" is inaccurate.
>>>>>>>>>
>>>>>>>>> No, x is a description of the Turing machine that specifies the
>>>>>>>>> behaviour
>>>>>>>>> that H is required to report.
>>>>>>>>
>>>>>>>> That is what I said.
>>>>>>>
>>>>>>> Note, the string doesn't DIRECTLY specify behavior, but only
>>>>>>> indirectly as a description/representation of the Turing Mach
>>>>>>>
>>>>>>
>>>>>> The string directly SPECIFIES behavior to a UTM or to
>>>>>> any TM based on a UTM.
>>>>>
>>>>> By telling that UTM information about the state-transition table of
>>>>> the machine.
>>>>>
>>>>> Note, the description of the machine doesn't depend on the input
>>>>> given to it, so it needs to fully specify how to recreate the
>>>>> behavior of the machine for ALL inputs (an infinite number of them)
>>>>> in a finite string.
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> The maning of x is that there is a universal
>>>>>>>>> Turing machine that, when given x and y, simulates what the
>>>>>>>>> described
>>>>>>>>> Turing machine does when given y.
>>>>>>>>
>>>>>>>> Yes that is also correct.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> When embedded_H is a UTM then it never halts.
>>>>>>>
>>>>>>> But it isn't unless H is also a UTM, and then H never returns.
>>>>>>>
>>>>>>> You like to keep returning to that deception.
>>>>>>>
>>>>>>>>
>>>>>>>> When embedded_H is a simulating halt decider then its correctly
>>>>>>>> simulated input never reaches its own simulated final state of
>>>>>>>> ⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
>>>>>>>> input as non-halting.
>>>>>>>
>>>>>>> Except that isn't what the question is, the question is what the
>>>>>>> actual behavior of the machine described, or equivalently, the
>>>>>>> simulation by a REAL UTM (one that never stops till done).
>>>>>>
>>>>>> When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and
>>>>>> embedded_H is
>>>>>> not a decider.
>>>>>
>>>>> Right, that is YOUR delema. You can't make H / embedded_H a UTM
>>>>> without making it not a decider, thus "Correct Simulation by H"
>>>>> can't be the answer, since H can't do both.
>>>>>
>>>>>>
>>>>>> When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>>>>> simulated
>>>>>> by embedded_H never reaches its own simulated final state of
>>>>>> ⟨Ĥ.qn⟩ in
>>>>>> any finite number of steps and after these finite steps embedded_H
>>>>>> halts.
>>>>>
>>>>> Then its simulation isn't "correct" per the definitions that relate
>>>>> simulation to behavior.
>>>>>
>>>>
>>>> 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 }
>>>>
>>>> In other words you are insisting that every correct simulation
>>>> of DD by HH must simulate the following x86 machine code of DD
>>>> *incorrectly or in the incorrect order* because the following
>>>> machine code proves that DD correctly simulated by HH cannot
>>>> possibly reach its own machine address of 00001c47.
>>>
>>> It is "Incorrect" in that it is incomplete.
>>>
>>
>> You already acknowledged that DD correctly simulated by pure simulator
>> HH never reaches its own simulated final state so you already know that
>> a complete simulation does not help.
>
> Sure does, since those are different cases.
>
> Maybe you don't understand what it means to give the DD that calls the
> HH that aborts to an actual True Simulator, verse making HH a pure
> simulator/
>
*So you did not even try to show that you are not lying*
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.
I am thinking that you know you are lying, yet am open
to proof that you not.
>>
>> *Try and show how you are not lying*
>>
>> _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]
>>
>>
*I am going to stop here and not respond to anything else*
*that you say until AFTER this one point is fully resolved*
--
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 4 of 19 — ← Prev page 1 2 3 [4] 5 6 … 19 Next page →
Back to top | Article view | comp.theory
csiph-web