Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #105649 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-05-28 11:16 -0500 |
| Last post | 2024-06-03 13:36 +0300 |
| Articles | 20 on this page of 361 — 14 participants |
Back to article view | Back to comp.theory
D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 11:16 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-28 22:04 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 21:23 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-28 23:38 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-28 22:49 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-05-29 12:14 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 08:24 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:01 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 20:09 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:21 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 20:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 19:53 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 21:02 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 20:12 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 21:25 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 20:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 22:25 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 21:36 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 22:55 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 22:48 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets joes <noreply@example.com> - 2024-05-30 09:11 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-30 08:11 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-05-30 19:58 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-05-30 12:11 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-30 07:33 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-05-31 11:51 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-05-31 11:15 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-05-31 16:12 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-30 07:32 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 07:31 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 08:49 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Alan Mackenzie <acm@muc.de> - 2024-05-29 15:40 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 11:17 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-29 18:08 +0100
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 12:32 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-29 13:08 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Ben Bacarisse <ben@bsb.me.uk> - 2024-05-29 19:14 +0100
Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 13:31 -0500
Re: Two dozen people were simply wrong Alan Mackenzie <acm@muc.de> - 2024-05-29 20:17 +0000
Re: Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 15:25 -0500
Re: Two dozen people were simply wrong Python <python@invalid.org> - 2024-05-29 22:54 +0200
Re: Two dozen people were simply wrong olcott <polcott333@gmail.com> - 2024-05-29 16:14 -0500
Re: Two dozen people were simply wrong (including Olcott) Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 18:57 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 20:09 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 19:17 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 20:48 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 19:59 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 21:07 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:15 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 21:24 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:24 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 20:48 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 21:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-29 22:55 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-29 22:58 -0500
Re: Olcott was simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 07:30 -0400
Re: Olcott was simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 09:04 -0500
Re: Olcott was simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise joes <noreply@example.com> - 2024-05-30 09:08 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 08:21 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-05-31 11:08 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- Mike Terry olcott <polcott333@gmail.com> - 2024-05-31 10:04 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-05-30 10:40 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 08:31 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 20:54 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 22:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 21:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 22:51 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 21:58 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-30 23:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 22:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 09:10 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 17:36 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 17:08 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 18:46 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 17:54 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 19:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 18:57 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 20:39 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 20:10 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 21:35 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 21:08 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-05-31 22:25 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-05-31 21:40 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 07:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:30 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:56 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 18:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:24 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 20:40 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:44 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 21:04 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:11 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 10:56 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:02 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 14:20 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-02 09:18 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:54 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:38 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 12:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 12:44 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 13:56 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:07 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 14:21 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:31 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 14:43 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:46 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:58 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 15:03 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:23 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 16:35 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 14:51 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 16:29 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 17:13 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 16:24 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 18:30 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 17:40 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 19:02 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 18:12 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 19:27 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 22:33 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 07:51 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:19 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 12:59 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 14:13 -0400
DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 13:29 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 15:05 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 14:13 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <Richard@Damon-Family.org> - 2024-06-02 15:22 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 14:34 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:11 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 15:21 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:32 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD immibis <news@immibis.com> - 2024-06-03 02:14 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 15:50 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 16:58 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 16:25 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 17:43 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 17:05 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 18:20 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 17:44 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 19:45 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 20:45 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 22:24 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 21:54 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-02 23:13 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-02 22:20 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 10:10 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-03 07:46 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:49 +0200
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD Richard Damon <richard@damon-family.org> - 2024-06-03 07:14 -0400
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD olcott <polcott333@gmail.com> - 2024-06-03 07:42 -0500
Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:51 +0200
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:34 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:13 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:03 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:41 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:13 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 13:53 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:59 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 15:07 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:55 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:53 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 20:26 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:32 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Mikko <mikko.levanto@iki.fi> - 2024-06-02 11:29 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-02 09:08 -0500
Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Mikko <mikko.levanto@iki.fi> - 2024-06-03 12:44 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-03 08:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Mikko <mikko.levanto@iki.fi> - 2024-06-03 17:35 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-03 13:19 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:51 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 14:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 11:01 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Wasell <wasell@example.com> - 2024-06-01 10:36 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 09:00 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:46 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:58 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:08 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 11:18 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 12:33 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 11:46 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 16:29 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 15:35 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 17:15 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 16:27 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 18:30 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-01 17:37 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-01 19:02 -0400
Re: Two dozen people were simply wrong --- joes <noreply@example.com> - 2024-06-02 09:36 +0000
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 09:58 -0500
Re: Olcott is simply wrong --- Richard Damon <richard@damon-family.org> - 2024-06-02 13:22 -0400
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:16 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:37 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:51 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:57 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 21:01 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 14:10 -0500
Re: Two dozen people were simply wrong --- Richard Damon <richard@damon-family.org> - 2024-06-02 15:18 -0400
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 09:37 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-03 07:24 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:53 +0200
Re: Two dozen people were simply wrong --- Richard Damon <richard@damon-family.org> - 2024-06-02 15:08 -0400
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 10:02 -0500
Re: Two dozen people were simply wrong --- joes <noreply@example.com> - 2024-06-02 17:55 +0000
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:08 -0500
Re: Two dozen people were simply wrong --- Richard Damon <richard@damon-family.org> - 2024-06-02 14:18 -0400
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:36 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:42 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:53 +0200
Re: Two dozen people were simply wrong --- olcott <polcott333@gmail.com> - 2024-06-02 13:58 -0500
Re: Two dozen people were simply wrong --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 09:40 +0200
Re: Two dozen people were simply wrong --- Alan Mackenzie <acm@muc.de> - 2024-06-02 21:02 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:24 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 09:47 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:24 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 13:39 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:55 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical olcott <polcott333@gmail.com> - 2024-06-02 14:01 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 09:50 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical Richard Damon <richard@damon-family.org> - 2024-06-02 14:59 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical immibis <news@immibis.com> - 2024-06-02 21:19 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down --- canonical immibis <news@immibis.com> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:49 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 10:57 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:17 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:32 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 10:51 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:02 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 18:06 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 11:22 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 12:34 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:54 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 19:12 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 20:52 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 19:04 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 15:01 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 23:35 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down Richard Damon <richard@damon-family.org> - 2024-06-01 11:49 -0400
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 18:59 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-01 18:41 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down olcott <polcott333@gmail.com> - 2024-06-01 13:45 -0500
Re: Two dozen people were simply right --- Try to prove otherwise --- pinned down joes <noreply@example.com> - 2024-06-02 09:46 +0000
Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down immibis <news@immibis.com> - 2024-06-01 14:48 +0200
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-05-31 11:30 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-31 10:13 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-06-03 13:03 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-06-03 08:16 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-06-03 17:49 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-06-03 13:20 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-06-04 11:40 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-06-04 12:46 -0500
Re: Two dozen people were simply wrong --- Try to prove otherwise Mikko <mikko.levanto@iki.fi> - 2024-05-31 11:22 +0300
Re: Two dozen people were simply wrong --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-31 10:07 -0500
Re: H is an incorrect x86 emulator immibis <news@immibis.com> - 2024-05-30 12:24 +0200
Re: Two dozen people were simply wrong immibis <news@immibis.com> - 2024-05-30 12:04 +0200
Re: Two dozen people were simply wrong Mikko <mikko.levanto@iki.fi> - 2024-06-01 11:23 +0300
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years olcott <polcott333@gmail.com> - 2024-06-01 10:09 -0500
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:18 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years olcott <polcott333@gmail.com> - 2024-06-01 10:44 -0500
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-01 17:58 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years immibis <news@immibis.com> - 2024-06-01 20:51 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years joes <noreply@example.com> - 2024-06-01 19:02 +0000
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years olcott <polcott333@gmail.com> - 2024-06-01 14:58 -0500
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years Richard Damon <richard@damon-family.org> - 2024-06-01 16:28 -0400
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years immibis <news@immibis.com> - 2024-06-01 23:36 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 11:28 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years immibis <news@immibis.com> - 2024-06-02 12:56 +0200
Re: Two dozen people were simply wrong -- Only basis for rebuttal in the last 3 years Mikko <mikko.levanto@iki.fi> - 2024-06-02 11:08 +0300
Re: Deciders are ONLY accountable for their actual inputs --- olcott <polcott333@gmail.com> - 2024-06-02 08:56 -0500
Re: Deciders are ONLY accountable for their actual inputs --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:39 +0200
Re: Deciders are ONLY accountable for their actual inputs --- olcott <polcott333@gmail.com> - 2024-06-02 13:46 -0500
Re: Deciders are ONLY accountable for their actual inputs --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-02 20:57 +0200
Re: Deciders are ONLY accountable for their actual inputs --- olcott <polcott333@gmail.com> - 2024-06-02 14:03 -0500
Re: Deciders are ONLY accountable for their actual inputs --- Richard Damon <richard@damon-family.org> - 2024-06-02 15:16 -0400
Re: Deciders are ONLY accountable for their actual inputs --- immibis <news@immibis.com> - 2024-06-02 21:20 +0200
Re: Deciders are ONLY accountable for their actual inputs --- immibis <news@immibis.com> - 2024-06-02 21:24 +0200
Re: Deciders are ONLY accountable for their actual inputs --- Richard Damon <richard@damon-family.org> - 2024-06-02 15:01 -0400
Re: Deciders are ONLY accountable for their actual inputs --- Mikko <mikko.levanto@iki.fi> - 2024-06-03 13:13 +0300
Re: Deciders are ONLY accountable for their actual inputs --- olcott <polcott333@gmail.com> - 2024-06-03 08:17 -0500
Re: Deciders are ONLY accountable for their actual inputs --- Mikko <mikko.levanto@iki.fi> - 2024-06-03 17:39 +0300
Re: Deciders are ONLY accountable for their actual inputs --- "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:55 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 09:43 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 15:59 +0100
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 10:21 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 17:13 +0100
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 11:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-30 21:51 +0100
Re: D correctly simulated by H cannot possibly halt --- Try to prove otherwise olcott <polcott333@gmail.com> - 2024-05-30 16:22 -0500
Re: D correctly simulated by H cannot possibly halt --- Try to prove otherwise immibis <news@immibis.com> - 2024-05-30 23:50 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- Mike Terry olcott <polcott333@gmail.com> - 2024-05-31 09:46 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 17:20 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 10:30 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 17:58 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 12:00 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 20:50 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 14:01 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 21:32 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 15:15 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-30 22:59 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 16:27 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders immibis <news@immibis.com> - 2024-05-30 23:51 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:10 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 22:33 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Jeff Barnett <jbb@notatt.com> - 2024-05-30 21:48 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:52 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 23:06 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders immibis <news@immibis.com> - 2024-05-31 10:41 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:16 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders André G. Isaak <agisaak@gm.invalid> - 2024-05-30 21:14 -0600
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-30 22:36 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-31 10:02 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-05-31 09:33 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-31 07:23 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders joes <noreply@example.com> - 2024-06-01 18:07 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders olcott <polcott333@gmail.com> - 2024-06-01 13:11 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-06-01 14:23 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets --- deciders Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-05-31 16:10 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-05-31 10:44 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-06-01 11:20 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-06-01 09:52 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-06-01 11:08 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets joes <noreply@example.com> - 2024-06-01 18:56 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-06-01 14:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Richard Damon <richard@damon-family.org> - 2024-06-01 16:29 -0400
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets immibis <news@immibis.com> - 2024-06-01 23:36 +0200
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets joes <noreply@example.com> - 2024-06-02 09:24 +0000
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-06-02 09:55 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-06-02 11:24 +0300
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets olcott <polcott333@gmail.com> - 2024-06-02 09:04 -0500
Re: D correctly simulated by H cannot possibly halt --- templates and infinite sets Mikko <mikko.levanto@iki.fi> - 2024-06-03 13:36 +0300
Page 9 of 19 — ← Prev page 1 … 7 8 [9] 10 11 … 19 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-02 19:45 -0400 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3j06k$2qu72$16@i2pn2.org> |
| In reply to | #106092 |
On 6/2/24 6:44 PM, olcott wrote:
> On 6/2/2024 5:20 PM, Richard Damon wrote:
>> On 6/2/24 6:05 PM, olcott wrote:
>>> On 6/2/2024 4:43 PM, Richard Damon wrote:
>>>> On 6/2/24 5:25 PM, olcott wrote:
>>>>> On 6/2/2024 3:58 PM, Richard Damon wrote:
>>>>>> On 6/2/24 4:50 PM, olcott wrote:
>>>>>>> *We can see that the following DD cannot possibly halt*
>>>>>>
>>>>>> Unless the HH(DD,DD) aborts its simulation and returns 0, then
>>>>>> DD(DD) will ALWAYS halt when directly called, which is the
>>>>>> definition of "Halting".
>>>>>>
>>>>>> Not your LIE that it pertains to partial simulations.
>>>>>>
>>>>>>> *when correctly simulated by every HH that can possibly exist*
>>>>>>
>>>>>> Except for EVERY HH that aborts its simulation and returns 0
>>>>>>
>>>>>
>>>>> This may be an ADD thing.
>>>>> For every HH that aborts its simulation and returns 0
>>>>> DD correctly simulated by this HH *DID NOT HALT AND NEVER WILL HALT*
>>>>
>>>> Except you mental problems are getting in YOUR way.
>>>>
>>>> You said that "DD Can not halt" NOT "the simulation by H of DD can
>>>> not Halt"
>>>>
>>>
>>> *I said neither of those things so it may be an ADD problem*
>>
>> I guess your medication is making you blind.
>>
>> Read the top line quoted from you on 6/2/24 4:50 PM
>>
>> You said:
>> "*We can see that the following DD cannot possibly halt*"
>>
>
> *Deceitfully taking things out of context*
>
> On 6/2/2024 3:50 PM, olcott wrote:
> > *We can see that the following DD cannot possibly halt*
> > *when correctly simulated by every HH that can possibly exist*
But the second line doesn't change the meaning of the first line, as
Halting ALWAYS (unless clearly modified) refers to the behavior of the
machine.
It just qualifies which DD we might be talking about.
Just like the sentence:
We can see that the house was red when the ball went through the window.
The ball going through the window doesn't affect the color attribute of
the house. It might qualify the WHEN (but Halting of a machine isn't
dependent on time) or which house we are talking about (so it clearly
makes it a DD that it paired to an HH), but it doesn't affect the color.
Just like the fact that you have given the description of this DD to HH,
doesn't affect the behavior of that instance of DD, it only might
indicate that it HAS been paired with such an HH and not some other thing.
>
>> Remember, Halting is defined as the MACHINE reaching a fianl state, so
>> trying to qualify it with a partial simulation is an irrelevent
>> qualification.
>>
>>
>>>
>>>> Those are DIFFERENT statements.
>>>>
>>>> DD WILL Halt.
>>>>
>>>> Your claim, that I will neither confirm or deny (until you can show
>>>> why I should), is that the simulation by H can never reach the
>>>> statement after the call instruction.
>>>>
>>>
>>> *Still not quite what I said*
>>
>> But you did in your message from 3:54 today earier in the thread:
>>
>> DD correctly emulated by HH with an x86 emulator cannot possibly
>> reach past its own machine instruction [00001c2e]
>>
>
> If you get my words 99.99999% perfectly then you screwed up
> far too much, thus 80% is not in the ballpark.
So, if you ever slightm
>
> *We can see that the following DD cannot possibly halt*
> *when correctly simulated by every HH that can possibly exist*
Nope ABSOLUTE LIE.
Hlating is a property of the MACHINE / PROGRAM, not the simulation.
DD(DD) WILL HALT as long as HH(DD,DD) returns 0, and any HH(DD,DD) that
doesn't return 0 fails to meet your requirement that HH be a decider, so
we can automatically filter those out.
You not understanding what your words mean is YOUR problem.
And you are just proving that you have a reckless disregard for the
truth, showing that you are just an ignorant pathologial liar.
You MIGHT be able to claim that the SIMULATION of DD when correctly
performed by HH can never reach a final state. That is the claim you
seem to be working on, which i will neither confirm nor deny until we
handle this issue.,
Your statement about HALTING is just incorrect.
Try to PROVE your statement
Quote ACTULAL Definitions and accepted scholarly publish works in the field.
So far, it is just "Olcott says" and Olcott has been proven to LIE and
is often mistaken, so not a reliable source.
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-02 20:45 -0500 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3j76v$3j83v$1@dont-email.me> |
| In reply to | #106093 |
On 6/2/2024 6:45 PM, Richard Damon wrote:
> On 6/2/24 6:44 PM, olcott wrote:
>> On 6/2/2024 5:20 PM, Richard Damon wrote:
>>> On 6/2/24 6:05 PM, olcott wrote:
>>>> On 6/2/2024 4:43 PM, Richard Damon wrote:
>>>>> On 6/2/24 5:25 PM, olcott wrote:
>>>>>> On 6/2/2024 3:58 PM, Richard Damon wrote:
>>>>>>> On 6/2/24 4:50 PM, olcott wrote:
>>>>>>>> *We can see that the following DD cannot possibly halt*
>>>>>>>
>>>>>>> Unless the HH(DD,DD) aborts its simulation and returns 0, then
>>>>>>> DD(DD) will ALWAYS halt when directly called, which is the
>>>>>>> definition of "Halting".
>>>>>>>
>>>>>>> Not your LIE that it pertains to partial simulations.
>>>>>>>
>>>>>>>> *when correctly simulated by every HH that can possibly exist*
>>>>>>>
>>>>>>> Except for EVERY HH that aborts its simulation and returns 0
>>>>>>>
>>>>>>
>>>>>> This may be an ADD thing.
>>>>>> For every HH that aborts its simulation and returns 0
>>>>>> DD correctly simulated by this HH *DID NOT HALT AND NEVER WILL HALT*
>>>>>
>>>>> Except you mental problems are getting in YOUR way.
>>>>>
>>>>> You said that "DD Can not halt" NOT "the simulation by H of DD can
>>>>> not Halt"
>>>>>
>>>>
>>>> *I said neither of those things so it may be an ADD problem*
>>>
>>> I guess your medication is making you blind.
>>>
>>> Read the top line quoted from you on 6/2/24 4:50 PM
>>>
>>> You said:
>>> "*We can see that the following DD cannot possibly halt*"
>>>
>>
>> *Deceitfully taking things out of context*
>>
>> On 6/2/2024 3:50 PM, olcott wrote:
>> > *We can see that the following DD cannot possibly halt*
>> > *when correctly simulated by every HH that can possibly exist*
>
> But the second line doesn't change the meaning of the first line, as
> Halting ALWAYS (unless clearly modified) refers to the behavior of the
> machine.
>
I was wrong to call you deceitful on this, I sincerely apologize.
The above two lines are the same single sentence that I wanted
to make bold. Putting a period at the end or not breaking it up
into two lines makes bold not work.
> It just qualifies which DD we might be talking about.
>
> Just like the sentence:
>
My whole point has ALWAYS been DD correctly simulated by HH.
DD specifies non-halting behavior to the simulator/UTM aspect
of DD. DD(DD) has different behavior that decider HH is not
actually held accountable for. HH is ONLY held accountable
for the behavior that DD specifies to its simulator/UTM aspect.
> We can see that the house was red when the ball went through the window.
>
> The ball going through the window doesn't affect the color attribute of
> the house. It might qualify the WHEN (but Halting of a machine isn't
> dependent on time) or which house we are talking about (so it clearly
> makes it a DD that it paired to an HH), but it doesn't affect the color.
>
> Just like the fact that you have given the description of this DD to HH,
> doesn't affect the behavior of that instance of DD, it only might
> indicate that it HAS been paired with such an HH and not some other thing.
>
>>
>>> Remember, Halting is defined as the MACHINE reaching a fianl state,
>>> so trying to qualify it with a partial simulation is an irrelevent
>>> qualification.
>>>
>>>
>>>>
>>>>> Those are DIFFERENT statements.
>>>>>
>>>>> DD WILL Halt.
>>>>>
>>>>> Your claim, that I will neither confirm or deny (until you can show
>>>>> why I should), is that the simulation by H can never reach the
>>>>> statement after the call instruction.
>>>>>
>>>>
>>>> *Still not quite what I said*
>>>
>>> But you did in your message from 3:54 today earier in the thread:
>>>
>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>> reach past its own machine instruction [00001c2e]
>>>
>>
>> If you get my words 99.99999% perfectly then you screwed up
>> far too much, thus 80% is not in the ballpark.
>
> So, if you ever slightm
>
>>
>> *We can see that the following DD cannot possibly halt*
>> *when correctly simulated by every HH that can possibly exist*
>
> Nope ABSOLUTE LIE.
>
*If it was even incorrect then you could show a counter-example*
That it is categorically impossible to show a counter-example
conclusively proves that it is correct. I really hope that you are
merely confused about this. I really hope you are not risking your
salvation.
> Hlating is a property of the MACHINE / PROGRAM, not the simulation.
>
> DD(DD) WILL HALT as long as HH(DD,DD) returns 0, and any HH(DD,DD) that
> doesn't return 0 fails to meet your requirement that HH be a decider, so
> we can automatically filter those out.
>
My whole point has ALWAYS been DD correctly simulated by HH.
DD specifies non-halting behavior to the simulator/UTM aspect
of DD. DD(DD) has different behavior that decider HH is not
actually held accountable for. HH is ONLY held accountable
for the behavior that DD specifies to its simulator/UTM aspect.
> You not understanding what your words mean is YOUR problem.
>
> And you are just proving that you have a reckless disregard for the
> truth, showing that you are just an ignorant pathologial liar.
>
I really hope that you are merely confused about this.
I really hope you are not risking your salvation.
> You MIGHT be able to claim that the SIMULATION of DD when correctly
> performed by HH can never reach a final state. That is the claim you
> seem to be working on, which i will neither confirm nor deny until we
> handle this issue.,
>
*DD simulated by HH cannot possibly halt*
Saying the opposite way makes it looks like HH is not a good
enough simulator. HH is a perfectly correct simulator of its N
steps of correct simulation. After N steps of correct simulation
HH correctly recognizes that DD cannot possibly halt no matter
how many steps are simulated.
> Your statement about HALTING is just incorrect.
>
Not at all. It has always been correct and you have denied the
verified facts. If this is through confusion then there is no
risk to your salvation. I really hope it is because of confusion.
I don't want you to lose your salvation.
> Try to PROVE your statement
>
> Quote ACTULAL Definitions and accepted scholarly publish works in the
> field.
>
> So far, it is just "Olcott says" and Olcott has been proven to LIE and
> is often mistaken, so not a reliable source.
>
For the last few months I HAVE ONLY BEEN TALKING ABOUT
SOFTWARE ENGINEERING AND YOU HAVE CONSISTENTLY DENIED
THE VERIFIED SOFTWARE ENGINEERING FACTS.
There is no HH that can possibly exist such that DD correctly
simulated by HH can possibly reach past its own line 03.
>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C
>> 00 int HH(ptr p, ptr i);
>> 01 int DD(ptr p)
>> 02 {
>> 03 int Halt_Status = HH(p, p);
>> 04 if (Halt_Status)
>> 05 HERE: goto HERE;
>> 06 return Halt_Status;
>> 07 }
>>
>> _DD()
>> [00001c22] 55 push ebp
>> [00001c23] 8bec mov ebp,esp
>> [00001c25] 51 push ecx
>> [00001c26] 8b4508 mov eax,[ebp+08]
>> [00001c29] 50 push eax ; push DD 1c22
>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>> [00001c2d] 51 push ecx ; push DD 1c22
>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>> [00001c33] 83c408 add esp,+08
>> [00001c36] 8945fc mov [ebp-04],eax
>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>> [00001c3d] 7402 jz 00001c41
>> [00001c3f] ebfe jmp 00001c3f
>> [00001c41] 8b45fc mov eax,[ebp-04]
>> [00001c44] 8be5 mov esp,ebp
>> [00001c46] 5d pop ebp
>> [00001c47] c3 ret
>> Size in bytes:(0038) [00001c47]
>>
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-02 22:24 -0400 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3j9h3$2qu72$18@i2pn2.org> |
| In reply to | #106097 |
On 6/2/24 9:45 PM, olcott wrote:
> On 6/2/2024 6:45 PM, Richard Damon wrote:
>> On 6/2/24 6:44 PM, olcott wrote:
>>> On 6/2/2024 5:20 PM, Richard Damon wrote:
>>>> On 6/2/24 6:05 PM, olcott wrote:
>>>>> On 6/2/2024 4:43 PM, Richard Damon wrote:
>>>>>> On 6/2/24 5:25 PM, olcott wrote:
>>>>>>> On 6/2/2024 3:58 PM, Richard Damon wrote:
>>>>>>>> On 6/2/24 4:50 PM, olcott wrote:
>>>>>>>>> *We can see that the following DD cannot possibly halt*
>>>>>>>>
>>>>>>>> Unless the HH(DD,DD) aborts its simulation and returns 0, then
>>>>>>>> DD(DD) will ALWAYS halt when directly called, which is the
>>>>>>>> definition of "Halting".
>>>>>>>>
>>>>>>>> Not your LIE that it pertains to partial simulations.
>>>>>>>>
>>>>>>>>> *when correctly simulated by every HH that can possibly exist*
>>>>>>>>
>>>>>>>> Except for EVERY HH that aborts its simulation and returns 0
>>>>>>>>
>>>>>>>
>>>>>>> This may be an ADD thing.
>>>>>>> For every HH that aborts its simulation and returns 0
>>>>>>> DD correctly simulated by this HH *DID NOT HALT AND NEVER WILL HALT*
>>>>>>
>>>>>> Except you mental problems are getting in YOUR way.
>>>>>>
>>>>>> You said that "DD Can not halt" NOT "the simulation by H of DD can
>>>>>> not Halt"
>>>>>>
>>>>>
>>>>> *I said neither of those things so it may be an ADD problem*
>>>>
>>>> I guess your medication is making you blind.
>>>>
>>>> Read the top line quoted from you on 6/2/24 4:50 PM
>>>>
>>>> You said:
>>>> "*We can see that the following DD cannot possibly halt*"
>>>>
>>>
>>> *Deceitfully taking things out of context*
>>>
>>> On 6/2/2024 3:50 PM, olcott wrote:
>>> > *We can see that the following DD cannot possibly halt*
>>> > *when correctly simulated by every HH that can possibly exist*
>>
>> But the second line doesn't change the meaning of the first line, as
>> Halting ALWAYS (unless clearly modified) refers to the behavior of the
>> machine.
>>
>
> I was wrong to call you deceitful on this, I sincerely apologize.
> The above two lines are the same single sentence that I wanted
> to make bold. Putting a period at the end or not breaking it up
> into two lines makes bold not work.
>
>> It just qualifies which DD we might be talking about.
>>
>> Just like the sentence:
>>
>
> My whole point has ALWAYS been DD correctly simulated by HH.
Which means NOTHING, as your definition of "correctly Simulated" doesn't
meet the requirements to talk about the behavior of the machine
described by the input.
You don't seem to understand that you can't just "redefine" the system
to meet your desires.
That is why all you are actually talking about is POOP.
> DD specifies non-halting behavior to the simulator/UTM aspect
> of DD. DD(DD) has different behavior that decider HH is not
> actually held accountable for. HH is ONLY held accountable
> for the behavior that DD specifies to its simulator/UTM aspect.
Then it just isn't a Halt Decider. PERIOD, and your whole arguement
fails, and is based on just lying.
As I have pointed out, by your definitions, a triial decider can just
declare that virtual all input are non-halting and be "just as correct",
since the logic you try to use is just invalid.
>
>> We can see that the house was red when the ball went through the window.
>>
>> The ball going through the window doesn't affect the color attribute
>> of the house. It might qualify the WHEN (but Halting of a machine
>> isn't dependent on time) or which house we are talking about (so it
>> clearly makes it a DD that it paired to an HH), but it doesn't affect
>> the color.
>>
>> Just like the fact that you have given the description of this DD to
>> HH, doesn't affect the behavior of that instance of DD, it only might
>> indicate that it HAS been paired with such an HH and not some other
>> thing.
>>
>>>
>>>> Remember, Halting is defined as the MACHINE reaching a fianl state,
>>>> so trying to qualify it with a partial simulation is an irrelevent
>>>> qualification.
>>>>
>>>>
>>>>>
>>>>>> Those are DIFFERENT statements.
>>>>>>
>>>>>> DD WILL Halt.
>>>>>>
>>>>>> Your claim, that I will neither confirm or deny (until you can
>>>>>> show why I should), is that the simulation by H can never reach
>>>>>> the statement after the call instruction.
>>>>>>
>>>>>
>>>>> *Still not quite what I said*
>>>>
>>>> But you did in your message from 3:54 today earier in the thread:
>>>>
>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>> reach past its own machine instruction [00001c2e]
>>>>
>>>
>>> If you get my words 99.99999% perfectly then you screwed up
>>> far too much, thus 80% is not in the ballpark.
>>
>> So, if you ever slightm
>>
>>>
>>> *We can see that the following DD cannot possibly halt*
>>> *when correctly simulated by every HH that can possibly exist*
>>
>> Nope ABSOLUTE LIE.
>>
>
> *If it was even incorrect then you could show a counter-example*
>
D(D) is the counter example.
D(D) Halts if H(D,D) returns 0.
The fact you want the question to be different doesn't make it different.
Remember, adding the condition of "When Correctly simulated by evdry HH
that can possible exist" doesn't change the meaning of the first line to
refer to the actual machine, which is what the term Halting will refer
to. It just might qualify what DD we are talking about
You might be able to make the claim that no simulation of DD can
possible reach a final state of the simulated DD ...
I won't verify that to be correct, but that seems to be the statement
you want to make, but then it doesn't make it sound like you are solving
the halting problem.
> That it is categorically impossible to show a counter-example
> conclusively proves that it is correct. I really hope that you are
> merely confused about this. I really hope you are not risking your
> salvation.
But the fact the counter example HAS been shown just shows you to be a liar.
>
>> Hlating is a property of the MACHINE / PROGRAM, not the simulation.
>>
>> DD(DD) WILL HALT as long as HH(DD,DD) returns 0, and any HH(DD,DD)
>> that doesn't return 0 fails to meet your requirement that HH be a
>> decider, so we can automatically filter those out.
>>
>
> My whole point has ALWAYS been DD correctly simulated by HH.
> DD specifies non-halting behavior to the simulator/UTM aspect
> of DD. DD(DD) has different behavior that decider HH is not
> actually held accountable for. HH is ONLY held accountable
> for the behavior that DD specifies to its simulator/UTM aspect.
But that just points out that you are just being deceptive.
Halting is ALWAYS about the actual behavior of the machine.
And, your HH is NOT a UTM if it aborts its simulatin, no matter how much
you want to try to claim it to be, as if FUNDAMENTALLY breaks the
definition.
It is like taking an electric car, and remove the electric motors and
replace with a gas engine, and then trying to say you still have an
electric car, because that is what you started with until you "enhanced it".
>
>> You not understanding what your words mean is YOUR problem.
>>
>> And you are just proving that you have a reckless disregard for the
>> truth, showing that you are just an ignorant pathologial liar.
>>
>
> I really hope that you are merely confused about this.
> I really hope you are not risking your salvation.
I know I am not, but your repeated deceptions make it clear you never
had one.
>
>> You MIGHT be able to claim that the SIMULATION of DD when correctly
>> performed by HH can never reach a final state. That is the claim you
>> seem to be working on, which i will neither confirm nor deny until we
>> handle this issue.,
>>
>
> *DD simulated by HH cannot possibly halt*
> Saying the opposite way makes it looks like HH is not a good
> enough simulator. HH is a perfectly correct simulator of its N
> steps of correct simulation. After N steps of correct simulation
> HH correctly recognizes that DD cannot possibly halt no matter
> how many steps are simulated.
But as I have said, DD does halt.
And the problem is that HH ISN'T a good enough simulator to be able to
use its result to decide halting, because partial simulation never prove
non-halting behavior.
The problem is you forget that HH is what HH is, and thus it can't argue
that ir it was something different than what it actually is, and in a
why that changes the contents of the input give to it (which includes
the HH that DD calls) without invoking invalid logic.
SO, since HH DOES abort its simulation, its logi must be consistant with
that behavior, and not think about the non-existant case where the input
is based on a different machine.
That just proves your ignorance and deceptive nature.
>
>> Your statement about HALTING is just incorrect.
>>
>
> Not at all. It has always been correct and you have denied the
> verified facts. If this is through confusion then there is no
> risk to your salvation. I really hope it is because of confusion.
> I don't want you to lose your salvation.
Nope. You just don't understand what you are talking about,
Your facts are NOT verified, but are just your own fabrications.
The problem is you seem to have
>
>> Try to PROVE your statement
>>
>> Quote ACTULAL Definitions and accepted scholarly publish works in the
>> field.
>>
>> So far, it is just "Olcott says" and Olcott has been proven to LIE and
>> is often mistaken, so not a reliable source.
>>
>
> For the last few months I HAVE ONLY BEEN TALKING ABOUT
> SOFTWARE ENGINEERING AND YOU HAVE CONSISTENTLY DENIED
> THE VERIFIED SOFTWARE ENGINEERING FACTS.
But your "facts" are not Software Engineering facts.
Can you actually quote a SOURCE for your claims?
SOmething accepted by the general community?
I don't think you actually know what that is, and you think that
anything you think up and seems right to you is a "verified fact"
That just shows how much of a pathological liar you are.
From what I have seen, you are little more than a hack programmer who
doesn't understand the basic princples of Software Engineering.
>
> There is no HH that can possibly exist such that DD correctly
> simulated by HH can possibly reach past its own line 03.
That might be true, and I will refuse to confirm or deny that fact,
because it is meaningless.
The error comes when you rephrase that to say that DD doesn't Halt. and
THAT is just a blantant lie.
>
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int HH(ptr p, ptr i);
>>> 01 int DD(ptr p)
>>> 02 {
>>> 03 int Halt_Status = HH(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>>
>>> _DD()
>>> [00001c22] 55 push ebp
>>> [00001c23] 8bec mov ebp,esp
>>> [00001c25] 51 push ecx
>>> [00001c26] 8b4508 mov eax,[ebp+08]
>>> [00001c29] 50 push eax ; push DD 1c22
>>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>>> [00001c2d] 51 push ecx ; push DD 1c22
>>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>>> [00001c33] 83c408 add esp,+08
>>> [00001c36] 8945fc mov [ebp-04],eax
>>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>>> [00001c3d] 7402 jz 00001c41
>>> [00001c3f] ebfe jmp 00001c3f
>>> [00001c41] 8b45fc mov eax,[ebp-04]
>>> [00001c44] 8be5 mov esp,ebp
>>> [00001c46] 5d pop ebp
>>> [00001c47] c3 ret
>>> Size in bytes:(0038) [00001c47]
>>>
>>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-02 21:54 -0500 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3jb9l$3nor9$1@dont-email.me> |
| In reply to | #106098 |
On 6/2/2024 9:24 PM, Richard Damon wrote:
> On 6/2/24 9:45 PM, olcott wrote:
>> On 6/2/2024 6:45 PM, Richard Damon wrote:
>>> On 6/2/24 6:44 PM, olcott wrote:
>>>> On 6/2/2024 5:20 PM, Richard Damon wrote:
>>>>> On 6/2/24 6:05 PM, olcott wrote:
>>>>>> On 6/2/2024 4:43 PM, Richard Damon wrote:
>>>>>>> On 6/2/24 5:25 PM, olcott wrote:
>>>>>>>> On 6/2/2024 3:58 PM, Richard Damon wrote:
>>>>>>>>> On 6/2/24 4:50 PM, olcott wrote:
>>>>>>>>>> *We can see that the following DD cannot possibly halt*
>>>>>>>>>
>>>>>>>>> Unless the HH(DD,DD) aborts its simulation and returns 0, then
>>>>>>>>> DD(DD) will ALWAYS halt when directly called, which is the
>>>>>>>>> definition of "Halting".
>>>>>>>>>
>>>>>>>>> Not your LIE that it pertains to partial simulations.
>>>>>>>>>
>>>>>>>>>> *when correctly simulated by every HH that can possibly exist*
>>>>>>>>>
>>>>>>>>> Except for EVERY HH that aborts its simulation and returns 0
>>>>>>>>>
>>>>>>>>
>>>>>>>> This may be an ADD thing.
>>>>>>>> For every HH that aborts its simulation and returns 0
>>>>>>>> DD correctly simulated by this HH *DID NOT HALT AND NEVER WILL
>>>>>>>> HALT*
>>>>>>>
>>>>>>> Except you mental problems are getting in YOUR way.
>>>>>>>
>>>>>>> You said that "DD Can not halt" NOT "the simulation by H of DD
>>>>>>> can not Halt"
>>>>>>>
>>>>>>
>>>>>> *I said neither of those things so it may be an ADD problem*
>>>>>
>>>>> I guess your medication is making you blind.
>>>>>
>>>>> Read the top line quoted from you on 6/2/24 4:50 PM
>>>>>
>>>>> You said:
>>>>> "*We can see that the following DD cannot possibly halt*"
>>>>>
>>>>
>>>> *Deceitfully taking things out of context*
>>>>
>>>> On 6/2/2024 3:50 PM, olcott wrote:
>>>> > *We can see that the following DD cannot possibly halt*
>>>> > *when correctly simulated by every HH that can possibly exist*
>>>
>>> But the second line doesn't change the meaning of the first line, as
>>> Halting ALWAYS (unless clearly modified) refers to the behavior of
>>> the machine.
>>>
>>
>> I was wrong to call you deceitful on this, I sincerely apologize.
>> The above two lines are the same single sentence that I wanted
>> to make bold. Putting a period at the end or not breaking it up
>> into two lines makes bold not work.
>>
>>> It just qualifies which DD we might be talking about.
>>>
>>> Just like the sentence:
>>>
>>
>> My whole point has ALWAYS been DD correctly simulated by HH.
>
> Which means NOTHING, as your definition of "correctly Simulated" doesn't
> meet the requirements to talk about the behavior of the machine
> described by the input.
>
IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE IN[UT SPECIFIES.
That you did get confused by the Linz text proves that you do
get confused. Previously it looked just like willful deception.
> You don't seem to understand that you can't just "redefine" the system
> to meet your desires.
>
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
You can't get away with implicitly saying that you
just don't "believe in" UTMs.
You can't get away with implicitly saying that you
just don't "believe in" UTMs.
You can't get away with implicitly saying that you
just don't "believe in" UTMs.
> That is why all you are actually talking about is POOP.
>
>> DD specifies non-halting behavior to the simulator/UTM aspect
>> of DD. DD(DD) has different behavior that decider HH is not
>> actually held accountable for. HH is ONLY held accountable
>> for the behavior that DD specifies to its simulator/UTM aspect.
>
> Then it just isn't a Halt Decider. PERIOD, and your whole arguement
> fails, and is based on just lying.
>
Deciders compute the mapping FROM THEIR INPUTS.
DD correctly simulated by HH specifies NON-HALTING.
You can't get away with implicitly saying that you
just don't "believe in" UTMs.
> As I have pointed out, by your definitions, a triial decider can just
> declare that virtual all input are non-halting and be "just as correct",
> since the logic you try to use is just invalid.
>
>>
>>> We can see that the house was red when the ball went through the window.
>>>
>>> The ball going through the window doesn't affect the color attribute
>>> of the house. It might qualify the WHEN (but Halting of a machine
>>> isn't dependent on time) or which house we are talking about (so it
>>> clearly makes it a DD that it paired to an HH), but it doesn't affect
>>> the color.
>>>
>>> Just like the fact that you have given the description of this DD to
>>> HH, doesn't affect the behavior of that instance of DD, it only might
>>> indicate that it HAS been paired with such an HH and not some other
>>> thing.
>>>
>>>>
>>>>> Remember, Halting is defined as the MACHINE reaching a fianl state,
>>>>> so trying to qualify it with a partial simulation is an irrelevent
>>>>> qualification.
>>>>>
>>>>>
>>>>>>
>>>>>>> Those are DIFFERENT statements.
>>>>>>>
>>>>>>> DD WILL Halt.
>>>>>>>
>>>>>>> Your claim, that I will neither confirm or deny (until you can
>>>>>>> show why I should), is that the simulation by H can never reach
>>>>>>> the statement after the call instruction.
>>>>>>>
>>>>>>
>>>>>> *Still not quite what I said*
>>>>>
>>>>> But you did in your message from 3:54 today earier in the thread:
>>>>>
>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>> reach past its own machine instruction [00001c2e]
>>>>>
>>>>
>>>> If you get my words 99.99999% perfectly then you screwed up
>>>> far too much, thus 80% is not in the ballpark.
>>>
>>> So, if you ever slightm
>>>
>>>>
>>>> *We can see that the following DD cannot possibly halt*
>>>> *when correctly simulated by every HH that can possibly exist*
>>>
>>> Nope ABSOLUTE LIE.
>>>
>>
>> *If it was even incorrect then you could show a counter-example*
>>
>
> D(D) is the counter example.
Liar Liar Pants ON Fire
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-02 23:13 -0400 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3jccs$2qu72$19@i2pn2.org> |
| In reply to | #106099 |
On 6/2/24 10:54 PM, olcott wrote:
> On 6/2/2024 9:24 PM, Richard Damon wrote:
>> On 6/2/24 9:45 PM, olcott wrote:
>>> On 6/2/2024 6:45 PM, Richard Damon wrote:
>>>> On 6/2/24 6:44 PM, olcott wrote:
>>>>> On 6/2/2024 5:20 PM, Richard Damon wrote:
>>>>>> On 6/2/24 6:05 PM, olcott wrote:
>>>>>>> On 6/2/2024 4:43 PM, Richard Damon wrote:
>>>>>>>> On 6/2/24 5:25 PM, olcott wrote:
>>>>>>>>> On 6/2/2024 3:58 PM, Richard Damon wrote:
>>>>>>>>>> On 6/2/24 4:50 PM, olcott wrote:
>>>>>>>>>>> *We can see that the following DD cannot possibly halt*
>>>>>>>>>>
>>>>>>>>>> Unless the HH(DD,DD) aborts its simulation and returns 0, then
>>>>>>>>>> DD(DD) will ALWAYS halt when directly called, which is the
>>>>>>>>>> definition of "Halting".
>>>>>>>>>>
>>>>>>>>>> Not your LIE that it pertains to partial simulations.
>>>>>>>>>>
>>>>>>>>>>> *when correctly simulated by every HH that can possibly exist*
>>>>>>>>>>
>>>>>>>>>> Except for EVERY HH that aborts its simulation and returns 0
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This may be an ADD thing.
>>>>>>>>> For every HH that aborts its simulation and returns 0
>>>>>>>>> DD correctly simulated by this HH *DID NOT HALT AND NEVER WILL
>>>>>>>>> HALT*
>>>>>>>>
>>>>>>>> Except you mental problems are getting in YOUR way.
>>>>>>>>
>>>>>>>> You said that "DD Can not halt" NOT "the simulation by H of DD
>>>>>>>> can not Halt"
>>>>>>>>
>>>>>>>
>>>>>>> *I said neither of those things so it may be an ADD problem*
>>>>>>
>>>>>> I guess your medication is making you blind.
>>>>>>
>>>>>> Read the top line quoted from you on 6/2/24 4:50 PM
>>>>>>
>>>>>> You said:
>>>>>> "*We can see that the following DD cannot possibly halt*"
>>>>>>
>>>>>
>>>>> *Deceitfully taking things out of context*
>>>>>
>>>>> On 6/2/2024 3:50 PM, olcott wrote:
>>>>> > *We can see that the following DD cannot possibly halt*
>>>>> > *when correctly simulated by every HH that can possibly exist*
>>>>
>>>> But the second line doesn't change the meaning of the first line, as
>>>> Halting ALWAYS (unless clearly modified) refers to the behavior of
>>>> the machine.
>>>>
>>>
>>> I was wrong to call you deceitful on this, I sincerely apologize.
>>> The above two lines are the same single sentence that I wanted
>>> to make bold. Putting a period at the end or not breaking it up
>>> into two lines makes bold not work.
>>>
>>>> It just qualifies which DD we might be talking about.
>>>>
>>>> Just like the sentence:
>>>>
>>>
>>> My whole point has ALWAYS been DD correctly simulated by HH.
>>
>> Which means NOTHING, as your definition of "correctly Simulated"
>> doesn't meet the requirements to talk about the behavior of the
>> machine described by the input.
>>
>
> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE IN[UT SPECIFIES.
> That you did get confused by the Linz text proves that you do
> get confused. Previously it looked just like willful deception.
Which is, for a Halt Decider, exactly and only the behavior of the
Turing Machine the input describes.
PERIOD.
Anything else is just a LIE.
>
>> You don't seem to understand that you can't just "redefine" the system
>> to meet your desires.
>>
>
> Deciders compute the mapping FROM THEIR INPUTS.
> DD correctly simulated by HH specifies NON-HALTING.
No, Running DD(DD) and seeing that it will never, after an unbounded
number of steps, indicate it is non-halting.
DEFINITION.
>
> Deciders compute the mapping FROM THEIR INPUTS.
> DD correctly simulated by HH specifies NON-HALTING.
Right, and the input is a representation of a Turing Machine and its
input, whose behavior the decider is to decide on.
>
> Deciders compute the mapping FROM THEIR INPUTS.
> DD correctly simulated by HH specifies NON-HALTING.
>
And that is the machine the input describes.
ANYTHING ELSE IS JUST A LIE.
> You can't get away with implicitly saying that you
> just don't "believe in" UTMs.
I do, and a UTM is DEFINED as a machine that exactly reproduces the
behavior of the machine described by its input.
>
> You can't get away with implicitly saying that you
> just don't "believe in" UTMs.
Right, but it seems you don't, as you think something that doesn't meet
the minimum requirement to be one could be one.
>
> You can't get away with implicitly saying that you
> just don't "believe in" UTMs.
I don't, you just don't understand what they are, because you just don't
understand what a Turing machine is.
Key point, there is NO requirement that a UTM simulate thorough an exact
sequence of equivalent states of the machine it is "simulating". The
ONLY requirement is that its output exactly match the output of the
described machine.
>
>> That is why all you are actually talking about is POOP.
>>
>>> DD specifies non-halting behavior to the simulator/UTM aspect
>>> of DD. DD(DD) has different behavior that decider HH is not
>>> actually held accountable for. HH is ONLY held accountable
>>> for the behavior that DD specifies to its simulator/UTM aspect.
>>
>> Then it just isn't a Halt Decider. PERIOD, and your whole arguement
>> fails, and is based on just lying.
>>
>
> Deciders compute the mapping FROM THEIR INPUTS.
> DD correctly simulated by HH specifies NON-HALTING.
Nope.
A decide compute the mapping from their inputs to the corresponding
value of the function they are computing.
A Halt Decider is computing the results of the Halts Function, which
indicates if the described machine will halt or not when run.
THus H(D,D) NEEDS to generate the results of Halts(D,D) which will be
true if D(D) will eventually halt in a finite number of steps, or false
if D(D) will never reach a final state after even an unbounded number of
states.
SInce D(D) Does Halt if H(D,D) returns 0, H(D,D) returning 0 is NEVER a
correct answer.
>
> You can't get away with implicitly saying that you
> just don't "believe in" UTMs.
I don't, you are just impuing a LIE, becaue you don't understand what
they actually are.
>
>> As I have pointed out, by your definitions, a triial decider can just
>> declare that virtual all input are non-halting and be "just as
>> correct", since the logic you try to use is just invalid.
>>
>>>
>>>> We can see that the house was red when the ball went through the
>>>> window.
>>>>
>>>> The ball going through the window doesn't affect the color attribute
>>>> of the house. It might qualify the WHEN (but Halting of a machine
>>>> isn't dependent on time) or which house we are talking about (so it
>>>> clearly makes it a DD that it paired to an HH), but it doesn't
>>>> affect the color.
>>>>
>>>> Just like the fact that you have given the description of this DD to
>>>> HH, doesn't affect the behavior of that instance of DD, it only
>>>> might indicate that it HAS been paired with such an HH and not some
>>>> other thing.
>>>>
>>>>>
>>>>>> Remember, Halting is defined as the MACHINE reaching a fianl
>>>>>> state, so trying to qualify it with a partial simulation is an
>>>>>> irrelevent qualification.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> Those are DIFFERENT statements.
>>>>>>>>
>>>>>>>> DD WILL Halt.
>>>>>>>>
>>>>>>>> Your claim, that I will neither confirm or deny (until you can
>>>>>>>> show why I should), is that the simulation by H can never reach
>>>>>>>> the statement after the call instruction.
>>>>>>>>
>>>>>>>
>>>>>>> *Still not quite what I said*
>>>>>>
>>>>>> But you did in your message from 3:54 today earier in the thread:
>>>>>>
>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>> reach past its own machine instruction [00001c2e]
>>>>>>
>>>>>
>>>>> If you get my words 99.99999% perfectly then you screwed up
>>>>> far too much, thus 80% is not in the ballpark.
>>>>
>>>> So, if you ever slightm
>>>>
>>>>>
>>>>> *We can see that the following DD cannot possibly halt*
>>>>> *when correctly simulated by every HH that can possibly exist*
>>>>
>>>> Nope ABSOLUTE LIE.
>>>>
>>>
>>> *If it was even incorrect then you could show a counter-example*
>>>
>>
>> D(D) is the counter example.
>
> Liar Liar Pants ON Fire
Then why does it halt when run?
>
> *We can see that the following DD cannot possibly halt when*
> *correctly simulated by every HH that can possibly exist*
But the question isn't about it being simulated, but being run.
Guess you are just showing how stupid you are.
So, whose pants are on fire?
>
> *We can see that the following DD cannot possibly halt when*
> *correctly simulated by every HH that can possibly exist*
Just repeating the lie doesn't make it more true.
>
> *We can see that the following DD cannot possibly halt when*
> *correctly simulated by every HH that can possibly exist*
Third time is the charm, proves it wasn't a honest mistake, here comes
the lake of fire for you.
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-02 22:20 -0500 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3jcqb$3nv01$1@dont-email.me> |
| In reply to | #106100 |
On 6/2/2024 10:13 PM, Richard Damon wrote:
> On 6/2/24 10:54 PM, olcott wrote:
>> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
>> That you did get confused by the Linz text proves that you do
>> get confused. Previously it looked just like willful deception.
>
> Which is, for a Halt Decider, exactly and only the behavior of the
> Turing Machine the input describes.
>
> PERIOD.
>
> Anything else is just a LIE.
>
>>
>>> You don't seem to understand that you can't just "redefine" the
>>> system to meet your desires.
>>>
>>
>> Deciders compute the mapping FROM THEIR INPUTS.
>> DD correctly simulated by HH specifies NON-HALTING.
>
> No, Running DD(DD) and seeing that it will never, after an unbounded
> number of steps, indicate it is non-halting.
>
> DEFINITION.
>
>>
>> Deciders compute the mapping FROM THEIR INPUTS.
>> DD correctly simulated by HH specifies NON-HALTING.
>
> Right, and the input is a representation of a Turing Machine and its
> input, whose behavior the decider is to decide on.
>
>>
>> Deciders compute the mapping FROM THEIR INPUTS.
>> DD correctly simulated by HH specifies NON-HALTING.
>>
>
> And that is the machine the input describes.
>
> ANYTHING ELSE IS JUST A LIE.
>
>> You can't get away with implicitly saying that you
>> just don't "believe in" UTMs.
>
> I do, and a UTM is DEFINED as a machine that exactly reproduces the
> behavior of the machine described by its input.
>
*If that was true then you prove that this statement is false*
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-03 10:10 +0200 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3jtpe$3qblu$2@dont-email.me> |
| In reply to | #106101 |
Op 03.jun.2024 om 05:20 schreef olcott:
> On 6/2/2024 10:13 PM, Richard Damon wrote:
>> On 6/2/24 10:54 PM, olcott wrote:
>>> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
>>> That you did get confused by the Linz text proves that you do
>>> get confused. Previously it looked just like willful deception.
>>
>> Which is, for a Halt Decider, exactly and only the behavior of the
>> Turing Machine the input describes.
>>
>> PERIOD.
>>
>> Anything else is just a LIE.
>>
>>>
>>>> You don't seem to understand that you can't just "redefine" the
>>>> system to meet your desires.
>>>>
>>>
>>> Deciders compute the mapping FROM THEIR INPUTS.
>>> DD correctly simulated by HH specifies NON-HALTING.
>>
>> No, Running DD(DD) and seeing that it will never, after an unbounded
>> number of steps, indicate it is non-halting.
>>
>> DEFINITION.
>>
>>>
>>> Deciders compute the mapping FROM THEIR INPUTS.
>>> DD correctly simulated by HH specifies NON-HALTING.
>>
>> Right, and the input is a representation of a Turing Machine and its
>> input, whose behavior the decider is to decide on.
>>
>>>
>>> Deciders compute the mapping FROM THEIR INPUTS.
>>> DD correctly simulated by HH specifies NON-HALTING.
>>>
>>
>> And that is the machine the input describes.
>>
>> ANYTHING ELSE IS JUST A LIE.
>>
>>> You can't get away with implicitly saying that you
>>> just don't "believe in" UTMs.
>>
>> I do, and a UTM is DEFINED as a machine that exactly reproduces the
>> behavior of the machine described by its input.
>>
>
> *If that was true then you prove that this statement is false*
> *We can see that the following DD cannot possibly halt when*
> *correctly simulated by every HH that can possibly exist*
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
It is clear (both from the C code as from the compiled code) that at the
moment that the outer simulator reaches the place where DD calls HH then
HH finds *itself* in a 'repeated state'. At that same moment DD is *not*
(yet) in a repeated state. (DD may get in a repeated state if the called
HH would start a new simulation.) So, the only conclusion is that it is
HH that displays repetition. And because of that DD will repeat as well.
By using simulation, a new halting problem is introduced, that has
nothing to do with the pathological part of DD n lines 04, 05 and 06.
This pathological part is not even processed by the simulation.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 07:46 -0500 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3kduv$3stk9$6@dont-email.me> |
| In reply to | #106112 |
On 6/3/2024 3:10 AM, Fred. Zwarts wrote:
> Op 03.jun.2024 om 05:20 schreef olcott:
>> On 6/2/2024 10:13 PM, Richard Damon wrote:
>>> On 6/2/24 10:54 PM, olcott wrote:
>>>> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
>>>> That you did get confused by the Linz text proves that you do
>>>> get confused. Previously it looked just like willful deception.
>>>
>>> Which is, for a Halt Decider, exactly and only the behavior of the
>>> Turing Machine the input describes.
>>>
>>> PERIOD.
>>>
>>> Anything else is just a LIE.
>>>
>>>>
>>>>> You don't seem to understand that you can't just "redefine" the
>>>>> system to meet your desires.
>>>>>
>>>>
>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>
>>> No, Running DD(DD) and seeing that it will never, after an unbounded
>>> number of steps, indicate it is non-halting.
>>>
>>> DEFINITION.
>>>
>>>>
>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>
>>> Right, and the input is a representation of a Turing Machine and its
>>> input, whose behavior the decider is to decide on.
>>>
>>>>
>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>
>>>
>>> And that is the machine the input describes.
>>>
>>> ANYTHING ELSE IS JUST A LIE.
>>>
>>>> You can't get away with implicitly saying that you
>>>> just don't "believe in" UTMs.
>>>
>>> I do, and a UTM is DEFINED as a machine that exactly reproduces the
>>> behavior of the machine described by its input.
>>>
>>
>> *If that was true then you prove that this statement is false*
>> *We can see that the following DD cannot possibly halt when*
>> *correctly simulated by every HH that can possibly exist*
>>
>> typedef int (*ptr)(); // ptr is pointer to int function in C
>> 00 int HH(ptr p, ptr i);
>> 01 int DD(ptr p)
>> 02 {
>> 03 int Halt_Status = HH(p, p);
>> 04 if (Halt_Status)
>> 05 HERE: goto HERE;
>> 06 return Halt_Status;
>> 07 }
>>
>> _DD()
>> [00001c22] 55 push ebp
>> [00001c23] 8bec mov ebp,esp
>> [00001c25] 51 push ecx
>> [00001c26] 8b4508 mov eax,[ebp+08]
>> [00001c29] 50 push eax ; push DD 1c22
>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>> [00001c2d] 51 push ecx ; push DD 1c22
>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>> [00001c33] 83c408 add esp,+08
>> [00001c36] 8945fc mov [ebp-04],eax
>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>> [00001c3d] 7402 jz 00001c41
>> [00001c3f] ebfe jmp 00001c3f
>> [00001c41] 8b45fc mov eax,[ebp-04]
>> [00001c44] 8be5 mov esp,ebp
>> [00001c46] 5d pop ebp
>> [00001c47] c3 ret
>> Size in bytes:(0038) [00001c47]
>>
>
> It is clear (both from the C code as from the compiled code) that at the
> moment that the outer simulator reaches the place where DD calls HH then
> HH finds *itself* in a 'repeated state'. At that same moment DD is *not*
> (yet) in a repeated state. (DD may get in a repeated state if the called
> HH would start a new simulation.) So, the only conclusion is that it is
> HH that displays repetition. And because of that DD will repeat as well.
>
> By using simulation, a new halting problem is introduced, that has
> nothing to do with the pathological part of DD n lines 04, 05 and 06.
> This pathological part is not even processed by the simulation.
DD correctly simulated by HH meets this criteria:
On 10/13/2022 11:29:23 AM
MIT Professor Michael Sipser agreed this verbatim paragraph is correct
(He has neither reviewed nor agreed to anything else in this paper)
<Professor Sipser agreed>
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then
H can abort its simulation of D and correctly report that D specifies a
non-halting sequence of configurations.
</Professor Sipser agreed>
Therefore HH(DD,DD) == 0 is correct.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-03 21:49 +0200 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3l6nn$13cp$2@dont-email.me> |
| In reply to | #106129 |
Op 03.jun.2024 om 14:46 schreef olcott:
> On 6/3/2024 3:10 AM, Fred. Zwarts wrote:
>> Op 03.jun.2024 om 05:20 schreef olcott:
>>> On 6/2/2024 10:13 PM, Richard Damon wrote:
>>>> On 6/2/24 10:54 PM, olcott wrote:
>>>>> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
>>>>> That you did get confused by the Linz text proves that you do
>>>>> get confused. Previously it looked just like willful deception.
>>>>
>>>> Which is, for a Halt Decider, exactly and only the behavior of the
>>>> Turing Machine the input describes.
>>>>
>>>> PERIOD.
>>>>
>>>> Anything else is just a LIE.
>>>>
>>>>>
>>>>>> You don't seem to understand that you can't just "redefine" the
>>>>>> system to meet your desires.
>>>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>
>>>> No, Running DD(DD) and seeing that it will never, after an unbounded
>>>> number of steps, indicate it is non-halting.
>>>>
>>>> DEFINITION.
>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>
>>>> Right, and the input is a representation of a Turing Machine and its
>>>> input, whose behavior the decider is to decide on.
>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>>
>>>>
>>>> And that is the machine the input describes.
>>>>
>>>> ANYTHING ELSE IS JUST A LIE.
>>>>
>>>>> You can't get away with implicitly saying that you
>>>>> just don't "believe in" UTMs.
>>>>
>>>> I do, and a UTM is DEFINED as a machine that exactly reproduces the
>>>> behavior of the machine described by its input.
>>>>
>>>
>>> *If that was true then you prove that this statement is false*
>>> *We can see that the following DD cannot possibly halt when*
>>> *correctly simulated by every HH that can possibly exist*
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int HH(ptr p, ptr i);
>>> 01 int DD(ptr p)
>>> 02 {
>>> 03 int Halt_Status = HH(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>>
>>> _DD()
>>> [00001c22] 55 push ebp
>>> [00001c23] 8bec mov ebp,esp
>>> [00001c25] 51 push ecx
>>> [00001c26] 8b4508 mov eax,[ebp+08]
>>> [00001c29] 50 push eax ; push DD 1c22
>>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>>> [00001c2d] 51 push ecx ; push DD 1c22
>>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>>> [00001c33] 83c408 add esp,+08
>>> [00001c36] 8945fc mov [ebp-04],eax
>>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>>> [00001c3d] 7402 jz 00001c41
>>> [00001c3f] ebfe jmp 00001c3f
>>> [00001c41] 8b45fc mov eax,[ebp-04]
>>> [00001c44] 8be5 mov esp,ebp
>>> [00001c46] 5d pop ebp
>>> [00001c47] c3 ret
>>> Size in bytes:(0038) [00001c47]
>>>
>>
>> It is clear (both from the C code as from the compiled code) that at
>> the moment that the outer simulator reaches the place where DD calls
>> HH then HH finds *itself* in a 'repeated state'. At that same moment
>> DD is *not* (yet) in a repeated state. (DD may get in a repeated state
>> if the called HH would start a new simulation.) So, the only
>> conclusion is that it is HH that displays repetition. And because of
>> that DD will repeat as well.
>>
>> By using simulation, a new halting problem is introduced, that has
>> nothing to do with the pathological part of DD n lines 04, 05 and 06.
>> This pathological part is not even processed by the simulation.
>
> DD correctly simulated by HH meets this criteria:
>
> On 10/13/2022 11:29:23 AM
> MIT Professor Michael Sipser agreed this verbatim paragraph is correct
> (He has neither reviewed nor agreed to anything else in this paper)
>
> <Professor Sipser agreed>
> If simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D would never stop running
> unless aborted then
>
> H can abort its simulation of D and correctly report that D specifies a
> non-halting sequence of configurations.
> </Professor Sipser agreed>
>
> Therefore HH(DD,DD) == 0 is correct.
>
Which means that HH (as part of DD) does not halt.
--
Paradoxes in the relation between Creator and creature.
<http://www.wirholt.nl/English>.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-03 20:56 -0400 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3loo4$2uv04$8@i2pn2.org> |
| In reply to | #106129 |
On 6/3/24 8:46 AM, olcott wrote:
> On 6/3/2024 3:10 AM, Fred. Zwarts wrote:
>> Op 03.jun.2024 om 05:20 schreef olcott:
>>> On 6/2/2024 10:13 PM, Richard Damon wrote:
>>>> On 6/2/24 10:54 PM, olcott wrote:
>>>>> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
>>>>> That you did get confused by the Linz text proves that you do
>>>>> get confused. Previously it looked just like willful deception.
>>>>
>>>> Which is, for a Halt Decider, exactly and only the behavior of the
>>>> Turing Machine the input describes.
>>>>
>>>> PERIOD.
>>>>
>>>> Anything else is just a LIE.
>>>>
>>>>>
>>>>>> You don't seem to understand that you can't just "redefine" the
>>>>>> system to meet your desires.
>>>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>
>>>> No, Running DD(DD) and seeing that it will never, after an unbounded
>>>> number of steps, indicate it is non-halting.
>>>>
>>>> DEFINITION.
>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>
>>>> Right, and the input is a representation of a Turing Machine and its
>>>> input, whose behavior the decider is to decide on.
>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>>
>>>>
>>>> And that is the machine the input describes.
>>>>
>>>> ANYTHING ELSE IS JUST A LIE.
>>>>
>>>>> You can't get away with implicitly saying that you
>>>>> just don't "believe in" UTMs.
>>>>
>>>> I do, and a UTM is DEFINED as a machine that exactly reproduces the
>>>> behavior of the machine described by its input.
>>>>
>>>
>>> *If that was true then you prove that this statement is false*
>>> *We can see that the following DD cannot possibly halt when*
>>> *correctly simulated by every HH that can possibly exist*
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int HH(ptr p, ptr i);
>>> 01 int DD(ptr p)
>>> 02 {
>>> 03 int Halt_Status = HH(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>>
>>> _DD()
>>> [00001c22] 55 push ebp
>>> [00001c23] 8bec mov ebp,esp
>>> [00001c25] 51 push ecx
>>> [00001c26] 8b4508 mov eax,[ebp+08]
>>> [00001c29] 50 push eax ; push DD 1c22
>>> [00001c2a] 8b4d08 mov ecx,[ebp+08]
>>> [00001c2d] 51 push ecx ; push DD 1c22
>>> [00001c2e] e80ff7ffff call 00001342 ; call HH
>>> [00001c33] 83c408 add esp,+08
>>> [00001c36] 8945fc mov [ebp-04],eax
>>> [00001c39] 837dfc00 cmp dword [ebp-04],+00
>>> [00001c3d] 7402 jz 00001c41
>>> [00001c3f] ebfe jmp 00001c3f
>>> [00001c41] 8b45fc mov eax,[ebp-04]
>>> [00001c44] 8be5 mov esp,ebp
>>> [00001c46] 5d pop ebp
>>> [00001c47] c3 ret
>>> Size in bytes:(0038) [00001c47]
>>>
>>
>> It is clear (both from the C code as from the compiled code) that at
>> the moment that the outer simulator reaches the place where DD calls
>> HH then HH finds *itself* in a 'repeated state'. At that same moment
>> DD is *not* (yet) in a repeated state. (DD may get in a repeated state
>> if the called HH would start a new simulation.) So, the only
>> conclusion is that it is HH that displays repetition. And because of
>> that DD will repeat as well.
>>
>> By using simulation, a new halting problem is introduced, that has
>> nothing to do with the pathological part of DD n lines 04, 05 and 06.
>> This pathological part is not even processed by the simulation.
>
> DD correctly simulated by HH meets this criteria:
>
> On 10/13/2022 11:29:23 AM
> MIT Professor Michael Sipser agreed this verbatim paragraph is correct
> (He has neither reviewed nor agreed to anything else in this paper)
>
> <Professor Sipser agreed>
> If simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D would never stop running
> unless aborted then
>
> H can abort its simulation of D and correctly report that D specifies a
> non-halting sequence of configurations.
> </Professor Sipser agreed>
>
> Therefore HH(DD,DD) == 0 is correct.
>
Nope.
Until you can show an H that DOES "correctly" (when that includes the
requirement of completely) simulate its input and also aborts its
simulation (which is a clear contradiction of terms) you can not use
your phrase as stated.
You are just proven to be an ignorant pathological liar.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-03 07:14 -0400 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3k8j2$2scls$2@i2pn2.org> |
| In reply to | #106101 |
On 6/2/24 11:20 PM, olcott wrote:
> On 6/2/2024 10:13 PM, Richard Damon wrote:
>> On 6/2/24 10:54 PM, olcott wrote:
>>> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
>>> That you did get confused by the Linz text proves that you do
>>> get confused. Previously it looked just like willful deception.
>>
>> Which is, for a Halt Decider, exactly and only the behavior of the
>> Turing Machine the input describes.
>>
>> PERIOD.
>>
>> Anything else is just a LIE.
>>
>>>
>>>> You don't seem to understand that you can't just "redefine" the
>>>> system to meet your desires.
>>>>
>>>
>>> Deciders compute the mapping FROM THEIR INPUTS.
>>> DD correctly simulated by HH specifies NON-HALTING.
>>
>> No, Running DD(DD) and seeing that it will never, after an unbounded
>> number of steps, indicate it is non-halting.
>>
>> DEFINITION.
>>
>>>
>>> Deciders compute the mapping FROM THEIR INPUTS.
>>> DD correctly simulated by HH specifies NON-HALTING.
>>
>> Right, and the input is a representation of a Turing Machine and its
>> input, whose behavior the decider is to decide on.
>>
>>>
>>> Deciders compute the mapping FROM THEIR INPUTS.
>>> DD correctly simulated by HH specifies NON-HALTING.
>>>
>>
>> And that is the machine the input describes.
>>
>> ANYTHING ELSE IS JUST A LIE.
>>
>>> You can't get away with implicitly saying that you
>>> just don't "believe in" UTMs.
>>
>> I do, and a UTM is DEFINED as a machine that exactly reproduces the
>> behavior of the machine described by its input.
>>
>
> *If that was true then you prove that this statement is false*
> *We can see that the following DD cannot possibly halt when*
> *correctly simulated by every HH that can possibly exist*
I have.
You keep of forgetting that the phrase "DD cannot possibly halt" means,
and only mean, that the direct execution of DD can not possible reach a
final state.
Thus, the subordinate clause "when correctly simulated by evry HH that
can possible exist" doesn't change the base condition of what is being
measured, but perhaps the time when you make that measurement (a
non-sence concept as the property does change with time) or which DD we
are looking at, which just means that we are looking at a DD that has
been paired with an HH that does your correct partial simulation of DD.
So, given the requirement that your HH be a decider, we can remove from
the set of HHs that we can use, those that never abort there simulation,
and thus every HH in your set, when passed DD, has been show to ALWAY
return 0.
Thus, the trace of DD(DD) shows that it will call HH(DD,DD), and that
will run for some period of time, and then it will abort its "correct"
(but partial) simulation of DD (which doesn't show DD to be non-halting,
just didn't halt yet) and return 0 to DD which will then Halt.
Thus, we have DISPROVED your statement, YET AGAIN, proving you to be a
liar that just doesn't understand what he is talking about.
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 07:42 -0500 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3kdn1$3stk9$5@dont-email.me> |
| In reply to | #106123 |
On 6/3/2024 6:14 AM, Richard Damon wrote:
> On 6/2/24 11:20 PM, olcott wrote:
>> On 6/2/2024 10:13 PM, Richard Damon wrote:
>>> On 6/2/24 10:54 PM, olcott wrote:
>>>> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
>>>> That you did get confused by the Linz text proves that you do
>>>> get confused. Previously it looked just like willful deception.
>>>
>>> Which is, for a Halt Decider, exactly and only the behavior of the
>>> Turing Machine the input describes.
>>>
>>> PERIOD.
>>>
>>> Anything else is just a LIE.
>>>
>>>>
>>>>> You don't seem to understand that you can't just "redefine" the
>>>>> system to meet your desires.
>>>>>
>>>>
>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>
>>> No, Running DD(DD) and seeing that it will never, after an unbounded
>>> number of steps, indicate it is non-halting.
>>>
>>> DEFINITION.
>>>
>>>>
>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>
>>> Right, and the input is a representation of a Turing Machine and its
>>> input, whose behavior the decider is to decide on.
>>>
>>>>
>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>
>>>
>>> And that is the machine the input describes.
>>>
>>> ANYTHING ELSE IS JUST A LIE.
>>>
>>>> You can't get away with implicitly saying that you
>>>> just don't "believe in" UTMs.
>>>
>>> I do, and a UTM is DEFINED as a machine that exactly reproduces the
>>> behavior of the machine described by its input.
>>>
>>
>> *If that was true then you prove that this statement is false*
>> *We can see that the following DD cannot possibly halt when*
>> *correctly simulated by every HH that can possibly exist*
>
> I have.
>
> You keep of forgetting that the phrase "DD cannot possibly halt" means,
This eliminates the problem of you dishonestly removing context
*DD correctly emulated by any HH that can possibly exist DOES NOT HALT*
*DD correctly emulated by any HH that can possibly exist DOES NOT HALT*
*DD correctly emulated by any HH that can possibly exist DOES NOT HALT*
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-03 21:51 +0200 |
| Subject | Re: DD correctly simulated by HH cannot possible halt --- Try to prove otherwise --- x86 DD |
| Message-ID | <v3l6r7$13cp$3@dont-email.me> |
| In reply to | #106128 |
Op 03.jun.2024 om 14:42 schreef olcott:
> On 6/3/2024 6:14 AM, Richard Damon wrote:
>> On 6/2/24 11:20 PM, olcott wrote:
>>> On 6/2/2024 10:13 PM, Richard Damon wrote:
>>>> On 6/2/24 10:54 PM, olcott wrote:
>>>>> IT HAS ALWAYS BEEN ABOUT THE BEHAVIOR THAT THE INPUT SPECIFIES.
>>>>> That you did get confused by the Linz text proves that you do
>>>>> get confused. Previously it looked just like willful deception.
>>>>
>>>> Which is, for a Halt Decider, exactly and only the behavior of the
>>>> Turing Machine the input describes.
>>>>
>>>> PERIOD.
>>>>
>>>> Anything else is just a LIE.
>>>>
>>>>>
>>>>>> You don't seem to understand that you can't just "redefine" the
>>>>>> system to meet your desires.
>>>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>
>>>> No, Running DD(DD) and seeing that it will never, after an unbounded
>>>> number of steps, indicate it is non-halting.
>>>>
>>>> DEFINITION.
>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>
>>>> Right, and the input is a representation of a Turing Machine and its
>>>> input, whose behavior the decider is to decide on.
>>>>
>>>>>
>>>>> Deciders compute the mapping FROM THEIR INPUTS.
>>>>> DD correctly simulated by HH specifies NON-HALTING.
>>>>>
>>>>
>>>> And that is the machine the input describes.
>>>>
>>>> ANYTHING ELSE IS JUST A LIE.
>>>>
>>>>> You can't get away with implicitly saying that you
>>>>> just don't "believe in" UTMs.
>>>>
>>>> I do, and a UTM is DEFINED as a machine that exactly reproduces the
>>>> behavior of the machine described by its input.
>>>>
>>>
>>> *If that was true then you prove that this statement is false*
>>> *We can see that the following DD cannot possibly halt when*
>>> *correctly simulated by every HH that can possibly exist*
>>
>> I have.
>>
>> You keep of forgetting that the phrase "DD cannot possibly halt" means,
>
> This eliminates the problem of you dishonestly removing context
> *DD correctly emulated by any HH that can possibly exist DOES NOT HALT*
> *DD correctly emulated by any HH that can possibly exist DOES NOT HALT*
> *DD correctly emulated by any HH that can possibly exist DOES NOT HALT*
Because *HH* correctly emulated by any HH that can possibly exist DOES
NOT HALT
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
--
Paradoxes in the relation between Creator and creature.
<http://www.wirholt.nl/English>.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-02 20:34 +0200 |
| Subject | Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3idvb$3f51j$5@dont-email.me> |
| In reply to | #106033 |
Op 02.jun.2024 om 19:59 schreef olcott:
> On 6/2/2024 12:22 PM, Richard Damon wrote:
>> On 6/2/24 10:19 AM, olcott wrote:
>>> On 6/2/2024 6:51 AM, Richard Damon wrote:
>>>> On 6/1/24 11:33 PM, olcott wrote:
>>>>> On 6/1/2024 6:27 PM, Richard Damon wrote:
>>>>>> On 6/1/24 7:12 PM, olcott wrote:
>>>>>>> On 6/1/2024 6:02 PM, Richard Damon wrote:
>>>>>>>> On 6/1/24 6:40 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>> Show me where I said anything in the above spec about an
>>>>>>>>> aborted simulation.
>>>>>>>>
>>>>>>>> So, why did HH stop simulating after some n steps?
>>>>>>>>
>>>>>>>> Did it reach a final state in the simulation? if not, it ABORTED
>>>>>>>> its simulation.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> When every possible which way DD correctly simulated by HH
>>>>>>>>> never reaches
>>>>>>>>> past its own simulated line 03 then
>>>>>>>>
>>>>>>>> And a simulation either goes until it reaches a final state of
>>>>>>>> the machine it is simulating, or it aborted its simulation.
>>>>>>>>
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>> 01 int DD(ptr p)
>>>>>>> 02 {
>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>> 04 if (Halt_Status)
>>>>>>> 05 HERE: goto HERE;
>>>>>>> 06 return Halt_Status;
>>>>>>> 07 }
>>>>>>> 08
>>>>>>> 09 int main()
>>>>>>> 10 {
>>>>>>> 11 HH(DD,DD);
>>>>>>> 12 return 0;
>>>>>>> 13 }
>>>>>>>
>>>>>>> When every DD correctly simulated by any HH cannot possibly reach
>>>>>>> past its own simulated line 03 in 1 to ∞ steps of correct simulation
>>>>>>> of DD by HH then we have exhaustively examined every possible HH/DD
>>>>>>> pair and each element has of this infinite set has the same
>>>>>>> property.
>>>>>>
>>>>>> So?
>>>>>>
>>>>>> It doesn't matter how many aborted simulaiton you do of a given
>>>>>> input (and each HH simulated a DIFFERENT input since it simulated
>>>>>> the INSTANCE of the template with a different HH)
>>>>>>
>>>>>
>>>>> In other words one cannot prove that every five pound rock weighs
>>>>> more than every three pound rock, one must weigh them one-at-a-time?
>>>>
>>>> Nope. But you need to show that each rock IS a five pound rock.
>>>>
>>>> IF you weigh one rock, and find it is 5 pounds, doesn't mean that
>>>> anothoer rock rock that looks about the same is also 5 pouds,
>>>>
>>>> You do seem to like you Herring in Red sauce, don't you.
>>>>
>>>> The comparison here is that you have only "weighed" a very few of
>>>> your DDs, only those built on an HH that NEVER aborts have been
>>>> determined to not halt. The others are just
>>>> haven't-yet-halted-after-n-steps, but we actually DO know that they
>>>> WILL Halt after more.
>>>>
>>>>>
>>>>>> The ONLY simulation that actually showed that ITS input was
>>>>>> no-halting was the HH that never aborted, and it didn't answer.
>>>>>>
>>>>>> Every other HH has a DIFFERENT INPUT and would be LYING to say it
>>>>>> had that other input.
>>>>>>
>>>>>
>>>>> In other words (because each rock is different) one cannot prove
>>>>> that every five pound rock weighs more than every three pound rock,
>>>>> one must weigh them one-at-a-time?
>>>> Nope, unless of course you still need to weight them to show they
>>>> ARE 5 pound rocks.
>>>>
>>>>>
>>>>> Every HH/DD pair of the infinite of every possible HH/DD pair
>>>>> DD correctly simulated by HH NEVER HALTS.
>>>>
>>>> That isn't even your original claim you were asking about.
>>>>
>>>> Your claim wasn't about "Halting" because that is easily disproven,
>>>> but that there correct PARTIAL simulation done by H never reaches
>>>> the statement after the call.
>>>>
>>>> You are just showing your true colors, that you just don't
>>>> understand what you are talkinag about and get your lies confused.
>>>>
>>>>>
>>>>>>>
>>>>>>> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
>>>>>>> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
>>>>>>> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
>>>>>>
>>>>>> Nope. Aborted simulation don't prove anything.
>>>>>>
>>>>>
>>>>> When for each element of the infinite set of every HH/DD pair DD
>>>>> correctly simulated by HH cannot get past its own simulated line 03
>>>>> then we know that none of the DD inputs to each HH(DD,DD) ever halts.
>>>>
>>>>
>>>> Nope. Try to actually PROVE that.
>>>>
>>>
>>> Semantic tautologies are self-evident truth that prove themselves.
>>> It is a fact that every five pound rock weights more than any
>>> three pound rock. No need to weigh any rocks.
>>
>> Right, so you don't need to weigh a five pound rock to know it is five
>> bpounds.
>>
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int HH(ptr p, ptr i);
>>> 01 int DD(ptr p)
>>> 02 {
>>> 03 int Halt_Status = HH(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11 HH(DD,DD);
>>> 12 return 0;
>>> 13 }
>>>
>>> Likewise we correctly deduce that for every HH/DD pair of the
>>> infinite set of all HH/DD pairs that match the above template
>>> every DD correctly simulated by HH never reaches past its own
>>> simulated line 03, thus never halts.
>>
>
> When for every freaking HH/DD pair that matches the above template
> DD correctly simulated by HH cannot possibly ever reaches past its
> own simulated line 03 then
Similarly:
When for every freaking HH/DD pair that matches the above template
HH correctly simulated by HH cannot possibly ever reaches its own return
then
we know with complete logical certainty that not a damn one of
these HH instance halts. halts, NOT A DAMN ONE OF THEM EVER HALTS.
>
> we know with complete logical certainty that not a damn one of
> these DD instance halts. halts, NOT A DAMN ONE OF THEM EVER HALTS.
>
> NOT A DAMN ONE OF THEM EVER HALTS.
> NOT A DAMN ONE OF THEM EVER HALTS.
> NOT A DAMN ONE OF THEM EVER HALTS.
> NOT A DAMN ONE OF THEM EVER HALTS.
>
> How many morons do you think will believe your damn nonsense?
> How many morons do you think will believe your damn nonsense?
> How many morons do you think will believe your damn nonsense?
>
> We do not have to freaking weigh every damn rock to know that
> every rock weighing more than five pounds weighs more than
> three pounds likewise for all HH/DD pairs.
>
Shouting and swearing does not convince anyone. It sounds as if you
cannot find a real argument any more.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-02 11:19 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3hdfm$39nv5$2@dont-email.me> |
| In reply to | #105980 |
Op 02.jun.2024 om 01:12 schreef olcott:
> On 6/1/2024 6:02 PM, Richard Damon wrote:
>> On 6/1/24 6:40 PM, olcott wrote:
>>>
>>> Show me where I said anything in the above spec about an aborted
>>> simulation.
>>
>> So, why did HH stop simulating after some n steps?
>>
>> Did it reach a final state in the simulation? if not, it ABORTED its
>> simulation.
>>
>>>
>>> When every possible which way DD correctly simulated by HH never reaches
>>> past its own simulated line 03 then
>>
>> And a simulation either goes until it reaches a final state of the
>> machine it is simulating, or it aborted its simulation.
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 HH(DD,DD);
> 12 return 0;
> 13 }
>
> When every DD correctly simulated by any HH cannot possibly reach
> past its own simulated line 03 in 1 to ∞ steps of correct simulation
> of DD by HH then we have exhaustively examined every possible HH/DD
> pair and each element has of this infinite set has the same property.
Similarly:
When every HH correctly simulated by itself cannot possibly reach its
own simulated return in 1 to ∞ steps of correct simulation
of HH by HH then we have exhaustively examined every possible HH/DD
pair and each element has of this infinite set has the same property.
>
> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
>
And since HH is part of that input, it proves that none of these HH halt.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-02 11:13 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3hd40$39nv5$1@dont-email.me> |
| In reply to | #105968 |
Op 01.jun.2024 om 23:24 schreef olcott:
> On 6/1/2024 4:13 PM, Richard Damon wrote:
>> On 6/1/24 4:37 PM, olcott wrote:
>>> On 6/1/2024 3:29 PM, Richard Damon wrote:
>>>> On 6/1/24 3:51 PM, olcott wrote:
>>>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *I will not discuss any other points with you until
>>>>>>>>>>>>>>>>> after you either*
>>>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and
>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>>>>>>>> in C
>>>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>>>> 08
>>>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite
>>>>>>>>>>>>>>> set of HH/DD
>>>>>>>>>>>>>>> pairs that match the above template never reaches past
>>>>>>>>>>>>>>> its own simulated
>>>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In this case HH is either a pure simulator that never
>>>>>>>>>>>>>>> halts or
>>>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>>>> finite number
>>>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>>>> variable.
>>>>>>>>>>>>>>> The pure function HH always returns the meaningless value
>>>>>>>>>>>>>>> of 56
>>>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can pretend that you don't understand something that
>>>>>>>>>>>>> you do indeed
>>>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The key measure of dishonestly would be that you continue
>>>>>>>>>>>>> to say
>>>>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>>>>> what you
>>>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are
>>>>>>>>>>>>>> asking, though it seems that now you are admitting that
>>>>>>>>>>>>>> your HH doesn't actually ANSWER the question, so it isn't
>>>>>>>>>>>>>> ACTUALL a decider for any function except the "56" mapping.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will repeat the question and until you answer the
>>>>>>>>>>>>>> question of what that actually means, I will reply WHO CARES.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what
>>>>>>>>>>>>> I specified*
>>>>>>>>>>>>>
>>>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have
>>>>>>>>>>>>>> no code past point to simulate, and thus your claim is
>>>>>>>>>>>>>> just a LIE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>>>>> instance of DD, at which point we never have the 1 to
>>>>>>>>>>>>>> infinte number of simulatons of THAT INPUT, so your claim
>>>>>>>>>>>>>> is just a LIE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>>>
>>>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Why? I don't care about it.
>>>>>>>>>>
>>>>>>>>>> As I have said, the implication of your definition of "Correct
>>>>>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>>>>>> behavior of DD. (only not halted yet)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>>>
>>>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>>>
>>>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>>>> something that is clearly meaningless.
>>>>>>>>
>>>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>>>> only ever be simulated by ONE given HH that only simuates for
>>>>>>>> one number of steps.
>>>>>>>>
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>> 01 int DD(ptr p)
>>>>>>> 02 {
>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>> 04 if (Halt_Status)
>>>>>>> 05 HERE: goto HERE;
>>>>>>> 06 return Halt_Status;
>>>>>>> 07 }
>>>>>>> 08
>>>>>>> 09 int main()
>>>>>>> 10 {
>>>>>>> 11 HH(DD,DD);
>>>>>>> 12 return 0;
>>>>>>> 13 }
>>>>>>>
>>>>>>> You continue to either fail to understand or seemingly more likely
>>>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>>>> HH that can possibly exist cannot possibly reach past its own
>>>>>>> line 03.
>>>>>>
>>>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>>>> return, otherwise the simulation of DD would go to line 04.
>>>>>>
>>>>>>>
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>>>
>>>>>>
>>>>>> If true: The input to HH is both DD and HH called by DD, so both
>>>>>> DD and HH do not halt, but keep starting new instances of each other.
>>>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>>>> halts is phantasy.
>>>>>
>>>>> I have fully operational code that proves otherwise.
>>>>> Any expert in the C programming language knows the
>>>>> same thing from the C source-code.
>>>>>
>>>>
>>>>
>>>> And have yo tried it to see what your HH says about HH?
>>>>
>>>> After all, just running H isn't good enough by your rules, as you
>>>> reject the fact that DD(DD) Halts just because it does when main
>>>> calls it.
>>>>
>>>
>>> *We have been going over this same point for 2.5 years*
>>>
>>> Pages 4-5 of
>>> *The 2021-09-26 version of my first paper on simulating halt deciders*
>>> *Halting problem undecidability and infinitely nested simulation*
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>> Which is supposed to show WHAT?
>>
>> you have shown main() calling D(D) once to my memory, and that shows
>> that D(D) Halts.
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 HH(DD,DD);
> 12 return 0;
> 13 }
>
> Every DD correctly simulated by any HH of the infinite set of HH/DD
> pairs that match the above template never reaches past its own simulated
> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
Similarly:
Every HH simulated by HH as part of the simulation of DD never reaches
its return in 1 to ∞ steps of correct simulation of HH by HH.
>
> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
> *THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
Similarly:
*THIS PROVES THAT HH, as part of THE INPUT TO H(DD,DD) DOES NOT HALT*
*THIS PROVES THAT HH, as part of THE INPUT TO H(DD,DD) DOES NOT HALT*
*THIS PROVES THAT HH, as part of THE INPUT TO H(DD,DD) DOES NOT HALT*
*THIS PROVES THAT HH, as part of THE INPUT TO H(DD,DD) DOES NOT HALT*
>
> The reason why the behavior of D(D) is irrelevant can
> be discussed ONLY AFTER WE GET CLOSURE ON THE ABOVE POINT.
Similarly:
The reason why the behavior of H(DD,DD) is irrelevant can
be discussed ONLY AFTER WE GET CLOSURE ON THE ABOVE POINT.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-02 11:03 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3hchb$39j2d$2@dont-email.me> |
| In reply to | #105950 |
Op 01.jun.2024 om 21:51 schreef olcott:
> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>> Op 01.jun.2024 om 20:07 schreef olcott:
>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> *I will not discuss any other points with you until after
>>>>>>>>>>>>> you either*
>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩
>>>>>>>>>>>>> ⟨Ĥ⟩ correctly
>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>
>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>
>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>> 02 {
>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>> 07 }
>>>>>>>>>>> 08
>>>>>>>>>>> 09 int main()
>>>>>>>>>>> 10 {
>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>> 12 return 0;
>>>>>>>>>>> 13 }
>>>>>>>>>>>
>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite set of
>>>>>>>>>>> HH/DD
>>>>>>>>>>> pairs that match the above template never reaches past its
>>>>>>>>>>> own simulated
>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>
>>>>>>>>>>> In this case HH is either a pure simulator that never halts or
>>>>>>>>>>> HH is a pure function that stops simulating after some finite
>>>>>>>>>>> number
>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>> variable.
>>>>>>>>>>> The pure function HH always returns the meaningless value of 56
>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>
>>>>>>>>> You can pretend that you don't understand something that you do
>>>>>>>>> indeed
>>>>>>>>> understand into perpetuity.
>>>>>>>>>
>>>>>>>>> The key measure of dishonestly would be that you continue to say
>>>>>>>>> that you don't understand yet never ever point out exactly what
>>>>>>>>> you
>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>
>>>>>>>>>> I giuess that Mean YOU don't even know what you are asking,
>>>>>>>>>> though it seems that now you are admitting that your HH
>>>>>>>>>> doesn't actually ANSWER the question, so it isn't ACTUALL a
>>>>>>>>>> decider for any function except the "56" mapping.
>>>>>>>>>>
>>>>>>>>>> I will repeat the question and until you answer the question
>>>>>>>>>> of what that actually means, I will reply WHO CARES.
>>>>>>>>>>
>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>
>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what I
>>>>>>>>> specified*
>>>>>>>>>
>>>>>>>>>> which means that we CAN'T simulate the call HH as we have no
>>>>>>>>>> code past point to simulate, and thus your claim is just a LIE.
>>>>>>>>>>
>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>> instance of DD, at which point we never have the 1 to infinte
>>>>>>>>>> number of simulatons of THAT INPUT, so your claim is just a LIE.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>
>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>
>>>>>>>>
>>>>>>>> And every one gives a meaningless answer,
>>>>>>>
>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>> number of steps of correct emulation.
>>>>>>>
>>>>>>
>>>>>> Why? I don't care about it.
>>>>>>
>>>>>> As I have said, the implication of your definition of "Correct
>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>> behavior of DD. (only not halted yet)
>>>>>>
>>>>>
>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>> *or infinite* number of steps of correct emulation.
>>>>>
>>>>> When I say it that way you claim to be confused and what I do
>>>>> not say it that way you claim what I say is incomplete proof.
>>>>
>>>> WHy do I care? I won't spend the effort to even try to refute
>>>> something that is clearly meaningless.
>>>>
>>>> You seem to have a conflict of definitions, as a given DD will only
>>>> ever be simulated by ONE given HH that only simuates for one number
>>>> of steps.
>>>>
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>> 00 int HH(ptr p, ptr i);
>>> 01 int DD(ptr p)
>>> 02 {
>>> 03 int Halt_Status = HH(p, p);
>>> 04 if (Halt_Status)
>>> 05 HERE: goto HERE;
>>> 06 return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11 HH(DD,DD);
>>> 12 return 0;
>>> 13 }
>>>
>>> You continue to either fail to understand or seemingly more likely
>>> simply lie about the fact that every DD correctly simulated by any
>>> HH that can possibly exist cannot possibly reach past its own line 03.
>>
>> Only if the simulation of HH simulated by HH does not reach HH's
>> return, otherwise the simulation of DD would go to line 04.
>>
>>>
>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>
>>
>> If true: The input to HH is both DD and HH called by DD, so both DD
>> and HH do not halt, but keep starting new instances of each other.
>> However, HH is required to halt, but it doesn't. So, the HH that halts
>> is phantasy.
>
> I have fully operational code that proves otherwise.
But you are unable to show the ret instruction of HH simulated by
itself. So, the proof is missing the crucial part.
> Any expert in the C programming language knows the
> same thing from the C source-code.
>
You don't need to be an expert in C to see that if the simulated HH
would halt, then DD would continue to line 04.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-02 09:41 -0500 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3i0ai$3cpu7$2@dont-email.me> |
| In reply to | #105992 |
On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
> Op 01.jun.2024 om 21:51 schreef olcott:
>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *I will not discuss any other points with you until after
>>>>>>>>>>>>>> you either*
>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩
>>>>>>>>>>>>>> ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>> 02 {
>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>> 07 }
>>>>>>>>>>>> 08
>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>> 10 {
>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>> 13 }
>>>>>>>>>>>>
>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite set
>>>>>>>>>>>> of HH/DD
>>>>>>>>>>>> pairs that match the above template never reaches past its
>>>>>>>>>>>> own simulated
>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>
>>>>>>>>>>>> In this case HH is either a pure simulator that never halts or
>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>> finite number
>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>> variable.
>>>>>>>>>>>> The pure function HH always returns the meaningless value of 56
>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>
>>>>>>>>>> You can pretend that you don't understand something that you
>>>>>>>>>> do indeed
>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>
>>>>>>>>>> The key measure of dishonestly would be that you continue to say
>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>> what you
>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>
>>>>>>>>>>> I giuess that Mean YOU don't even know what you are asking,
>>>>>>>>>>> though it seems that now you are admitting that your HH
>>>>>>>>>>> doesn't actually ANSWER the question, so it isn't ACTUALL a
>>>>>>>>>>> decider for any function except the "56" mapping.
>>>>>>>>>>>
>>>>>>>>>>> I will repeat the question and until you answer the question
>>>>>>>>>>> of what that actually means, I will reply WHO CARES.
>>>>>>>>>>>
>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>
>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what I
>>>>>>>>>> specified*
>>>>>>>>>>
>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have no
>>>>>>>>>>> code past point to simulate, and thus your claim is just a LIE.
>>>>>>>>>>>
>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>> instance of DD, at which point we never have the 1 to infinte
>>>>>>>>>>> number of simulatons of THAT INPUT, so your claim is just a LIE.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>
>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>
>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>> number of steps of correct emulation.
>>>>>>>>
>>>>>>>
>>>>>>> Why? I don't care about it.
>>>>>>>
>>>>>>> As I have said, the implication of your definition of "Correct
>>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>>> behavior of DD. (only not halted yet)
>>>>>>>
>>>>>>
>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>
>>>>>> When I say it that way you claim to be confused and what I do
>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>
>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>> something that is clearly meaningless.
>>>>>
>>>>> You seem to have a conflict of definitions, as a given DD will only
>>>>> ever be simulated by ONE given HH that only simuates for one number
>>>>> of steps.
>>>>>
>>>>
>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>> 00 int HH(ptr p, ptr i);
>>>> 01 int DD(ptr p)
>>>> 02 {
>>>> 03 int Halt_Status = HH(p, p);
>>>> 04 if (Halt_Status)
>>>> 05 HERE: goto HERE;
>>>> 06 return Halt_Status;
>>>> 07 }
>>>> 08
>>>> 09 int main()
>>>> 10 {
>>>> 11 HH(DD,DD);
>>>> 12 return 0;
>>>> 13 }
>>>>
>>>> You continue to either fail to understand or seemingly more likely
>>>> simply lie about the fact that every DD correctly simulated by any
>>>> HH that can possibly exist cannot possibly reach past its own line 03.
>>>
>>> Only if the simulation of HH simulated by HH does not reach HH's
>>> return, otherwise the simulation of DD would go to line 04.
>>>
>>>>
>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>
>>>
>>> If true: The input to HH is both DD and HH called by DD, so both DD
>>> and HH do not halt, but keep starting new instances of each other.
>>> However, HH is required to halt, but it doesn't. So, the HH that
>>> halts is phantasy.
>>
>> I have fully operational code that proves otherwise.
>
> But you are unable to show the ret instruction of HH simulated by
> itself. So, the proof is missing the crucial part.
>
>
>> Any expert in the C programming language knows the
>> same thing from the C source-code.
>>
>
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 HH(DD,DD);
12 return 0;
13 }
> You don't need to be an expert in C to see that if the simulated HH
> would halt, then DD would continue to line 04.
*Try and show how that can happen*
*You may simply lack the required prerequisite knowledge*
DD correctly emulated by HH with an x86 emulator cannot possibly
reach past its own machine instruction [00001c2e] in any finite
(or infinite) number of steps of correct emulation.
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22
[00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-02 13:22 -0400 |
| Subject | Re: Olcott is simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3i9os$2qu72$2@i2pn2.org> |
| In reply to | #106016 |
On 6/2/24 10:41 AM, olcott wrote:
> On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
>> Op 01.jun.2024 om 21:51 schreef olcott:
>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *I will not discuss any other points with you until after
>>>>>>>>>>>>>>> you either*
>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩
>>>>>>>>>>>>>>> ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>> 08
>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite set
>>>>>>>>>>>>> of HH/DD
>>>>>>>>>>>>> pairs that match the above template never reaches past its
>>>>>>>>>>>>> own simulated
>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In this case HH is either a pure simulator that never halts or
>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>> finite number
>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>> variable.
>>>>>>>>>>>>> The pure function HH always returns the meaningless value
>>>>>>>>>>>>> of 56
>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>
>>>>>>>>>>> You can pretend that you don't understand something that you
>>>>>>>>>>> do indeed
>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>
>>>>>>>>>>> The key measure of dishonestly would be that you continue to say
>>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>>> what you
>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>
>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are asking,
>>>>>>>>>>>> though it seems that now you are admitting that your HH
>>>>>>>>>>>> doesn't actually ANSWER the question, so it isn't ACTUALL a
>>>>>>>>>>>> decider for any function except the "56" mapping.
>>>>>>>>>>>>
>>>>>>>>>>>> I will repeat the question and until you answer the question
>>>>>>>>>>>> of what that actually means, I will reply WHO CARES.
>>>>>>>>>>>>
>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>
>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what I
>>>>>>>>>>> specified*
>>>>>>>>>>>
>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have no
>>>>>>>>>>>> code past point to simulate, and thus your claim is just a LIE.
>>>>>>>>>>>>
>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>>> instance of DD, at which point we never have the 1 to
>>>>>>>>>>>> infinte number of simulatons of THAT INPUT, so your claim is
>>>>>>>>>>>> just a LIE.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>
>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>
>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why? I don't care about it.
>>>>>>>>
>>>>>>>> As I have said, the implication of your definition of "Correct
>>>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>>>> behavior of DD. (only not halted yet)
>>>>>>>>
>>>>>>>
>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>
>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>
>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>> something that is clearly meaningless.
>>>>>>
>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>> only ever be simulated by ONE given HH that only simuates for one
>>>>>> number of steps.
>>>>>>
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>> 00 int HH(ptr p, ptr i);
>>>>> 01 int DD(ptr p)
>>>>> 02 {
>>>>> 03 int Halt_Status = HH(p, p);
>>>>> 04 if (Halt_Status)
>>>>> 05 HERE: goto HERE;
>>>>> 06 return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 int main()
>>>>> 10 {
>>>>> 11 HH(DD,DD);
>>>>> 12 return 0;
>>>>> 13 }
>>>>>
>>>>> You continue to either fail to understand or seemingly more likely
>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>> HH that can possibly exist cannot possibly reach past its own line 03.
>>>>
>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>> return, otherwise the simulation of DD would go to line 04.
>>>>
>>>>>
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>
>>>>
>>>> If true: The input to HH is both DD and HH called by DD, so both DD
>>>> and HH do not halt, but keep starting new instances of each other.
>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>> halts is phantasy.
>>>
>>> I have fully operational code that proves otherwise.
>>
>> But you are unable to show the ret instruction of HH simulated by
>> itself. So, the proof is missing the crucial part.
>>
>>
>>> Any expert in the C programming language knows the
>>> same thing from the C source-code.
>>>
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 HH(DD,DD);
> 12 return 0;
> 13 }
>
>> You don't need to be an expert in C to see that if the simulated HH
>> would halt, then DD would continue to line 04.
>
> *Try and show how that can happen*
> *You may simply lack the required prerequisite knowledge*
its been done many times.
In fact you even posted a trace of this happening, when you (perhaps
mistakenly) posted a trace which had main calling P(P).
>
> DD correctly emulated by HH with an x86 emulator cannot possibly
> reach past its own machine instruction [00001c2e] in any finite
> (or infinite) number of steps of correct emulation.
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
>
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-02 20:13 +0200 |
| Subject | Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down |
| Message-ID | <v3icns$3f51j$2@dont-email.me> |
| In reply to | #106016 |
Op 02.jun.2024 om 16:41 schreef olcott:
> On 6/2/2024 4:03 AM, Fred. Zwarts wrote:
>> Op 01.jun.2024 om 21:51 schreef olcott:
>>> On 6/1/2024 1:54 PM, Fred. Zwarts wrote:
>>>> Op 01.jun.2024 om 20:07 schreef olcott:
>>>>> On 6/1/2024 12:56 PM, Richard Damon wrote:
>>>>>> On 6/1/24 1:44 PM, olcott wrote:
>>>>>>> On 6/1/2024 12:33 PM, Richard Damon wrote:
>>>>>>>> On 6/1/24 1:27 PM, olcott wrote:
>>>>>>>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>>>>>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>>>>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>>>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *I will not discuss any other points with you until after
>>>>>>>>>>>>>>> you either*
>>>>>>>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩
>>>>>>>>>>>>>>> ⟨Ĥ⟩ correctly
>>>>>>>>>>>>>>> simulated by embedded_H remain stuck in recursive
>>>>>>>>>>>>>>> simulation for
>>>>>>>>>>>>>>> 1 to ∞ of correct simulation or
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And until you answer the question of what that actually
>>>>>>>>>>>>>> means, I will reply WHO CARES.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>>> 00 int HH(ptr p, ptr i);
>>>>>>>>>>>>> 01 int DD(ptr p)
>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>> 03 int Halt_Status = HH(p, p);
>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>> 08
>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>> 11 HH(DD,DD);
>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every DD correctly simulated by any HH of the infinite set
>>>>>>>>>>>>> of HH/DD
>>>>>>>>>>>>> pairs that match the above template never reaches past its
>>>>>>>>>>>>> own simulated
>>>>>>>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In this case HH is either a pure simulator that never halts or
>>>>>>>>>>>>> HH is a pure function that stops simulating after some
>>>>>>>>>>>>> finite number
>>>>>>>>>>>>> of simulated lines. The line count is stored in a local
>>>>>>>>>>>>> variable.
>>>>>>>>>>>>> The pure function HH always returns the meaningless value
>>>>>>>>>>>>> of 56
>>>>>>>>>>>>> after it stops simulating.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, still no answer, to teh question.
>>>>>>>>>>>
>>>>>>>>>>> You can pretend that you don't understand something that you
>>>>>>>>>>> do indeed
>>>>>>>>>>> understand into perpetuity.
>>>>>>>>>>>
>>>>>>>>>>> The key measure of dishonestly would be that you continue to say
>>>>>>>>>>> that you don't understand yet never ever point out exactly
>>>>>>>>>>> what you
>>>>>>>>>>> don't understand and why you don't understand it.
>>>>>>>>>>>
>>>>>>>>>>>> I giuess that Mean YOU don't even know what you are asking,
>>>>>>>>>>>> though it seems that now you are admitting that your HH
>>>>>>>>>>>> doesn't actually ANSWER the question, so it isn't ACTUALL a
>>>>>>>>>>>> decider for any function except the "56" mapping.
>>>>>>>>>>>>
>>>>>>>>>>>> I will repeat the question and until you answer the question
>>>>>>>>>>>> of what that actually means, I will reply WHO CARES.
>>>>>>>>>>>>
>>>>>>>>>>>> DO you mean the simulation of the TEMPLATE DD,
>>>>>>>>>>>
>>>>>>>>>>> *Of course I don't mean that nonsense. I mean exactly what I
>>>>>>>>>>> specified*
>>>>>>>>>>>
>>>>>>>>>>>> which means that we CAN'T simulate the call HH as we have no
>>>>>>>>>>>> code past point to simulate, and thus your claim is just a LIE.
>>>>>>>>>>>>
>>>>>>>>>>>> Or, do you mean a given instance of HH simulating a given
>>>>>>>>>>>> instance of DD, at which point we never have the 1 to
>>>>>>>>>>>> infinte number of simulatons of THAT INPUT, so your claim is
>>>>>>>>>>>> just a LIE.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>> Every element of the infinite set of every H/D pairs...
>>>>>>>>>>>
>>>>>>>>>>> *Its not that hard when one refrains from dishonesty*
>>>>>>>>>>> We can't even say that you forgot these details from one reply
>>>>>>>>>>> to the next because the details are still in this same post.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And every one gives a meaningless answer,
>>>>>>>>>
>>>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>>>> number of steps of correct emulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why? I don't care about it.
>>>>>>>>
>>>>>>>> As I have said, the implication of your definition of "Correct
>>>>>>>> SImulation" means that this says NOTHING about the halting
>>>>>>>> behavior of DD. (only not halted yet)
>>>>>>>>
>>>>>>>
>>>>>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>>>>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>>>>>> reach past its own machine instruction [00001c2e] in any finite
>>>>>>> *or infinite* number of steps of correct emulation.
>>>>>>>
>>>>>>> When I say it that way you claim to be confused and what I do
>>>>>>> not say it that way you claim what I say is incomplete proof.
>>>>>>
>>>>>> WHy do I care? I won't spend the effort to even try to refute
>>>>>> something that is clearly meaningless.
>>>>>>
>>>>>> You seem to have a conflict of definitions, as a given DD will
>>>>>> only ever be simulated by ONE given HH that only simuates for one
>>>>>> number of steps.
>>>>>>
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>> 00 int HH(ptr p, ptr i);
>>>>> 01 int DD(ptr p)
>>>>> 02 {
>>>>> 03 int Halt_Status = HH(p, p);
>>>>> 04 if (Halt_Status)
>>>>> 05 HERE: goto HERE;
>>>>> 06 return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 int main()
>>>>> 10 {
>>>>> 11 HH(DD,DD);
>>>>> 12 return 0;
>>>>> 13 }
>>>>>
>>>>> You continue to either fail to understand or seemingly more likely
>>>>> simply lie about the fact that every DD correctly simulated by any
>>>>> HH that can possibly exist cannot possibly reach past its own line 03.
>>>>
>>>> Only if the simulation of HH simulated by HH does not reach HH's
>>>> return, otherwise the simulation of DD would go to line 04.
>>>>
>>>>>
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>> *THIS MEANS THAT THE INPUT TO HH(DD,DD) DOES NOT HALT*
>>>>>
>>>>
>>>> If true: The input to HH is both DD and HH called by DD, so both DD
>>>> and HH do not halt, but keep starting new instances of each other.
>>>> However, HH is required to halt, but it doesn't. So, the HH that
>>>> halts is phantasy.
>>>
>>> I have fully operational code that proves otherwise.
>>
>> But you are unable to show the ret instruction of HH simulated by
>> itself. So, the proof is missing the crucial part.
>>
>>
>>> Any expert in the C programming language knows the
>>> same thing from the C source-code.
>>>
>>
>
> typedef int (*ptr)(); // ptr is pointer to int function in C
> 00 int HH(ptr p, ptr i);
> 01 int DD(ptr p)
> 02 {
> 03 int Halt_Status = HH(p, p);
> 04 if (Halt_Status)
> 05 HERE: goto HERE;
> 06 return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11 HH(DD,DD);
> 12 return 0;
> 13 }
>
>> You don't need to be an expert in C to see that if the simulated HH
>> would halt, then DD would continue to line 04.
>
> *Try and show how that can happen*
If you show how HH simulated by HH reaches its return and show the next
10 instructions. You can't and therefore we know the simulated HH does
not halt and the non-halting HH is the reason that DD does not continue.
> *You may simply lack the required prerequisite knowledge >
> DD correctly emulated by HH with an x86 emulator cannot possibly
> reach past its own machine instruction [00001c2e] in any finite
> (or infinite) number of steps of correct emulation.
>
> _DD()
> [00001c22] 55 push ebp
> [00001c23] 8bec mov ebp,esp
> [00001c25] 51 push ecx
> [00001c26] 8b4508 mov eax,[ebp+08]
> [00001c29] 50 push eax ; push DD 1c22
> [00001c2a] 8b4d08 mov ecx,[ebp+08]
> [00001c2d] 51 push ecx ; push DD 1c22
> [00001c2e] e80ff7ffff call 00001342 ; call HH
> [00001c33] 83c408 add esp,+08
> [00001c36] 8945fc mov [ebp-04],eax
> [00001c39] 837dfc00 cmp dword [ebp-04],+00
> [00001c3d] 7402 jz 00001c41
> [00001c3f] ebfe jmp 00001c3f
> [00001c41] 8b45fc mov eax,[ebp-04]
> [00001c44] 8be5 mov esp,ebp
> [00001c46] 5d pop ebp
> [00001c47] c3 ret
> Size in bytes:(0038) [00001c47]
It could if HH were a halting function as required. Then the call at
[00001c2e] would return and the next instruction would be reachable. The
reason that it is not, is that HH does not return.
(You don't need to show your x86 code. Is does not show more than the C
code.)
[toc] | [prev] | [next] | [standalone]
Page 9 of 19 — ← Prev page 1 … 7 8 [9] 10 11 … 19 Next page →
Back to top | Article view | comp.theory
csiph-web