Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.logic > #334663 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-05-28 11:16 -0500 |
| Last post | 2024-05-30 21:37 -0400 |
| Articles | 20 on this page of 254 — 13 participants |
Back to article view | Back to sci.logic
D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 11:16 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-28 22:04 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 21:23 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-28 23:38 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 22:49 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 07:31 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 08:49 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Alan Mackenzie <acm@muc.de> - 2024-05-29 15:40 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 11:21 -0500
Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 13:31 -0500
Re: Two dozen people were simply wrong Alan Mackenzie <acm@muc.de> - 2024-05-29 20:17 +0000
Re: Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 15:26 -0500
Re: Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 16:14 -0500
Re: Two dozen people were simply wrong (including Olcott) Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 18:57 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 20:09 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 19:17 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 20:48 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 19:59 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 21:07 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:15 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 21:24 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:24 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:48 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 21:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:55 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 22:58 -0500
Re: Olcott was simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 07:30 -0400
Re: Olcott was simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 09:04 -0500
Re: Olcott was simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 20:54 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 22:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 21:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 22:51 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 21:58 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 23:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 22:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 09:10 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 17:36 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 17:08 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 18:46 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 17:54 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 19:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 18:57 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 20:39 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 20:10 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 21:35 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 21:08 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 22:25 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 21:40 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 07:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:30 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:56 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 18:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:24 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 20:40 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:44 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 21:04 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:11 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 10:56 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:02 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 14:20 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:38 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 12:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 12:44 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:56 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:07 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 14:21 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:31 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 14:43 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:46 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:58 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 15:03 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:23 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 16:35 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 14:51 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 16:29 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 17:13 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 16:24 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 18:30 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 17:40 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 19:02 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 18:12 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down wij <wyniijj5@gmail.com> - 2024-06-02 07:25 +0800
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down wij <wyniijj5@gmail.com> - 2024-06-02 07:26 +0800
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 19:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 22:33 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 07:51 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:19 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 12:59 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 14:13 -0400
DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 13:29 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 15:05 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 14:13 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <Richard@Damon-Family.org> - 2024-06-02 15:22 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 14:34 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:11 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 15:21 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:32 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD immibis <news@immibis.com> - 2024-06-03 02:14 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 15:50 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:58 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 16:25 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 17:43 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 17:05 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 18:20 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 17:44 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 19:45 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 20:45 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 22:24 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 21:54 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 23:13 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 22:20 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 10:10 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-03 07:46 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:49 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-03 07:14 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-03 07:42 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:51 +0200
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:34 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Mikko <mikko.levanto@iki.fi> - 2024-06-03 10:33 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down wij <wyniijj5@gmail.com> - 2024-06-02 07:29 +0800
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:13 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:03 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:41 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:13 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:53 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:59 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 15:07 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:55 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:53 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 20:26 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 14:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 11:01 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Wasell <wasell@example.com> - 2024-06-01 10:36 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 09:00 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:46 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:58 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:08 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 11:18 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 12:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 11:46 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 16:29 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 15:35 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 17:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 16:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 18:30 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 17:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 19:02 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:24 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 09:47 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:24 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 13:39 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:55 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 14:01 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 09:50 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-02 14:59 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical immibis <news@immibis.com> - 2024-06-02 21:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical immibis <news@immibis.com> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 10:57 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:17 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:32 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:51 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:02 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 18:06 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:22 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:34 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 19:12 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:52 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:49 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 14:48 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-06-04 12:46 -0500
Re: Two dozen people were simply wrong immibis <news@immibis.com> - 2024-05-30 12:04 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years olcott <polcott333@gmail.com> - 2024-06-01 10:09 -0500
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:18 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years olcott <polcott333@gmail.com> - 2024-06-01 10:44 -0500
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:58 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years immibis <news@immibis.com> - 2024-06-01 20:51 +0200
Re: Deciders are ONLY accountable for their actual inputs --- immibis <news@immibis.com> - 2024-06-02 21:20 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:01 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 20:09 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:21 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 20:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:53 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 21:02 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 20:12 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 21:25 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 20:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 22:25 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 21:36 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 22:55 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 22:48 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-05-30 12:11 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-30 07:33 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-30 07:32 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 09:43 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 15:59 +0100
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 10:21 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 17:13 +0100
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 11:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 21:51 +0100
Re: D correctly simulated by H cannot possibly halt --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 16:22 -0500
Re: D correctly simulated by H cannot possibly halt --- Try to prove otherwise immibis <news@immibis.com> - 2024-05-30 23:50 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- Mike Terry olcott <polcott333@gmail.com> - 2024-05-31 09:46 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 17:20 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 10:30 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 17:58 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 12:00 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 20:50 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 14:01 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 21:32 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 15:15 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 22:59 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 16:27 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders immibis <news@immibis.com> - 2024-05-30 23:51 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:10 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 22:33 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Jeff Barnett <jbb@notatt.com> - 2024-05-30 21:48 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:52 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 23:06 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders immibis <news@immibis.com> - 2024-05-31 10:41 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:14 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 22:36 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-31 10:02 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-31 09:33 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:23 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders joes <noreply@example.com> - 2024-06-01 18:07 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-06-01 13:11 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-06-01 14:23 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Page 1 of 13 [1] 2 3 … 13 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-28 11:16 -0500 |
| Subject | D correctly simulated by H cannot possibly halt --- templates and infinite sets |
| Message-ID | <v3501h$lpnh$1@dont-email.me> |
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 }
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*Formalizing the Linz Proof structure*
∃H ∈ Turing_Machines
∀x ∈ Turing_Machines_Descriptions
∀y ∈ Finite_Strings
such that H(x,y) = Halts(x,x)
*Here is the same thing applied to H/D pairs*
∃H ∈ C_Functions
∀D ∈ x86_Machine_Code_of_C_Functions
such that H(D,D) = Halts(D,D)
In both cases infinite sets are examined to see
if any H exists with the required properties.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-28 22:04 -0400 |
| Message-ID | <v362eu$2d367$3@i2pn2.org> |
| In reply to | #334663 |
On 5/28/24 12:16 PM, olcott wrote:
> 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Â Â Â Â Â Â }
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> *Formalizing the Linz Proof structure*
> ∃H ∈ Turing_Machines
> ∀x ∈ Turing_Machines_Descriptions
> ∀y ∈ Finite_Strings
> such that H(x,y) = Halts(x,x)
But since for x being the description of the H^ built from that H and y
being the same, it turns out that no matter what answer H gives, it will
be wrong.
(And I think you have an error in your reference to Halts, I think you
mean Halts(x,y) not Halts(x,x)
>
> *Here is the same thing applied to H/D pairs*
> ∃H ∈ C_Functions
> ∀D ∈ x86_Machine_Code_of_C_Functions
> such that H(D,D) = Halts(D,D)
Not the same thing.
∃H ∈ C_Functions
is not equivalent to
∃H ∈ Turing_Machines
as there are many C_Functions that are not the equivalent of Turing
Machines.
>
> In both cases infinite sets are examined to see
> if any H exists with the required properties.
>
Yes, but the logic of Turing Machines looks at them one at a time, and
the input is a FULL INDEPENDENT PROGRAM.
I'm not sure what you can define your computation system to be actually
based on, and what its supposed use is, since your 'decider' and 'input'
are so intertwined.
And your supposed algorithm just doesn't work when you try to make you
system "Turing Complete" by letting D have the ability to have a COPY of
H, and being able to make copies of its input, like real Turing machines
can.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-28 21:23 -0500 |
| Message-ID | <v363js$vg63$2@dont-email.me> |
| In reply to | #334666 |
On 5/28/2024 9:04 PM, Richard Damon wrote:
> On 5/28/24 12:16 PM, olcott wrote:
>> 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Â Â Â Â Â Â }
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> *Formalizing the Linz Proof structure*
>> ∃H ∈ Turing_Machines
>> ∀x ∈ Turing_Machines_Descriptions
>> ∀y ∈ Finite_Strings
>> such that H(x,y) = Halts(x,x)
>
> But since for x being the description of the H^ built from that H and y
> being the same, it turns out that no matter what answer H gives, it will
> be wrong.
>
We have not gotten to that point yet this post is so that
you can fully understand what templates are and how they work.
> (And I think you have an error in your reference to Halts, I think you
> mean Halts(x,y) not Halts(x,x)
>
Yes good catch. I was trying to model embedded_H / ⟨Ĥ⟩
and then changed my mind to make it more general.
>>
>> *Here is the same thing applied to H/D pairs*
>> ∃H ∈ C_Functions
>> ∀D ∈ x86_Machine_Code_of_C_Functions
>> such that H(D,D) = Halts(D,D)
>
> Not the same thing.
> ∃H ∈ C_Functions
> is not equivalent to
> ∃H ∈ Turing_Machines
>
> as there are many C_Functions that are not the equivalent of Turing
> Machines.
>
The whole purpose here is to get you to understand what
templates are and how they reference infinite sets.
>
>>
>> In both cases infinite sets are examined to see
>> if any H exists with the required properties.
>>
>
> Yes, but the logic of Turing Machines looks at them one at a time, and
> the input is a FULL INDEPENDENT PROGRAM.
>
∃H ∈ Turing_Machines
That does not look at one machine it looks as an infinite set of
machines. I am very happy to find out that you were not playing head
games. Linz actually used the words that you referred to.
> I'm not sure what you can define your computation system to be actually
> based on, and what its supposed use is, since your 'decider' and 'input'
> are so intertwined.
>
The whole purpose here is to get you to understand what
templates are and how they reference infinite sets.
> And your supposed algorithm just doesn't work when you try to make you
> system "Turing Complete" by letting D have the ability to have a COPY of
> H, and being able to make copies of its input, like real Turing machines
> can.
>
The whole purpose here is to get you to understand what
templates are and how they reference infinite sets.
All the other issues are for another different post.
--
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-28 23:38 -0400 |
| Message-ID | <v36803$2d368$3@i2pn2.org> |
| In reply to | #334668 |
On 5/28/24 10:23 PM, olcott wrote:
> On 5/28/2024 9:04 PM, Richard Damon wrote:
>> On 5/28/24 12:16 PM, olcott wrote:
>>> 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Â Â Â Â Â Â }
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> *Formalizing the Linz Proof structure*
>>> ∃H ∈ Turing_Machines
>>> ∀x ∈ Turing_Machines_Descriptions
>>> ∀y ∈ Finite_Strings
>>> such that H(x,y) = Halts(x,x)
>>
>> But since for x being the description of the H^ built from that H and
>> y being the same, it turns out that no matter what answer H gives, it
>> will be wrong.
>>
>
> We have not gotten to that point yet this post is so that
> you can fully understand what templates are and how they work.
But note, x, being a Turing Machine, is NOT a "template"
And H, isn't a "set of Turing Machines", but an arbitrary member of that
set, so all we need to do is find a single x, y, possible determined as
a function of H (so, BUILT from a template, but not a template
themselves) that shows that particular H was wrong.
That is basically what Linz does.
Given a SPECIFIC (but arbitary) H, we can construct a specific H^ built
from a template from H, that that H can not get right.
All the other H's might get this input right, but we don't care, we have
shown that for every H we
>
>> (And I think you have an error in your reference to Halts, I think you
>> mean Halts(x,y) not Halts(x,x)
>>
>
> Yes good catch. I was trying to model embedded_H / ⟨Ĥ⟩
> and then changed my mind to make it more general.
>
>>>
>>> *Here is the same thing applied to H/D pairs*
>>> ∃H ∈ C_Functions
>>> ∀D ∈ x86_Machine_Code_of_C_Functions
>>> such that H(D,D) = Halts(D,D)
>>
>> Not the same thing.
>> ∃H ∈ C_Functions
>> is not equivalent to
>> ∃H ∈ Turing_Machines
>>
>> as there are many C_Functions that are not the equivalent of Turing
>> Machines.
>>
>
> The whole purpose here is to get you to understand what
> templates are and how they reference infinite sets.
>
But the problem is that even in your formulation, H and D are, when
doing the test, SPECIFIC PROGRAMS and not "templates" as Halts is
defined on the domain of PROGRAMS.
Similarly, a "Template" doesn't have a specific set of
x86_Machine_Code_of_C_function, at least not one with defined behavior
since if it tries to reference code outside of itself, then Halts of
that just isn't defined, only Halts of that code + the specific machine
deciding it.
>>
>>>
>>> In both cases infinite sets are examined to see
>>> if any H exists with the required properties.
>>>
>>
>> Yes, but the logic of Turing Machines looks at them one at a time, and
>> the input is a FULL INDEPENDENT PROGRAM.
>>
>
> ∃H ∈ Turing_Machines
> That does not look at one machine it looks as an infinite set of
> machines. I am very happy to find out that you were not playing head
> games. Linz actually used the words that you referred to.
while the ∃H part can create a set of machines, each element of that set
is INDIVIDUALLY TESTED in the following conditions, so, when we get to
your test H(x,y) = Halts(x,x), each of H, x, y are individual members
of the set, and we THEN collect the set of all of them.
If we try to say
∃x ∈ Natural Numbers, such that x+x = 3
we can't say that x is both 1 and 2 and thus as a set meet the
requirement. For the conditions, each qualifier select a single
prospective element, and those are tested to see if that meet the
requirement.
>
>> I'm not sure what you can define your computation system to be
>> actually based on, and what its supposed use is, since your 'decider'
>> and 'input' are so intertwined.
>>
>
> The whole purpose here is to get you to understand what
> templates are and how they reference infinite sets.
I understand how they work, the problem is you think they somehow change
the meaning of the final condition.
H(D,D) == Halts(D,D) doesn't mean that we get to look at some other
choice of H with some other choice of D to provide the D for Halts then
what H was given.
>
>> And your supposed algorithm just doesn't work when you try to make you
>> system "Turing Complete" by letting D have the ability to have a COPY
>> of H, and being able to make copies of its input, like real Turing
>> machines can.
>>
>
> The whole purpose here is to get you to understand what
> templates are and how they reference infinite sets.
>
> All the other issues are for another different post.
>
And you are just showing that YOU don't understand it, as it doesn't get
you anywhere closer to you goal.
The qualifier step is STILL done with a single specific element from
each of the sets.
Since for every element of the first set (your ∃H) there exists an input
that that particular H will get wrong, you can't use the "infinite set
of H/D" to argue that it was right.
All that does is prove that their does NOT exist an H that meets the
requirements.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-28 22:49 -0500 |
| Message-ID | <v368je$100kd$3@dont-email.me> |
| In reply to | #334673 |
On 5/28/2024 10:38 PM, Richard Damon wrote:
> On 5/28/24 10:23 PM, olcott wrote:
>> On 5/28/2024 9:04 PM, Richard Damon wrote:
>>> On 5/28/24 12:16 PM, olcott wrote:
>>>> 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Â Â Â Â Â Â }
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> *Formalizing the Linz Proof structure*
>>>> ∃H ∈ Turing_Machines
>>>> ∀x ∈ Turing_Machines_Descriptions
>>>> ∀y ∈ Finite_Strings
>>>> such that H(x,y) = Halts(x,x)
>>>
>>> But since for x being the description of the H^ built from that H and
>>> y being the same, it turns out that no matter what answer H gives, it
>>> will be wrong.
>>>
>>
>> We have not gotten to that point yet this post is so that
>> you can fully understand what templates are and how they work.
>
> But note, x, being a Turing Machine, is NOT a "template"
>
> And H, isn't a "set of Turing Machines", but an arbitrary member of that
> set, so all we need to do is find a single x, y, possible determined as
> a function of H (so, BUILT from a template, but not a template
> themselves) that shows that particular H was wrong.
>
>
> That is basically what Linz does.
>
> Given a SPECIFIC (but arbitary) H, we can construct a specific H^ built
> from a template from H, that that H can not get right.
>
> All the other H's might get this input right, but we don't care, we have
> shown that for every H we
>
>>
>>> (And I think you have an error in your reference to Halts, I think
>>> you mean Halts(x,y) not Halts(x,x)
>>>
>>
>> Yes good catch. I was trying to model embedded_H / ⟨Ĥ⟩
>> and then changed my mind to make it more general.
>>
>>>>
>>>> *Here is the same thing applied to H/D pairs*
>>>> ∃H ∈ C_Functions
>>>> ∀D ∈ x86_Machine_Code_of_C_Functions
>>>> such that H(D,D) = Halts(D,D)
>>>
>>> Not the same thing.
>>> ∃H ∈ C_Functions
>>> is not equivalent to
>>> ∃H ∈ Turing_Machines
>>>
>>> as there are many C_Functions that are not the equivalent of Turing
>>> Machines.
>>>
>>
>> The whole purpose here is to get you to understand what
>> templates are and how they reference infinite sets.
>>
>
> But the problem is that even in your formulation, H and D are, when
> doing the test, SPECIFIC PROGRAMS and not "templates" as Halts is
> defined on the domain of PROGRAMS.
>
> Similarly, a "Template" doesn't have a specific set of
> x86_Machine_Code_of_C_function, at least not one with defined behavior
> since if it tries to reference code outside of itself, then Halts of
> that just isn't defined, only Halts of that code + the specific machine
> deciding it.
>
>>>
>>>>
>>>> In both cases infinite sets are examined to see
>>>> if any H exists with the required properties.
>>>>
>>>
>>> Yes, but the logic of Turing Machines looks at them one at a time,
>>> and the input is a FULL INDEPENDENT PROGRAM.
>>>
>>
>> ∃H ∈ Turing_Machines
>> That does not look at one machine it looks as an infinite set of
>> machines. I am very happy to find out that you were not playing head
>> games. Linz actually used the words that you referred to.
>
> while the ∃H part can create a set of machines, each element of that set
> is INDIVIDUALLY TESTED in the following conditions, so, when we get to
> your test H(x,y) = Halts(x,x), each of H, x, y are individual members
> of the set, and we THEN collect the set of all of them.
>
> If we try to say
> ∃x ∈ Natural Numbers, such that x+x = 3
> we can't say that x is both 1 and 2 and thus as a set meet the
> requirement. For the conditions, each qualifier select a single
> prospective element, and those are tested to see if that meet the
> requirement.
>
So it never was about any specific machine as Linz misleading words
seemed to indicate. It was always about examining each element of an
infinite set.
Likewise: ∃H ∈ C_Functions is about examining each element
of an infinite set. A program template specifies a set of programs
the same way that an axiom schema specifies a set of axioms.
I am very happy that the issue was the misleading words of Linz
and not you playing head games.
--
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 07:31 -0400 |
| Message-ID | <v373mr$2d367$5@i2pn2.org> |
| In reply to | #334674 |
On 5/28/24 11:49 PM, olcott wrote:
> On 5/28/2024 10:38 PM, Richard Damon wrote:
>> On 5/28/24 10:23 PM, olcott wrote:
>>> On 5/28/2024 9:04 PM, Richard Damon wrote:
>>>> On 5/28/24 12:16 PM, olcott wrote:
>>>>> 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Â Â Â Â Â Â }
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> *Formalizing the Linz Proof structure*
>>>>> ∃H ∈ Turing_Machines
>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>> ∀y ∈ Finite_Strings
>>>>> such that H(x,y) = Halts(x,x)
>>>>
>>>> But since for x being the description of the H^ built from that H
>>>> and y being the same, it turns out that no matter what answer H
>>>> gives, it will be wrong.
>>>>
>>>
>>> We have not gotten to that point yet this post is so that
>>> you can fully understand what templates are and how they work.
>>
>> But note, x, being a Turing Machine, is NOT a "template"
>>
>> And H, isn't a "set of Turing Machines", but an arbitrary member of
>> that set, so all we need to do is find a single x, y, possible
>> determined as a function of H (so, BUILT from a template, but not a
>> template themselves) that shows that particular H was wrong.
>>
>>
>> That is basically what Linz does.
>>
>> Given a SPECIFIC (but arbitary) H, we can construct a specific H^
>> built from a template from H, that that H can not get right.
>>
>> All the other H's might get this input right, but we don't care, we
>> have shown that for every H we
>>
>>>
>>>> (And I think you have an error in your reference to Halts, I think
>>>> you mean Halts(x,y) not Halts(x,x)
>>>>
>>>
>>> Yes good catch. I was trying to model embedded_H / ⟨Ĥ⟩
>>> and then changed my mind to make it more general.
>>>
>>>>>
>>>>> *Here is the same thing applied to H/D pairs*
>>>>> ∃H ∈ C_Functions
>>>>> ∀D ∈ x86_Machine_Code_of_C_Functions
>>>>> such that H(D,D) = Halts(D,D)
>>>>
>>>> Not the same thing.
>>>> ∃H ∈ C_Functions
>>>> is not equivalent to
>>>> ∃H ∈ Turing_Machines
>>>>
>>>> as there are many C_Functions that are not the equivalent of Turing
>>>> Machines.
>>>>
>>>
>>> The whole purpose here is to get you to understand what
>>> templates are and how they reference infinite sets.
>>>
>>
>> But the problem is that even in your formulation, H and D are, when
>> doing the test, SPECIFIC PROGRAMS and not "templates" as Halts is
>> defined on the domain of PROGRAMS.
>>
>> Similarly, a "Template" doesn't have a specific set of
>> x86_Machine_Code_of_C_function, at least not one with defined behavior
>> since if it tries to reference code outside of itself, then Halts of
>> that just isn't defined, only Halts of that code + the specific
>> machine deciding it.
>>
>>>>
>>>>>
>>>>> In both cases infinite sets are examined to see
>>>>> if any H exists with the required properties.
>>>>>
>>>>
>>>> Yes, but the logic of Turing Machines looks at them one at a time,
>>>> and the input is a FULL INDEPENDENT PROGRAM.
>>>>
>>>
>>> ∃H ∈ Turing_Machines
>>> That does not look at one machine it looks as an infinite set of
>>> machines. I am very happy to find out that you were not playing head
>>> games. Linz actually used the words that you referred to.
>>
>> while the ∃H part can create a set of machines, each element of that
>> set is INDIVIDUALLY TESTED in the following conditions, so, when we
>> get to your test H(x,y) = Halts(x,x), each of H, x, y are individual
>> members of the set, and we THEN collect the set of all of them.
>>
>> If we try to say
>> ∃x ∈ Natural Numbers, such that x+x = 3
>> we can't say that x is both 1 and 2 and thus as a set meet the
>> requirement. For the conditions, each qualifier select a single
>> prospective element, and those are tested to see if that meet the
>> requirement.
>>
>
> So it never was about any specific machine as Linz misleading words
> seemed to indicate. It was always about examining each element of an
> infinite set.
No, you just don't understand how logic works.
The main body of the proof IS about a SPECIFIC (but arbitrary) machine
out of the infinite set.
>
> Likewise: ∃H ∈ C_Functions is about examining each element
> of an infinite set. A program template specifies a set of programs
> the same way that an axiom schema specifies a set of axioms.
Right EACH ELEMENT INDIVIDUALLY
>
> I am very happy that the issue was the misleading words of Linz
> and not you playing head games.
>
But you still don't seem to understand that the final statement
H(x,y) = Halts(x, y)
Is a statement about SPECIFIC Machines/inputs H, x, and y as individuals.
So, the evaluation of each term is done as an individual.
So, the question for THAT H, isn't can any machine in the do the
simulation for its paired machine, it is did THIS H get the right answer
for THIS input.
The fact that when H(D,D) says non-halting for the D built on it, but
that D when used to process D(D) will halt, says that H just fails the
requried test, so it CAN'T be an H that meets the requirements.
The fact that we can categorically do that for ALL Hs, that is find an
x, y that they will get wrong, says the claim of the existance of an H
that meets that requirement is a LIE.
You just don't understand how logic works, and think false statements
can be true, becuase you just don't care about truth, but have a
reckless disregard for it.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 08:49 -0500 |
| Message-ID | <v37bpa$15n0b$1@dont-email.me> |
| In reply to | #334678 |
On 5/29/2024 6:31 AM, Richard Damon wrote:
> On 5/28/24 11:49 PM, olcott wrote:
>> On 5/28/2024 10:38 PM, Richard Damon wrote:
>>> On 5/28/24 10:23 PM, olcott wrote:
>>>> On 5/28/2024 9:04 PM, Richard Damon wrote:
>>>>> On 5/28/24 12:16 PM, olcott wrote:
>>>>>> 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Â Â Â Â Â Â }
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> *Formalizing the Linz Proof structure*
>>>>>> ∃H ∈ Turing_Machines
>>>>>> ∀x ∈ Turing_Machines_Descriptions
>>>>>> ∀y ∈ Finite_Strings
>>>>>> such that H(x,y) = Halts(x,x)
>>>>>
>>>>> But since for x being the description of the H^ built from that H
>>>>> and y being the same, it turns out that no matter what answer H
>>>>> gives, it will be wrong.
>>>>>
>>>>
>>>> We have not gotten to that point yet this post is so that
>>>> you can fully understand what templates are and how they work.
>>>
>>> But note, x, being a Turing Machine, is NOT a "template"
>>>
>>> And H, isn't a "set of Turing Machines", but an arbitrary member of
>>> that set, so all we need to do is find a single x, y, possible
>>> determined as a function of H (so, BUILT from a template, but not a
>>> template themselves) that shows that particular H was wrong.
>>>
>>>
>>> That is basically what Linz does.
>>>
>>> Given a SPECIFIC (but arbitary) H, we can construct a specific H^
>>> built from a template from H, that that H can not get right.
>>>
>>> All the other H's might get this input right, but we don't care, we
>>> have shown that for every H we
>>>
>>>>
>>>>> (And I think you have an error in your reference to Halts, I think
>>>>> you mean Halts(x,y) not Halts(x,x)
>>>>>
>>>>
>>>> Yes good catch. I was trying to model embedded_H / ⟨Ĥ⟩
>>>> and then changed my mind to make it more general.
>>>>
>>>>>>
>>>>>> *Here is the same thing applied to H/D pairs*
>>>>>> ∃H ∈ C_Functions
>>>>>> ∀D ∈ x86_Machine_Code_of_C_Functions
>>>>>> such that H(D,D) = Halts(D,D)
>>>>>
>>>>> Not the same thing.
>>>>> ∃H ∈ C_Functions
>>>>> is not equivalent to
>>>>> ∃H ∈ Turing_Machines
>>>>>
>>>>> as there are many C_Functions that are not the equivalent of Turing
>>>>> Machines.
>>>>>
>>>>
>>>> The whole purpose here is to get you to understand what
>>>> templates are and how they reference infinite sets.
>>>>
>>>
>>> But the problem is that even in your formulation, H and D are, when
>>> doing the test, SPECIFIC PROGRAMS and not "templates" as Halts is
>>> defined on the domain of PROGRAMS.
>>>
>>> Similarly, a "Template" doesn't have a specific set of
>>> x86_Machine_Code_of_C_function, at least not one with defined
>>> behavior since if it tries to reference code outside of itself, then
>>> Halts of that just isn't defined, only Halts of that code + the
>>> specific machine deciding it.
>>>
>>>>>
>>>>>>
>>>>>> In both cases infinite sets are examined to see
>>>>>> if any H exists with the required properties.
>>>>>>
>>>>>
>>>>> Yes, but the logic of Turing Machines looks at them one at a time,
>>>>> and the input is a FULL INDEPENDENT PROGRAM.
>>>>>
>>>>
>>>> ∃H ∈ Turing_Machines
>>>> That does not look at one machine it looks as an infinite set of
>>>> machines. I am very happy to find out that you were not playing head
>>>> games. Linz actually used the words that you referred to.
>>>
>>> while the ∃H part can create a set of machines, each element of that
>>> set is INDIVIDUALLY TESTED in the following conditions, so, when we
>>> get to your test H(x,y) = Halts(x,x), each of H, x, y are individual
>>> members of the set, and we THEN collect the set of all of them.
>>>
>>> If we try to say
>>> ∃x ∈ Natural Numbers, such that x+x = 3
>>> we can't say that x is both 1 and 2 and thus as a set meet the
>>> requirement. For the conditions, each qualifier select a single
>>> prospective element, and those are tested to see if that meet the
>>> requirement.
>>>
>>
>> So it never was about any specific machine as Linz misleading words
>> seemed to indicate. It was always about examining each element of an
>> infinite set.
>
> No, you just don't understand how logic works.
>
*Sure I do or I could not have encoded this correctly*
Of the infinite set of Turing_Machines does there exist at
least one H that always gets this H(x,y) = Halts(x,y) correctly
for every {x,y} pair of the infinite set of {x,y} pairs?
*Formalizing the Linz Proof structure*
∃H ∈ Turing_Machines
∀x ∈ Turing_Machines_Descriptions
∀y ∈ Finite_Strings
such that H(x,y) = Halts(x,y)
Everyone that knows the truth knows that I am correct and you are wrong.
There is NO correct reasoning that can possibly show that I am wrong.
Mike Terry would know that I am correct. Ben might not understand
quantification. Ben did verify this encoding:
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*I might like this encoding better*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
--
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 | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2024-05-29 15:40 +0000 |
| Message-ID | <v37i9p$lls$1@news.muc.de> |
| In reply to | #334682 |
[ Followup-To: set ] In comp.theory olcott <polcott333@gmail.com> wrote: [ .... ] > Everyone that knows the truth knows that I am correct and you are wrong. > There is NO correct reasoning that can possibly show that I am wrong. Everybody here, bar one person, knows you are wrong. > Mike Terry would know that I am correct. Ben might not understand > quantification. Ben did verify this encoding: 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? [ .... ] > -- > Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius > hits a target no one else can see." Arthur Schopenhauer -- Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 11:21 -0500 |
| Message-ID | <v37klo$17606$2@dont-email.me> |
| In reply to | #334684 |
On 5/29/2024 10:40 AM, Alan Mackenzie wrote:
> [ Followup-To: set ]
>
> In comp.theory olcott <polcott333@gmail.com> wrote:
>
> [ .... ]
>
>> Everyone that knows the truth knows that I am correct and you are wrong.
>> There is NO correct reasoning that can possibly show that I am wrong.
>
> Everybody here, bar one person, knows you are wrong.
>
*Most everyone here believes that I am wrong at least somewhere*
When we go over what I am saying point by point and thus do not
allow the *strawman deception CHANGE-THE-SUBJECT fake rebuttal*
no one here have provided complete and correct reasoning that I
am wrong on any one point.
The point of this post is {templates and infinite sets}
*Formalizing the Linz Proof structure*
∃H ∈ Turing_Machines
∀x ∈ Turing_Machines_Descriptions
∀y ∈ Finite_Strings
such that H(x,y) = Halts(x,y)
*Here is the same sort of template to H/D pairs*
∃H ∈ C_Functions
∀D ∈ x86_Machine_Code_of_C_Functions
such that H(D,D) = Halts(D,D)
In both cases infinite sets are examined to see
if any H exists with the required properties.
--
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 13:31 -0500 |
| Subject | Two dozen people were simply wrong |
| Message-ID | <v37sap$18mfo$1@dont-email.me> |
| In reply to | #334684 |
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); }
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
*two dozen people were simply wrong*
It now turns out that Richard Damon was not lying when he referred
to the words of Peter Linz.
It did seem ridiculous that the Linz proof merely proved that
a single machine does not get the correct answer to a specific
input. Since Linz actually did use the term "single Turing machine"
I now see that was an honest mistake.
The domain of this problem is to be taken as the set of all
Turing machines and all w; that is, we are looking for a
*single Turing machine* that, given the description of an arbitrary
M and w, will predict whether or not the computation of M applied
to w will halt
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2024-05-29 20:17 +0000 |
| Subject | Re: Two dozen people were simply wrong |
| Message-ID | <v382go$tjb$1@news.muc.de> |
| In reply to | #334686 |
[ Followup-To: set ] In comp.theory olcott <polcott333@gmail.com> wrote: [ .... ] > 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 That reminds me of a sketch from Morecombe and Wise (for non-Brits: this was a stand-up comdedy show from 1970s British television. It was of extraordinarily high quality). It was where Eric Morecombe was pretending to be a concert pianist playing Grieg's piano concerto under conductor André Previn. As his limited pianistic capabilities became clear, on being accused of playing wrong notes, Eric replied, holding André threateningly by the lapels "I'm playing the right notes - maybe just not in the right order!". [ .... ] > -- > Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius > hits a target no one else can see." Arthur Schopenhauer -- Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 15:26 -0500 |
| Subject | Re: Two dozen people were simply wrong |
| Message-ID | <v3831l$19pmv$2@dont-email.me> |
| In reply to | #334687 |
On 5/29/2024 3:17 PM, Alan Mackenzie wrote: > [ Followup-To: set ] > > In comp.theory olcott <polcott333@gmail.com> wrote: > > [ .... ] > >> 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 > > That reminds me of a sketch from Morecombe and Wise (for non-Brits: this > was a stand-up comdedy show from 1970s British television. It was of > extraordinarily high quality). It was where Eric Morecombe was > pretending to be a concert pianist playing Grieg's piano concerto under > conductor André Previn. As his limited pianistic capabilities became > clear, on being accused of playing wrong notes, Eric replied, holding > André threateningly by the lapels "I'm playing the right notes - maybe > just not in the right order!". > *Yet still no actual review of what I actually said* *Yet still no actual review of what I actually said* *Yet still no actual review of what I actually said* *Yet still no actual review of what I actually said* *Yet still no actual review of what I actually said* > [ .... ] > >> -- >> Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius >> hits a target no one else can see." Arthur Schopenhauer > -- 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 16:14 -0500 |
| Subject | Re: Two dozen people were simply wrong |
| Message-ID | <v385sa$1a8iq$1@dont-email.me> |
| In reply to | #334687 |
On 5/29/2024 3:54 PM, Python wrote:
> Le 29/05/2024 à 22:25, olcott a écrit :
>> On 5/29/2024 3:17 PM, Alan Mackenzie wrote:
>>> [ Followup-To: set ]
>>>
>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>
>>> [ .... ]
>>>
>>>> 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
>>>
>>> That reminds me of a sketch from Morecombe and Wise (for non-Brits: this
>>> was a stand-up comdedy show from 1970s British television. It was of
>>> extraordinarily high quality). It was where Eric Morecombe was
>>> pretending to be a concert pianist playing Grieg's piano concerto under
>>> conductor André Previn. As his limited pianistic capabilities became
>>> clear, on being accused of playing wrong notes, Eric replied, holding
>>> André threateningly by the lapels "I'm playing the right notes - maybe
>>> just not in the right order!".
>>>
>>
>> *Yet still no actual review of what I actually said*
>
> Yet it is an accurate point about how your words are silly, pointless
> and ridiculous. On psychological point of view the fact you don't
> get that point is a clear sign of cognitive dissonance on your part.
>
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 }
The above template refers to an infinite set of H/D pairs where D is
correctly simulated by either pure simulator H or pure function H. This
was done because many reviewers used the shell game ploy to endlessly
switch which H/D pair was being referred to.
H correctly simulates 1 to ∞ steps of D with either pure function H or
pure simulator H. In none of these cases does the correctly simulated D
ever reach its own simulated final state and halt.
*In actual finite memory C the H/D pair would eventually crash*
*Correct Simulation Defined*
This is provided because many reviewers had a different notion of
correct simulation that diverges from this notion.
A simulator is an x86 emulator that correctly emulates 1 to N of the
x86 instructions of D in the order specified by the x86 instructions
of D. This may include M recursive emulations of H emulating itself
emulating D.
*Fully operational code proves recursive emulation*
When we see that D correctly simulated by pure simulator H would remain
stuck in infinite recursive simulation then we also know that less than
an infinite number of steps is not enough steps for D correctly
simulated by pure function H to reach its own simulated final state at
line 06 and halt.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-29 19:47 -0400 |
| Subject | Re: Two dozen people were simply wrong (including Olcott) |
| Message-ID | <v38eq4$2foi0$1@i2pn2.org> |
| In reply to | #334686 |
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.
So, you are just proving your stupidity.
> *two dozen people were simply wrong*
>
> It now turns out that Richard Damon was not lying when he referred
> to the words of Peter Linz.
>
> It did seem ridiculous that the Linz proof merely proved that
> a single machine does not get the correct answer to a specific
> input. Since Linz actually did use the term "single Turing machine"
> I now see that was an honest mistake.
>
> Â Â The domain of this problem is to be taken as the set of all
> Â Â Turing machines and all w; that is, we are looking for a
> Â Â *single Turing machine* that, given the description of an arbitrary
> Â Â M and w, will predict whether or not the computation of M applied
> Â Â to w will halt
>
Yep, you do that A LOT, which shows your reckless disregard for the truth.
Now, after proving that a specific (but arbitrarily chosen) H is wrong,
he is able to use categorical logic to show that NO H can be correct.
Something that seems to be beyond your understand.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 18:57 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38fe0$1bndb$1@dont-email.me> |
| In reply to | #334690 |
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.
*FULLY OPERATIONAL CODE DOES SHOW THIS*
I may not look at any of you other replies until after this
one 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-29 20:09 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38g31$2foi0$11@i2pn2.org> |
| In reply to | #334694 |
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.
>
> *FULLY OPERATIONAL CODE DOES SHOW THIS*
Nope
>
> I may not look at any of you other replies until after this
> one is fully resolved.
>
Good for you, just prove your reckless disregard for the truth that is
going to land you in Gehenna.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 19:17 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38gi5$1bndb$3@dont-email.me> |
| In reply to | #334696 |
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.
One element of the infinite set has been fully operational for
at least two years.
--
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 20:48 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38ici$2fohv$2@i2pn2.org> |
| In reply to | #334698 |
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.
>
> One element of the infinite set has been fully operational for
> at least two years.
>
So, all you have done is shown that the Linz proof doesn't work on your
POOP.
And that you just don't know what you are talking about when you try to
talk about the ACTUAL problems that most people care about.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-29 19:59 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38j17$1c8ir$2@dont-email.me> |
| In reply to | #334701 |
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.
--
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 21:07 -0400 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise |
| Message-ID | <v38jgo$2foi0$14@i2pn2.org> |
| In reply to | #334703 |
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?
Remember Halts(Turing_Machine_Description, Finite_String) is DEFINED to
be if the Turing Machine that the Turing_Machine_Description describes,
applied to the Finite_String will come to a final state in a finite
number of steps.
Yes, you don't give the Turing Machine H DIRECTLY a Turing Machine, you
do it by a Description/Representation, just like you do for most problems.
When you build a Turing Machine to add two number, you can't give it
"numbers" as those are not "Finite Strings", but they CAN be described
or represented by finite strings (in a number of different way).
Thus, via the method of Descriptions/Representiations, we can talk of
asking Turing Machines do "Decide on" the behaivor of a Turing machine,
but giving it the description of that machine, just as we can ask it to
do arithmetic by giving it descriptions of the numbers.
[toc] | [prev] | [next] | [standalone]
Page 1 of 13 [1] 2 3 … 13 Next page →
Back to top | Article view | sci.logic
csiph-web