Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #107463 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-06-19 19:00 -0500 |
| Last post | 2024-06-30 12:30 +0300 |
| Articles | 20 on this page of 197 — 8 participants |
Back to article view | Back to comp.theory
195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-19 19:00 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-20 10:09 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-20 09:12 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Richard Damon <richard@damon-family.org> - 2024-06-20 18:37 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-20 17:45 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Richard Damon <richard@damon-family.org> - 2024-06-20 21:55 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-21 09:44 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 08:01 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 10:02 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 09:44 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 11:25 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 12:04 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 13:09 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 12:22 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 13:40 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 12:55 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 14:00 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 13:22 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 14:39 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 13:51 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 15:11 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-21 14:23 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-21 15:54 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply joes <noreply@example.com> - 2024-06-25 20:31 +0000
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-25 16:22 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-25 21:47 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply joes <noreply@example.com> - 2024-06-26 08:11 +0000
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-26 08:32 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-22 11:27 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-22 08:11 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-22 09:38 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply joes <noreply@example.com> - 2024-06-22 14:41 +0000
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-22 10:53 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-22 20:50 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-22 13:53 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-22 15:22 -0400
DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-22 14:45 -0500
Re: DDD correctly emulated by H0 Richard Damon <richard@damon-family.org> - 2024-06-22 16:10 -0400
Re: DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-22 19:01 -0500
Re: DDD correctly emulated by H0 Richard Damon <richard@damon-family.org> - 2024-06-22 20:14 -0400
Re: DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-22 22:28 -0500
Re: DDD correctly emulated by H0 Richard Damon <richard@damon-family.org> - 2024-06-23 07:28 -0400
Re: DDD correctly emulated by H0 olcott <polcott333@gmail.com> - 2024-06-23 08:38 -0500
Re: DDD correctly emulated by H0 Richard Damon <richard@damon-family.org> - 2024-06-23 14:23 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-23 11:45 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-23 08:30 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-24 11:43 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply olcott <polcott333@gmail.com> - 2024-06-24 13:16 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply Richard Damon <richard@damon-family.org> - 2024-06-24 19:23 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 Mikko <mikko.levanto@iki.fi> - 2024-06-23 11:22 +0300
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-23 08:17 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Mikko <mikko.levanto@iki.fi> - 2024-06-24 10:37 +0300
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-24 08:48 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 joes <noreply@example.com> - 2024-06-24 19:36 +0000
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-24 16:04 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Richard Damon <richard@damon-family.org> - 2024-06-24 19:43 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-25 14:08 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-25 08:12 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-25 16:13 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-25 12:29 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-25 20:19 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-25 13:26 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-25 20:49 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-25 13:51 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-25 21:17 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-25 14:30 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-26 10:01 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-26 08:07 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-27 11:38 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-27 12:21 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 10:06 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 09:12 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 16:43 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 10:01 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 17:19 +0200
Re: 197 page execution trace of DDD incorrectly simulated by HHH joes <noreply@example.com> - 2024-06-28 16:28 +0000
Re: 197 page execution trace of DDD incorrectly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 13:24 -0500
Re: 197 page execution trace of DDD incorrectly simulated by HHH joes <noreply@example.com> - 2024-06-28 19:25 +0000
Re: 197 page execution trace of DDD incorrectly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 16:03 -0500
Re: 197 page execution trace of DDD incorrectly simulated by HHH Alan Mackenzie <acm@muc.de> - 2024-06-28 21:26 +0000
Re: 197 page execution trace of DDD incorrectly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 16:52 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-26 08:30 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-27 11:45 +0200
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-27 12:30 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 10:23 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 09:27 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 16:53 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 10:04 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 17:22 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 10:32 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 17:48 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 11:54 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 20:22 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 13:31 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-28 20:48 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 14:01 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-29 10:52 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-29 21:51 -0500
Re: simulation trace of DDD joes <noreply@example.org> - 2024-06-30 08:58 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-06-30 08:34 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 joes <noreply@example.com> - 2024-06-28 13:14 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 10:25 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.com> - 2024-06-28 16:26 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 12:05 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.com> - 2024-06-28 17:41 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 12:53 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.com> - 2024-06-28 19:18 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 14:28 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.org> - 2024-06-29 19:44 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-29 15:03 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-06-29 16:11 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.org> - 2024-06-30 08:42 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-30 12:25 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-06-30 15:31 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.org> - 2024-06-30 20:16 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 10:27 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 07:57 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 16:27 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 09:35 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.org> - 2024-07-01 15:52 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 10:56 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 20:14 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 13:29 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-02 10:45 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 20:01 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 13:25 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-02 10:39 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.org> - 2024-07-01 15:48 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-01 20:38 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 20:39 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-01 22:03 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-30 12:42 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-30 12:20 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 10:23 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 07:59 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-07-01 16:25 +0200
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 09:31 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-01 20:38 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-01 20:38 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 20:36 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-01 22:24 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 21:34 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-01 22:44 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 22:14 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-01 23:21 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-01 22:34 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-02 07:30 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-02 07:39 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-02 18:44 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-02 17:58 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-02 19:03 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-02 18:09 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-02 21:07 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-02 20:28 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-02 21:32 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-07-02 20:42 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-07-02 21:48 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH --- clueless olcott <polcott333@gmail.com> - 2024-07-02 20:54 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH --- clueless Richard Damon <richard@damon-family.org> - 2024-07-02 21:59 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH --- Richard proves that he is clueless olcott <polcott333@gmail.com> - 2024-07-02 21:09 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH --- Richard proves that he is clueless Richard Damon <richard@damon-family.org> - 2024-07-02 22:23 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH --- Richard proves that he is clueless olcott <polcott333@gmail.com> - 2024-07-02 21:35 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH --- Richard proves that he is clueless Richard Damon <richard@damon-family.org> - 2024-07-02 22:46 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH --- Richard proves that he is clueless olcott <polcott333@gmail.com> - 2024-07-02 22:10 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH --- Richard proves that he is clueless Richard Damon <richard@damon-family.org> - 2024-07-02 23:26 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH --- Richard proves that he is clueless Richard Damon <richard@damon-family.org> - 2024-07-02 23:27 -0400
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.org> - 2024-07-03 03:55 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH Mikko <mikko.levanto@iki.fi> - 2024-07-02 09:42 +0300
Re: 197 page execution trace of DDD correctly simulated by HHH joes <noreply@example.org> - 2024-07-02 08:06 +0000
Re: 197 page execution trace of DDD correctly simulated by HHH Mikko <mikko.levanto@iki.fi> - 2024-07-02 09:40 +0300
Re: 195 page execution trace of DDD correctly simulated by HH0 Mikko <mikko.levanto@iki.fi> - 2024-06-26 11:10 +0300
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-26 07:55 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Alan Mackenzie <acm@muc.de> - 2024-06-26 13:40 +0000
DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure olcott <polcott333@gmail.com> - 2024-06-26 09:04 -0500
Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure Alan Mackenzie <acm@muc.de> - 2024-06-26 16:03 +0000
Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure olcott <polcott333@gmail.com> - 2024-06-26 11:24 -0500
Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure Python <python@invalid.org> - 2024-06-26 18:30 +0200
Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure Alan Mackenzie <acm@muc.de> - 2024-06-26 19:43 +0000
Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure olcott <polcott333@gmail.com> - 2024-06-26 15:10 -0500
Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure --- addendum olcott <polcott333@gmail.com> - 2024-06-26 15:30 -0500
Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure joes <noreply@example.com> - 2024-06-26 20:55 +0000
Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure olcott <polcott333@gmail.com> - 2024-06-26 16:15 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Mikko <mikko.levanto@iki.fi> - 2024-06-27 09:34 +0300
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-27 12:07 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Mikko <mikko.levanto@iki.fi> - 2024-06-28 10:17 +0300
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-28 10:28 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Mikko <mikko.levanto@iki.fi> - 2024-06-29 10:23 +0300
Re: 197 page execution trace of DDD correctly simulated by HHH olcott <polcott333@gmail.com> - 2024-06-29 21:50 -0500
Re: 197 page execution trace of DDD correctly simulated by HHH Mikko <mikko.levanto@iki.fi> - 2024-06-30 12:12 +0300
Re: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-06-30 08:34 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 Richard Damon <richard@damon-family.org> - 2024-06-25 21:47 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-25 21:12 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Richard Damon <richard@damon-family.org> - 2024-06-25 22:20 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 joes <noreply@example.com> - 2024-06-25 20:44 +0000
Re: 195 page execution trace of DDD correctly simulated by HH0 olcott <polcott333@gmail.com> - 2024-06-25 16:38 -0500
Re: 195 page execution trace of DDD correctly simulated by HH0 Richard Damon <richard@damon-family.org> - 2024-06-24 19:24 -0400
Re: 195 page execution trace of DDD correctly simulated by HH0 Mikko <mikko.levanto@iki.fi> - 2024-06-30 12:30 +0300
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-22 22:28 -0500 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <v584ou$5ski$1@dont-email.me> |
| In reply to | #107657 |
On 6/22/2024 7:14 PM, Richard Damon wrote: > On 6/22/24 8:01 PM, olcott wrote: >> >> When we stipulate that the only measure of a correct emulation >> is the semantics of the x86 programming language then we see >> that when DDD is correctly emulated by H0 that its call to >> H0(DDD) cannot possibly return. > > Right, so what do you do when you run out of instructions to simulate? > > Your logic just BLOWS UP. > That you are too stupid to see an infinite recursion behavior pattern does not mean that I am not correct. >> >> _DDD() >> [00002172] 55 push ebp ; housekeeping >> [00002173] 8bec mov ebp,esp ; housekeeping >> [00002175] 6872210000 push 00002172 ; push DDD >> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >> [0000217f] 83c404 add esp,+04 >> [00002182] 5d pop ebp >> [00002183] c3 ret >> Size in bytes:(0018) [00002183] >> >> > > This exposes the LIE of your system. YOu CAN'T correctly x86 emulate a > partial program, becuase it isn't prpgram with behavior to emulate. > > PERIOD. > > That means, the call to H0(DDD), to have any actual meaning, must > incluede *ALL* the instrutions in memory that are going to be used as > part of the input, and thus, DDD is TIED to the H0 that we started with, > so your "trick" of changing it is shows to just be a LIE. > > > You just don't understand that behavior is determined of an SPECIFIC > program, a specific instance of the template AFTER pairing it with the > decider it is to foil, and when you ask about other deciders looking at > THIS input, the input can't change. > > There goes your two decades down the drain. -- 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-23 07:28 -0400 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <v590sp$rmf0$3@i2pn2.org> |
| In reply to | #107660 |
On 6/22/24 11:28 PM, olcott wrote: > On 6/22/2024 7:14 PM, Richard Damon wrote: >> On 6/22/24 8:01 PM, olcott wrote: >>> >>> When we stipulate that the only measure of a correct emulation >>> is the semantics of the x86 programming language then we see >>> that when DDD is correctly emulated by H0 that its call to >>> H0(DDD) cannot possibly return. >> >> Right, so what do you do when you run out of instructions to simulate? >> >> Your logic just BLOWS UP. >> > > That you are too stupid to see an infinite recursion behavior > pattern does not mean that I am not correct. Except it is proven to not be the infinite recursion behavior if H0 is a decider. Just a finite recursion pattern. So, which LIE are you holding to: That this is an infinite recursion pattern, when every level of H0 will break the pattern as it is a decider and not let itself go on forever That H0 is a decider, because it isn't "smart" enough to see it is caught in an infinte loop an get out of it, so it just fails to answer at ANY level That H0 is a "Pure Function" and thus *ALL* calls to it with the same parameters will act the same. So, which *LIE* is it? (Confirmed liar Peter Olcott) > >>> >>> _DDD() >>> [00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping >>> [00002175] 6872210000 push 00002172 ; push DDD >>> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >>> [0000217f] 83c404 add esp,+04 >>> [00002182] 5d pop ebp >>> [00002183] c3 ret >>> Size in bytes:(0018) [00002183] >>> >>> >> >> This exposes the LIE of your system. YOu CAN'T correctly x86 emulate a >> partial program, becuase it isn't prpgram with behavior to emulate. >> >> PERIOD. >> >> That means, the call to H0(DDD), to have any actual meaning, must >> incluede *ALL* the instrutions in memory that are going to be used as >> part of the input, and thus, DDD is TIED to the H0 that we started >> with, so your "trick" of changing it is shows to just be a LIE. >> >> >> You just don't understand that behavior is determined of an SPECIFIC >> program, a specific instance of the template AFTER pairing it with the >> decider it is to foil, and when you ask about other deciders looking >> at THIS input, the input can't change. >> >> There goes your two decades down the drain. >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-23 08:38 -0500 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <v598g0$brmn$7@dont-email.me> |
| In reply to | #107670 |
On 6/23/2024 6:28 AM, Richard Damon wrote: > On 6/22/24 11:28 PM, olcott wrote: >> On 6/22/2024 7:14 PM, Richard Damon wrote: >>> On 6/22/24 8:01 PM, olcott wrote: >>>> >>>> When we stipulate that the only measure of a correct emulation >>>> is the semantics of the x86 programming language then we see >>>> that when DDD is correctly emulated by H0 that its call to >>>> H0(DDD) cannot possibly return. >>> >>> Right, so what do you do when you run out of instructions to simulate? >>> >>> Your logic just BLOWS UP. >>> >> >> That you are too stupid to see an infinite recursion behavior >> pattern does not mean that I am not correct. > > Except it is proven to not be the infinite recursion behavior if H0 is a > decider. > > Just a finite recursion pattern. > > So, which LIE are you holding to: > > That this is an infinite recursion pattern, when every level of H0 will > break the pattern as it is a decider and not let itself go on forever > > That H0 is a decider, because it isn't "smart" enough to see it is > caught in an infinte loop an get out of it, so it just fails to answer > at ANY level > > That H0 is a "Pure Function" and thus *ALL* calls to it with the same > parameters will act the same. > > > So, which *LIE* is it? > > > (Confirmed liar Peter Olcott) > >> >>>> >>>> _DDD() >>>> [00002172] 55 push ebp ; housekeeping >>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>> [00002175] 6872210000 push 00002172 ; push DDD >>>> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >>>> [0000217f] 83c404 add esp,+04 >>>> [00002182] 5d pop ebp >>>> [00002183] c3 ret >>>> Size in bytes:(0018) [00002183] >>>> >>>> >>> >>> This exposes the LIE of your system. YOu CAN'T correctly x86 emulate >>> a partial program, becuase it isn't prpgram with behavior to emulate. >>> >>> PERIOD. >>> >>> That means, the call to H0(DDD), to have any actual meaning, must >>> incluede *ALL* the instrutions in memory that are going to be used as >>> part of the input, and thus, DDD is TIED to the H0 that we started >>> with, so your "trick" of changing it is shows to just be a LIE. >>> >>> >>> You just don't understand that behavior is determined of an SPECIFIC >>> program, a specific instance of the template AFTER pairing it with >>> the decider it is to foil, and when you ask about other deciders >>> looking at THIS input, the input can't change. >>> >>> There goes your two decades down the drain. >> > _DDD() [00002172] 55 push ebp [00002173] 8bec mov ebp,esp [00002175] 6872210000 push 00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call HHH0 [0000217f] 83c404 add esp,+04 [00002182] 5d pop ebp [00002183] c3 ret Size in bytes:(0018) [00002183] According to the semantics of the x86 programming language when DDD correctly emulated by H0 calls H0(DDD) this call cannot possibly return. Likewise according to the semantics of arithmetic for decimal integers: 2 + 3 = 5. Anyone disagreeing with these two statements is WRONG. -- 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-23 14:23 -0400 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <v59p71$smd5$4@i2pn2.org> |
| In reply to | #107678 |
On 6/23/24 9:38 AM, olcott wrote: > On 6/23/2024 6:28 AM, Richard Damon wrote: >> On 6/22/24 11:28 PM, olcott wrote: >>> On 6/22/2024 7:14 PM, Richard Damon wrote: >>>> On 6/22/24 8:01 PM, olcott wrote: >>>>> >>>>> When we stipulate that the only measure of a correct emulation >>>>> is the semantics of the x86 programming language then we see >>>>> that when DDD is correctly emulated by H0 that its call to >>>>> H0(DDD) cannot possibly return. >>>> >>>> Right, so what do you do when you run out of instructions to simulate? >>>> >>>> Your logic just BLOWS UP. >>>> >>> >>> That you are too stupid to see an infinite recursion behavior >>> pattern does not mean that I am not correct. >> >> Except it is proven to not be the infinite recursion behavior if H0 is >> a decider. >> >> Just a finite recursion pattern. >> >> So, which LIE are you holding to: >> >> That this is an infinite recursion pattern, when every level of H0 >> will break the pattern as it is a decider and not let itself go on >> forever >> >> That H0 is a decider, because it isn't "smart" enough to see it is >> caught in an infinte loop an get out of it, so it just fails to answer >> at ANY level >> >> That H0 is a "Pure Function" and thus *ALL* calls to it with the same >> parameters will act the same. >> >> >> So, which *LIE* is it? >> >> >> (Confirmed liar Peter Olcott) >> >>> >>>>> >>>>> _DDD() >>>>> [00002172] 55 push ebp ; housekeeping >>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >>>>> [0000217f] 83c404 add esp,+04 >>>>> [00002182] 5d pop ebp >>>>> [00002183] c3 ret >>>>> Size in bytes:(0018) [00002183] >>>>> >>>>> >>>> >>>> This exposes the LIE of your system. YOu CAN'T correctly x86 emulate >>>> a partial program, becuase it isn't prpgram with behavior to emulate. >>>> >>>> PERIOD. >>>> >>>> That means, the call to H0(DDD), to have any actual meaning, must >>>> incluede *ALL* the instrutions in memory that are going to be used >>>> as part of the input, and thus, DDD is TIED to the H0 that we >>>> started with, so your "trick" of changing it is shows to just be a LIE. >>>> >>>> >>>> You just don't understand that behavior is determined of an SPECIFIC >>>> program, a specific instance of the template AFTER pairing it with >>>> the decider it is to foil, and when you ask about other deciders >>>> looking at THIS input, the input can't change. >>>> >>>> There goes your two decades down the drain. >>> >> > > _DDD() > [00002172] 55 push ebp > [00002173] 8bec mov ebp,esp > [00002175] 6872210000 push 00002172 ; push DDD > [0000217a] e853f4ffff call 000015d2 ; call HHH0 > [0000217f] 83c404 add esp,+04 > [00002182] 5d pop ebp > [00002183] c3 ret > Size in bytes:(0018) [00002183] > > According to the semantics of the x86 programming language > when DDD correctly emulated by H0 calls H0(DDD) this call > cannot possibly return. > > Likewise according to the semantics of arithmetic for > decimal integers: 2 + 3 = 5. > > Anyone disagreeing with these two statements is WRONG. > Now, if you REALLY mean just can HHH0 simulate this input to a final state, the answer is WHO CARES. But I will put out a few comments on errors in your presentation\. First, if you ONLY have the bytes presented, then the answer becomes trivial, as H0 HAS to stop emulating when it gets to the call instruction, as there is no data at address 000015d2 defined to simulate. This means you need to fix your problem statement to include the instructions of HHH0, and everything that it calls as part of the "input", or your question isn't the one you mean to be asking. Of course, this means that each HHH0 that you try, is processing a DIFFERENT input, so you can't argue from one about the behavior of a different one. Second, you forgot to specify what HHH0 has as requirements. Once you include its code, so can simulate it, the "non-pure" function tricks allow it to correctly simulate to the return instruction. Reminder, you complain when we point out assumptions made on previous statements that you didn't want to carry forward, so you can't also complain about us forgetting about requirements that you didn't bring forward. If you want to pull in the past, we can just point out that we KNOW you are talking about a Halt Decider, and that your question is the wrong question for a Halt decider. So, your statement is wrong for two logical reasons as described above, so your statement that anyone who disagrees is wrong is just wrong. You don't know how to properly state a problem. The last point to make, is that this is NOT a "proof" but just an argument claiming something should be obviously true. That may be a "proof" in the wild west of Philosophy, but it isn't in the realm of Formal Logic, which is what the field you are talking about is. So, you are making a statement, that when fixed to correct the deficits in it, becomes a statement that might be plausably true, but not proven. A proof can likely be made, but it seems that is beyond your ability since you didn't even try, Of course, without the second fix, the statement is just false, and without the first fix, the statment is meaningless, as of course you can't simulate to a return from a call that you are unable to simulate past.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-23 11:45 +0200 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v58qsk$9a7f$1@dont-email.me> |
| In reply to | #107637 |
Op 22.jun.2024 om 20:53 schreef olcott: > On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >> Op 22.jun.2024 om 15:11 schreef olcott: >>> On 6/22/2024 4:27 AM, Fred. Zwarts wrote: >>>> Op 21.jun.2024 om 15:01 schreef olcott: >>>>> On 6/21/2024 2:44 AM, Fred. Zwarts wrote: >>>>>> Op 20.jun.2024 om 16:12 schreef olcott: >>>>>>> On 6/20/2024 3:09 AM, Fred. Zwarts wrote: >>>>>>>> Op 20.jun.2024 om 02:00 schreef olcott: >>>>>>>>> This shows all of the steps of HH0 simulating DDD >>>>>>>>> calling a simulated HH0 simulating DDD >>>>>>>>> >>>>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf >>>>>>>>> *Some of the key instructions are color coded* >>>>>>>>> GREEN---DebugStep Address >>>>>>>>> RED-----HH Address >>>>>>>>> YELLOW--All of the DDD instructions >>>>>>>>> CYAN----Return from DebugStep to Decide_Halting_HH >>>>>>>>> >>>>>>>>> _DDD() >>>>>>>>> [000020a2] 55 push ebp ; housekeeping >>>>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping >>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD >>>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0 >>>>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping >>>>>>>>> [000020b2] 5d pop ebp ; housekeeping >>>>>>>>> [000020b3] c3 ret ; never gets here >>>>>>>>> Size in bytes:(0018) [000020b3] >>>>>>>>> >>>>>>>>> Exactly which step of DDD emulated by H0 was emulated >>>>>>>>> incorrectly such that this emulation would be complete? >>>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> If the simulation of a program with a loop of 5 iterations is >>>>>>>> aborted after 3 iterations, all instructions are correctly >>>>>>>> simulated. Nevertheless, it is an incorrect simulation, because >>>>>>>> it should simulate up to the final state of the program. >>>>>>>> >>>>>>> >>>>>>> It would be helpful if you answer the actual question being asked >>>>>>> right here and thus not answer some other question that was asked >>>>>>> somewhere else. >>>>>> >>>>>> If you do not understand that I answered the question why the >>>>>> simulation is incorrect, it is hopeless. The question which >>>>>> instruction is incorrect is not the right question. >>>>>> >>>>> >>>>> If you say that something is incorrect and can't be specific >>>>> then your rebuttal is pure bluster with no actual basis. >>>>> >>>> >>>> If ..., but that condition is not present, so the 'then' does not >>>> apply. >>>> This makes the sentence completely superfluous. I would expect >>>> better from someone who claims to be an experienced programmer. >>>> >>>> But since I pointed out in a very detailed way, why it is incorrect, >>>> your reply shows that you do not understand where you are talking >>>> about, which then becomes utterly nonsense. >>>> >>>> The question which instruction is incorrectly simulated already >>>> shows your error. The error is not that an instruction is simulated >>>> incorrectly, but that some instruction are not simulated at all. >>>> Why is that already over your head? >>>> >>> >>> It is a verified fact that the behavior that finite string DDD presents >>> to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that >>> this call DOES NOT RETURN. >>> >>> It is a verified fact that the behavior that finite string DDD presents >>> to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) that >>> this call DOES RETURN. >>> >>> I don't get why people here insist on lying about verified facts. >>> >> >> We know that 'verified fact' for you means 'my wish'. > > Ignoramus? > > When we stipulate that the only measure of a correct emulation is the > semantics of the x86 programming language then we see that when DDD is > correctly emulated by H0 that its call to H0(DDD) cannot possibly return. > > _DDD() > [00002172] 55 push ebp ; housekeeping > [00002173] 8bec mov ebp,esp ; housekeeping > [00002175] 6872210000 push 00002172 ; push DDD > [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) > [0000217f] 83c404 add esp,+04 > [00002182] 5d pop ebp > [00002183] c3 ret > Size in bytes:(0018) [00002183] > > When we define H1 as identical to H0 except that DDD does not call H1 > then we see that when DDD is correctly emulated by H1 that its call to > H0(DDD) does return. This is the same behavior as the directly executed > DDD(). > Exactly what I predicted. Olcott can not point to any error in what I said and just repeats his baseless claim. In addition he removes this prediction from his citation, as well as the proof why his reasoning is wrong. He probably not even wants to know the errors in his reasoning, because he would be too disappointed to learn that he spilled so many years on a basically wrong idea. Olcott, it may give you rest and peace to accept that there is no way to prove your opinion. I have had a similar experience. I thought I had some very clever ideas, but when I finally had the time to work them out, after my retirement, it turned out that some of them were known already and others were simply wrong. A disappointment, but when I accepted it, it gave me rest and time to do more useful things.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-23 08:30 -0500 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5981p$brmn$4@dont-email.me> |
| In reply to | #107666 |
On 6/23/2024 4:45 AM, Fred. Zwarts wrote: > Op 22.jun.2024 om 20:53 schreef olcott: >> On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >>> Op 22.jun.2024 om 15:11 schreef olcott: >>>> On 6/22/2024 4:27 AM, Fred. Zwarts wrote: >>>>> Op 21.jun.2024 om 15:01 schreef olcott: >>>>>> On 6/21/2024 2:44 AM, Fred. Zwarts wrote: >>>>>>> Op 20.jun.2024 om 16:12 schreef olcott: >>>>>>>> On 6/20/2024 3:09 AM, Fred. Zwarts wrote: >>>>>>>>> Op 20.jun.2024 om 02:00 schreef olcott: >>>>>>>>>> This shows all of the steps of HH0 simulating DDD >>>>>>>>>> calling a simulated HH0 simulating DDD >>>>>>>>>> >>>>>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf >>>>>>>>>> *Some of the key instructions are color coded* >>>>>>>>>> GREEN---DebugStep Address >>>>>>>>>> RED-----HH Address >>>>>>>>>> YELLOW--All of the DDD instructions >>>>>>>>>> CYAN----Return from DebugStep to Decide_Halting_HH >>>>>>>>>> >>>>>>>>>> _DDD() >>>>>>>>>> [000020a2] 55 push ebp ; housekeeping >>>>>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping >>>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD >>>>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0 >>>>>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping >>>>>>>>>> [000020b2] 5d pop ebp ; housekeeping >>>>>>>>>> [000020b3] c3 ret ; never gets here >>>>>>>>>> Size in bytes:(0018) [000020b3] >>>>>>>>>> >>>>>>>>>> Exactly which step of DDD emulated by H0 was emulated >>>>>>>>>> incorrectly such that this emulation would be complete? >>>>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> If the simulation of a program with a loop of 5 iterations is >>>>>>>>> aborted after 3 iterations, all instructions are correctly >>>>>>>>> simulated. Nevertheless, it is an incorrect simulation, because >>>>>>>>> it should simulate up to the final state of the program. >>>>>>>>> >>>>>>>> >>>>>>>> It would be helpful if you answer the actual question being asked >>>>>>>> right here and thus not answer some other question that was asked >>>>>>>> somewhere else. >>>>>>> >>>>>>> If you do not understand that I answered the question why the >>>>>>> simulation is incorrect, it is hopeless. The question which >>>>>>> instruction is incorrect is not the right question. >>>>>>> >>>>>> >>>>>> If you say that something is incorrect and can't be specific >>>>>> then your rebuttal is pure bluster with no actual basis. >>>>>> >>>>> >>>>> If ..., but that condition is not present, so the 'then' does not >>>>> apply. >>>>> This makes the sentence completely superfluous. I would expect >>>>> better from someone who claims to be an experienced programmer. >>>>> >>>>> But since I pointed out in a very detailed way, why it is >>>>> incorrect, your reply shows that you do not understand where you >>>>> are talking about, which then becomes utterly nonsense. >>>>> >>>>> The question which instruction is incorrectly simulated already >>>>> shows your error. The error is not that an instruction is simulated >>>>> incorrectly, but that some instruction are not simulated at all. >>>>> Why is that already over your head? >>>>> >>>> >>>> It is a verified fact that the behavior that finite string DDD presents >>>> to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that >>>> this call DOES NOT RETURN. >>>> >>>> It is a verified fact that the behavior that finite string DDD presents >>>> to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) that >>>> this call DOES RETURN. >>>> >>>> I don't get why people here insist on lying about verified facts. >>>> >>> >>> We know that 'verified fact' for you means 'my wish'. >> Is it merely my wish that for decimal integers 2 + 3 = 5 or is this according to the semantics of arithmetic? >> Ignoramus? >> >> When we stipulate that the only measure of a correct emulation is the >> semantics of the x86 programming language then we see that when DDD is >> correctly emulated by H0 that its call to H0(DDD) cannot possibly return. >> >> _DDD() >> [00002172] 55 push ebp ; housekeeping >> [00002173] 8bec mov ebp,esp ; housekeeping >> [00002175] 6872210000 push 00002172 ; push DDD >> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >> [0000217f] 83c404 add esp,+04 >> [00002182] 5d pop ebp >> [00002183] c3 ret >> Size in bytes:(0018) [00002183] >> >> When we define H1 as identical to H0 except that DDD does not call H1 >> then we see that when DDD is correctly emulated by H1 that its call to >> H0(DDD) does return. This is the same behavior as the directly >> executed DDD(). >> > > Exactly what I predicted. Olcott can not point to any error in what I > said and just repeats his baseless claim. The semantics of the x86 programming language conclusively proves that when DDD is correctly emulated by H0 that its call to H0(DDD) cannot possibly return. _DDD() [00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) [0000217f] 83c404 add esp,+04 [00002182] 5d pop ebp [00002183] c3 ret Size in bytes:(0018) [00002183] The semantics of arithmetic conclusively proves that for the decimal integers 2 + 3 = 5. -- 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-24 11:43 +0200 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5bf4l$s2cu$1@dont-email.me> |
| In reply to | #107675 |
Op 23.jun.2024 om 15:30 schreef olcott: > On 6/23/2024 4:45 AM, Fred. Zwarts wrote: >> Op 22.jun.2024 om 20:53 schreef olcott: >>> On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >>>> Op 22.jun.2024 om 15:11 schreef olcott: >>>>> On 6/22/2024 4:27 AM, Fred. Zwarts wrote: >>>>>> Op 21.jun.2024 om 15:01 schreef olcott: >>>>>>> On 6/21/2024 2:44 AM, Fred. Zwarts wrote: >>>>>>>> Op 20.jun.2024 om 16:12 schreef olcott: >>>>>>>>> On 6/20/2024 3:09 AM, Fred. Zwarts wrote: >>>>>>>>>> Op 20.jun.2024 om 02:00 schreef olcott: >>>>>>>>>>> This shows all of the steps of HH0 simulating DDD >>>>>>>>>>> calling a simulated HH0 simulating DDD >>>>>>>>>>> >>>>>>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf >>>>>>>>>>> *Some of the key instructions are color coded* >>>>>>>>>>> GREEN---DebugStep Address >>>>>>>>>>> RED-----HH Address >>>>>>>>>>> YELLOW--All of the DDD instructions >>>>>>>>>>> CYAN----Return from DebugStep to Decide_Halting_HH >>>>>>>>>>> >>>>>>>>>>> _DDD() >>>>>>>>>>> [000020a2] 55 push ebp ; housekeeping >>>>>>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD >>>>>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0 >>>>>>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping >>>>>>>>>>> [000020b2] 5d pop ebp ; housekeeping >>>>>>>>>>> [000020b3] c3 ret ; never gets here >>>>>>>>>>> Size in bytes:(0018) [000020b3] >>>>>>>>>>> >>>>>>>>>>> Exactly which step of DDD emulated by H0 was emulated >>>>>>>>>>> incorrectly such that this emulation would be complete? >>>>>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If the simulation of a program with a loop of 5 iterations is >>>>>>>>>> aborted after 3 iterations, all instructions are correctly >>>>>>>>>> simulated. Nevertheless, it is an incorrect simulation, >>>>>>>>>> because it should simulate up to the final state of the program. >>>>>>>>>> >>>>>>>>> >>>>>>>>> It would be helpful if you answer the actual question being asked >>>>>>>>> right here and thus not answer some other question that was asked >>>>>>>>> somewhere else. >>>>>>>> >>>>>>>> If you do not understand that I answered the question why the >>>>>>>> simulation is incorrect, it is hopeless. The question which >>>>>>>> instruction is incorrect is not the right question. >>>>>>>> >>>>>>> >>>>>>> If you say that something is incorrect and can't be specific >>>>>>> then your rebuttal is pure bluster with no actual basis. >>>>>>> >>>>>> >>>>>> If ..., but that condition is not present, so the 'then' does not >>>>>> apply. >>>>>> This makes the sentence completely superfluous. I would expect >>>>>> better from someone who claims to be an experienced programmer. >>>>>> >>>>>> But since I pointed out in a very detailed way, why it is >>>>>> incorrect, your reply shows that you do not understand where you >>>>>> are talking about, which then becomes utterly nonsense. >>>>>> >>>>>> The question which instruction is incorrectly simulated already >>>>>> shows your error. The error is not that an instruction is >>>>>> simulated incorrectly, but that some instruction are not simulated >>>>>> at all. >>>>>> Why is that already over your head? >>>>>> >>>>> >>>>> It is a verified fact that the behavior that finite string DDD >>>>> presents >>>>> to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that >>>>> this call DOES NOT RETURN. >>>>> >>>>> It is a verified fact that the behavior that finite string DDD >>>>> presents >>>>> to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) that >>>>> this call DOES RETURN. >>>>> >>>>> I don't get why people here insist on lying about verified facts. >>>>> >>>> >>>> We know that 'verified fact' for you means 'my wish'. >>> > > Is it merely my wish that for decimal integers 2 + 3 = 5 > or is this according to the semantics of arithmetic? > >>> Ignoramus? >>> >>> When we stipulate that the only measure of a correct emulation is the >>> semantics of the x86 programming language then we see that when DDD >>> is correctly emulated by H0 that its call to H0(DDD) cannot possibly >>> return. >>> >>> _DDD() >>> [00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping >>> [00002175] 6872210000 push 00002172 ; push DDD >>> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >>> [0000217f] 83c404 add esp,+04 >>> [00002182] 5d pop ebp >>> [00002183] c3 ret >>> Size in bytes:(0018) [00002183] >>> >>> When we define H1 as identical to H0 except that DDD does not call H1 >>> then we see that when DDD is correctly emulated by H1 that its call >>> to H0(DDD) does return. This is the same behavior as the directly >>> executed DDD(). >>> >> >> Exactly what I predicted. Olcott can not point to any error in what I >> said and just repeats his baseless claim. > > The semantics of the x86 programming language conclusively proves > that when DDD is correctly emulated by H0 that its call to H0(DDD) > cannot possibly return. > > _DDD() > [00002172] 55 push ebp ; housekeeping > [00002173] 8bec mov ebp,esp ; housekeeping > [00002175] 6872210000 push 00002172 ; push DDD > [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) > [0000217f] 83c404 add esp,+04 > [00002182] 5d pop ebp > [00002183] c3 ret > Size in bytes:(0018) [00002183] > > The semantics of arithmetic conclusively proves that > for the decimal integers 2 + 3 = 5. > So, why don't you agree?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-24 13:16 -0500 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5cd6d$128l4$1@dont-email.me> |
| In reply to | #107718 |
On 6/24/2024 4:43 AM, Fred. Zwarts wrote: > Op 23.jun.2024 om 15:30 schreef olcott: >> On 6/23/2024 4:45 AM, Fred. Zwarts wrote: >>> Op 22.jun.2024 om 20:53 schreef olcott: >>>> On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >>>>> Op 22.jun.2024 om 15:11 schreef olcott: >>>>>> On 6/22/2024 4:27 AM, Fred. Zwarts wrote: >>>>>>> Op 21.jun.2024 om 15:01 schreef olcott: >>>>>>>> On 6/21/2024 2:44 AM, Fred. Zwarts wrote: >>>>>>>>> Op 20.jun.2024 om 16:12 schreef olcott: >>>>>>>>>> On 6/20/2024 3:09 AM, Fred. Zwarts wrote: >>>>>>>>>>> Op 20.jun.2024 om 02:00 schreef olcott: >>>>>>>>>>>> This shows all of the steps of HH0 simulating DDD >>>>>>>>>>>> calling a simulated HH0 simulating DDD >>>>>>>>>>>> >>>>>>>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf >>>>>>>>>>>> *Some of the key instructions are color coded* >>>>>>>>>>>> GREEN---DebugStep Address >>>>>>>>>>>> RED-----HH Address >>>>>>>>>>>> YELLOW--All of the DDD instructions >>>>>>>>>>>> CYAN----Return from DebugStep to Decide_Halting_HH >>>>>>>>>>>> >>>>>>>>>>>> _DDD() >>>>>>>>>>>> [000020a2] 55 push ebp ; housekeeping >>>>>>>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD >>>>>>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0 >>>>>>>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping >>>>>>>>>>>> [000020b2] 5d pop ebp ; housekeeping >>>>>>>>>>>> [000020b3] c3 ret ; never gets here >>>>>>>>>>>> Size in bytes:(0018) [000020b3] >>>>>>>>>>>> >>>>>>>>>>>> Exactly which step of DDD emulated by H0 was emulated >>>>>>>>>>>> incorrectly such that this emulation would be complete? >>>>>>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If the simulation of a program with a loop of 5 iterations is >>>>>>>>>>> aborted after 3 iterations, all instructions are correctly >>>>>>>>>>> simulated. Nevertheless, it is an incorrect simulation, >>>>>>>>>>> because it should simulate up to the final state of the program. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It would be helpful if you answer the actual question being asked >>>>>>>>>> right here and thus not answer some other question that was asked >>>>>>>>>> somewhere else. >>>>>>>>> >>>>>>>>> If you do not understand that I answered the question why the >>>>>>>>> simulation is incorrect, it is hopeless. The question which >>>>>>>>> instruction is incorrect is not the right question. >>>>>>>>> >>>>>>>> >>>>>>>> If you say that something is incorrect and can't be specific >>>>>>>> then your rebuttal is pure bluster with no actual basis. >>>>>>>> >>>>>>> >>>>>>> If ..., but that condition is not present, so the 'then' does not >>>>>>> apply. >>>>>>> This makes the sentence completely superfluous. I would expect >>>>>>> better from someone who claims to be an experienced programmer. >>>>>>> >>>>>>> But since I pointed out in a very detailed way, why it is >>>>>>> incorrect, your reply shows that you do not understand where you >>>>>>> are talking about, which then becomes utterly nonsense. >>>>>>> >>>>>>> The question which instruction is incorrectly simulated already >>>>>>> shows your error. The error is not that an instruction is >>>>>>> simulated incorrectly, but that some instruction are not >>>>>>> simulated at all. >>>>>>> Why is that already over your head? >>>>>>> >>>>>> >>>>>> It is a verified fact that the behavior that finite string DDD >>>>>> presents >>>>>> to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) >>>>>> that >>>>>> this call DOES NOT RETURN. >>>>>> >>>>>> It is a verified fact that the behavior that finite string DDD >>>>>> presents >>>>>> to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) >>>>>> that >>>>>> this call DOES RETURN. >>>>>> >>>>>> I don't get why people here insist on lying about verified facts. >>>>>> >>>>> >>>>> We know that 'verified fact' for you means 'my wish'. >>>> >> >> Is it merely my wish that for decimal integers 2 + 3 = 5 >> or is this according to the semantics of arithmetic? >> >>>> Ignoramus? >>>> >>>> When we stipulate that the only measure of a correct emulation is >>>> the semantics of the x86 programming language then we see that when >>>> DDD is correctly emulated by H0 that its call to H0(DDD) cannot >>>> possibly return. >>>> >>>> _DDD() >>>> [00002172] 55 push ebp ; housekeeping >>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>> [00002175] 6872210000 push 00002172 ; push DDD >>>> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >>>> [0000217f] 83c404 add esp,+04 >>>> [00002182] 5d pop ebp >>>> [00002183] c3 ret >>>> Size in bytes:(0018) [00002183] >>>> >>>> When we define H1 as identical to H0 except that DDD does not call >>>> H1 then we see that when DDD is correctly emulated by H1 that its >>>> call to H0(DDD) does return. This is the same behavior as the >>>> directly executed DDD(). >>>> >>> >>> Exactly what I predicted. Olcott can not point to any error in what I >>> said and just repeats his baseless claim. >> >> The semantics of the x86 programming language conclusively proves >> that when DDD is correctly emulated by H0 that its call to H0(DDD) >> cannot possibly return. >> >> _DDD() >> [00002172] 55 push ebp ; housekeeping >> [00002173] 8bec mov ebp,esp ; housekeeping >> [00002175] 6872210000 push 00002172 ; push DDD >> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >> [0000217f] 83c404 add esp,+04 >> [00002182] 5d pop ebp >> [00002183] c3 ret >> Size in bytes:(0018) [00002183] >> >> The semantics of arithmetic conclusively proves that >> for the decimal integers 2 + 3 = 5. >> > > So, why don't you agree? That seems to be a stupid thing to say. I insist that I do agree and then you ask why I do not agree, is what a Troll would say. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-24 19:23 -0400 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5cv62$10m6p$2@i2pn2.org> |
| In reply to | #107727 |
On 6/24/24 2:16 PM, olcott wrote: > On 6/24/2024 4:43 AM, Fred. Zwarts wrote: >> Op 23.jun.2024 om 15:30 schreef olcott: >>> On 6/23/2024 4:45 AM, Fred. Zwarts wrote: >>>> Op 22.jun.2024 om 20:53 schreef olcott: >>>>> On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >>>>>> Op 22.jun.2024 om 15:11 schreef olcott: >>>>>>> On 6/22/2024 4:27 AM, Fred. Zwarts wrote: >>>>>>>> Op 21.jun.2024 om 15:01 schreef olcott: >>>>>>>>> On 6/21/2024 2:44 AM, Fred. Zwarts wrote: >>>>>>>>>> Op 20.jun.2024 om 16:12 schreef olcott: >>>>>>>>>>> On 6/20/2024 3:09 AM, Fred. Zwarts wrote: >>>>>>>>>>>> Op 20.jun.2024 om 02:00 schreef olcott: >>>>>>>>>>>>> This shows all of the steps of HH0 simulating DDD >>>>>>>>>>>>> calling a simulated HH0 simulating DDD >>>>>>>>>>>>> >>>>>>>>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf >>>>>>>>>>>>> *Some of the key instructions are color coded* >>>>>>>>>>>>> GREEN---DebugStep Address >>>>>>>>>>>>> RED-----HH Address >>>>>>>>>>>>> YELLOW--All of the DDD instructions >>>>>>>>>>>>> CYAN----Return from DebugStep to Decide_Halting_HH >>>>>>>>>>>>> >>>>>>>>>>>>> _DDD() >>>>>>>>>>>>> [000020a2] 55 push ebp ; housekeeping >>>>>>>>>>>>> [000020a3] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD >>>>>>>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0 >>>>>>>>>>>>> [000020af] 83c404 add esp,+04 ; housekeeping >>>>>>>>>>>>> [000020b2] 5d pop ebp ; housekeeping >>>>>>>>>>>>> [000020b3] c3 ret ; never gets here >>>>>>>>>>>>> Size in bytes:(0018) [000020b3] >>>>>>>>>>>>> >>>>>>>>>>>>> Exactly which step of DDD emulated by H0 was emulated >>>>>>>>>>>>> incorrectly such that this emulation would be complete? >>>>>>>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If the simulation of a program with a loop of 5 iterations >>>>>>>>>>>> is aborted after 3 iterations, all instructions are >>>>>>>>>>>> correctly simulated. Nevertheless, it is an incorrect >>>>>>>>>>>> simulation, because it should simulate up to the final state >>>>>>>>>>>> of the program. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It would be helpful if you answer the actual question being >>>>>>>>>>> asked >>>>>>>>>>> right here and thus not answer some other question that was >>>>>>>>>>> asked >>>>>>>>>>> somewhere else. >>>>>>>>>> >>>>>>>>>> If you do not understand that I answered the question why the >>>>>>>>>> simulation is incorrect, it is hopeless. The question which >>>>>>>>>> instruction is incorrect is not the right question. >>>>>>>>>> >>>>>>>>> >>>>>>>>> If you say that something is incorrect and can't be specific >>>>>>>>> then your rebuttal is pure bluster with no actual basis. >>>>>>>>> >>>>>>>> >>>>>>>> If ..., but that condition is not present, so the 'then' does >>>>>>>> not apply. >>>>>>>> This makes the sentence completely superfluous. I would expect >>>>>>>> better from someone who claims to be an experienced programmer. >>>>>>>> >>>>>>>> But since I pointed out in a very detailed way, why it is >>>>>>>> incorrect, your reply shows that you do not understand where you >>>>>>>> are talking about, which then becomes utterly nonsense. >>>>>>>> >>>>>>>> The question which instruction is incorrectly simulated already >>>>>>>> shows your error. The error is not that an instruction is >>>>>>>> simulated incorrectly, but that some instruction are not >>>>>>>> simulated at all. >>>>>>>> Why is that already over your head? >>>>>>>> >>>>>>> >>>>>>> It is a verified fact that the behavior that finite string DDD >>>>>>> presents >>>>>>> to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) >>>>>>> that >>>>>>> this call DOES NOT RETURN. >>>>>>> >>>>>>> It is a verified fact that the behavior that finite string DDD >>>>>>> presents >>>>>>> to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) >>>>>>> that >>>>>>> this call DOES RETURN. >>>>>>> >>>>>>> I don't get why people here insist on lying about verified facts. >>>>>>> >>>>>> >>>>>> We know that 'verified fact' for you means 'my wish'. >>>>> >>> >>> Is it merely my wish that for decimal integers 2 + 3 = 5 >>> or is this according to the semantics of arithmetic? >>> >>>>> Ignoramus? >>>>> >>>>> When we stipulate that the only measure of a correct emulation is >>>>> the semantics of the x86 programming language then we see that when >>>>> DDD is correctly emulated by H0 that its call to H0(DDD) cannot >>>>> possibly return. >>>>> >>>>> _DDD() >>>>> [00002172] 55 push ebp ; housekeeping >>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >>>>> [0000217f] 83c404 add esp,+04 >>>>> [00002182] 5d pop ebp >>>>> [00002183] c3 ret >>>>> Size in bytes:(0018) [00002183] >>>>> >>>>> When we define H1 as identical to H0 except that DDD does not call >>>>> H1 then we see that when DDD is correctly emulated by H1 that its >>>>> call to H0(DDD) does return. This is the same behavior as the >>>>> directly executed DDD(). >>>>> >>>> >>>> Exactly what I predicted. Olcott can not point to any error in what >>>> I said and just repeats his baseless claim. >>> >>> The semantics of the x86 programming language conclusively proves >>> that when DDD is correctly emulated by H0 that its call to H0(DDD) >>> cannot possibly return. >>> >>> _DDD() >>> [00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping >>> [00002175] 6872210000 push 00002172 ; push DDD >>> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) >>> [0000217f] 83c404 add esp,+04 >>> [00002182] 5d pop ebp >>> [00002183] c3 ret >>> Size in bytes:(0018) [00002183] >>> >>> The semantics of arithmetic conclusively proves that >>> for the decimal integers 2 + 3 = 5. >>> >> >> So, why don't you agree? > > That seems to be a stupid thing to say. I insist > that I do agree and then you ask why I do not agree, > is what a Troll would say. > No, you claim something proves something bur refuse to actually form the proof. The claim of the existance of a proof is not a proof of the claim.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-23 11:22 +0300 |
| Message-ID | <v58m12$8mmo$1@dont-email.me> |
| In reply to | #107463 |
The subject line is not quite correct. The execution trace is not 195 pages long, only 159 pages. In the beginning of the file there is other material, mainly several disaasembled functions, many of which do nothing. Several points in the trace are incorrect. On 2024-06-20 00:00:48 +0000, olcott said: > This shows all of the steps of HH0 simulating DDD > calling a simulated HH0 simulating DDD > > https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf > *Some of the key instructions are color coded* > GREEN---DebugStep Address > RED-----HH Address > YELLOW--All of the DDD instructions > CYAN----Return from DebugStep to Decide_Halting_HH > > _DDD() > [000020a2] 55 push ebp ; housekeeping > [000020a3] 8bec mov ebp,esp ; housekeeping > [000020a5] 68a2200000 push 000020a2 ; push DDD > [000020aa] e8f3f9ffff call 00001aa2 ; call H0 > [000020af] 83c404 add esp,+04 ; housekeeping > [000020b2] 5d pop ebp ; housekeeping > [000020b3] c3 ret ; never gets here > Size in bytes:(0018) [000020b3] That code is not from the mentined trace file. In that file _DDD() is at the addresses 2093..20a4. According to the trace no instruction at the address is executed (because that address points to the last byte of a three byte instruction. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-23 08:17 -0500 |
| Message-ID | <v59797$brmn$1@dont-email.me> |
| In reply to | #107664 |
On 6/23/2024 3:22 AM, Mikko wrote: > The subject line is not quite correct. The execution trace is not > 195 pages long, only 159 pages. In the beginning of the file there > is other material, mainly several disaasembled functions, many of > which do nothing. > > Several points in the trace are incorrect. > > On 2024-06-20 00:00:48 +0000, olcott said: > >> This shows all of the steps of HH0 simulating DDD >> calling a simulated HH0 simulating DDD >> >> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf >> *Some of the key instructions are color coded* >> GREEN---DebugStep Address >> RED-----HH Address >> YELLOW--All of the DDD instructions >> CYAN----Return from DebugStep to Decide_Halting_HH >> >> _DDD() >> [000020a2] 55 push ebp ; housekeeping >> [000020a3] 8bec mov ebp,esp ; housekeeping >> [000020a5] 68a2200000 push 000020a2 ; push DDD >> [000020aa] e8f3f9ffff call 00001aa2 ; call H0 >> [000020af] 83c404 add esp,+04 ; housekeeping >> [000020b2] 5d pop ebp ; housekeeping >> [000020b3] c3 ret ; never gets here >> Size in bytes:(0018) [000020b3] > > That code is not from the mentined trace file. In that file _DDD() > is at the addresses 2093..20a4. According to the trace no instruction > at the address is executed (because that address points to the last byte > of a three byte instruction. > In order to make my examples I must edit the code and this changes the addresses of some functions. When we stipulate that the only measure of a correct emulation is the semantics of the x86 programming language then we see that when DDD is correctly emulated by H0 that its call to H0(DDD) cannot possibly return. _DDD() [00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call H0(DDD) [0000217f] 83c404 add esp,+04 [00002182] 5d pop ebp [00002183] c3 ret Size in bytes:(0018) [00002183] The point is that the call from DDD to H0(DDD) cannot possibly return to DDD correctly emulated by HHH. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-24 10:37 +0300 |
| Message-ID | <v5b7nv$qvrb$1@dont-email.me> |
| In reply to | #107672 |
On 2024-06-23 13:17:27 +0000, olcott said: > On 6/23/2024 3:22 AM, Mikko wrote: >> The subject line is not quite correct. The execution trace is not >> 195 pages long, only 159 pages. In the beginning of the file there >> is other material, mainly several disaasembled functions, many of >> which do nothing. >> >> Several points in the trace are incorrect. >> >> On 2024-06-20 00:00:48 +0000, olcott said: >> >>> This shows all of the steps of HH0 simulating DDD >>> calling a simulated HH0 simulating DDD >>> >>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf >>> *Some of the key instructions are color coded* >>> GREEN---DebugStep Address >>> RED-----HH Address >>> YELLOW--All of the DDD instructions >>> CYAN----Return from DebugStep to Decide_Halting_HH >>> >>> _DDD() >>> [000020a2] 55 push ebp ; housekeeping >>> [000020a3] 8bec mov ebp,esp ; housekeeping >>> [000020a5] 68a2200000 push 000020a2 ; push DDD >>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0 >>> [000020af] 83c404 add esp,+04 ; housekeeping >>> [000020b2] 5d pop ebp ; housekeeping >>> [000020b3] c3 ret ; never gets here >>> Size in bytes:(0018) [000020b3] >> >> That code is not from the mentined trace file. In that file _DDD() >> is at the addresses 2093..20a4. According to the trace no instruction >> at the address is executed (because that address points to the last byte >> of a three byte instruction. > > In order to make my examples I must edit the code > and this changes the addresses of some functions. Why do you need to make an example when you already have one in the file mentioned in the subject line? -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-24 08:48 -0500 |
| Message-ID | <v5btf3$v0vb$4@dont-email.me> |
| In reply to | #107717 |
On 6/24/2024 2:37 AM, Mikko wrote: > On 2024-06-23 13:17:27 +0000, olcott said: > >> On 6/23/2024 3:22 AM, Mikko wrote: >>> The subject line is not quite correct. The execution trace is not >>> 195 pages long, only 159 pages. In the beginning of the file there >>> is other material, mainly several disaasembled functions, many of >>> which do nothing. >>> >>> Several points in the trace are incorrect. >>> >>> On 2024-06-20 00:00:48 +0000, olcott said: >>> >>>> This shows all of the steps of HH0 simulating DDD >>>> calling a simulated HH0 simulating DDD >>>> >>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf >>>> *Some of the key instructions are color coded* >>>> GREEN---DebugStep Address >>>> RED-----HH Address >>>> YELLOW--All of the DDD instructions >>>> CYAN----Return from DebugStep to Decide_Halting_HH >>>> >>>> _DDD() >>>> [000020a2] 55 push ebp ; housekeeping >>>> [000020a3] 8bec mov ebp,esp ; housekeeping >>>> [000020a5] 68a2200000 push 000020a2 ; push DDD >>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0 >>>> [000020af] 83c404 add esp,+04 ; housekeeping >>>> [000020b2] 5d pop ebp ; housekeeping >>>> [000020b3] c3 ret ; never gets here >>>> Size in bytes:(0018) [000020b3] >>> >>> That code is not from the mentined trace file. In that file _DDD() >>> is at the addresses 2093..20a4. According to the trace no instruction >>> at the address is executed (because that address points to the last byte >>> of a three byte instruction. >> >> In order to make my examples I must edit the code >> and this changes the addresses of some functions. > > Why do you need to make an example when you already have one > in the file mentioned in the subject line? > I had to make a few more examples such as HH1(DD,DD) -- 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 | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-24 19:36 +0000 |
| Message-ID | <v5chru$10816$1@i2pn2.org> |
| In reply to | #107723 |
Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott: > On 6/24/2024 2:37 AM, Mikko wrote: >> On 2024-06-23 13:17:27 +0000, olcott said: >>> On 6/23/2024 3:22 AM, Mikko wrote: >>>> That code is not from the mentined trace file. In that file _DDD() >>>> is at the addresses 2093..20a4. According to the trace no instruction >>>> at the address is executed (because that address points to the last >>>> byte of a three byte instruction. >>> >>> In order to make my examples I must edit the code and this changes the >>> addresses of some functions. >> >> Why do you need to make an example when you already have one in the >> file mentioned in the subject line? >> > I had to make a few more examples such as HH1(DD,DD) AFACT HH1 is the same as HH0, right? What happens when HH1 tries to simulate a function DD1 that only calls HH1? -- Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-24 16:04 -0500 |
| Message-ID | <v5cn01$149dc$1@dont-email.me> |
| In reply to | #107728 |
On 6/24/2024 2:36 PM, joes wrote:
> Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott:
>> On 6/24/2024 2:37 AM, Mikko wrote:
>>> On 2024-06-23 13:17:27 +0000, olcott said:
>>>> On 6/23/2024 3:22 AM, Mikko wrote:
>>>>> That code is not from the mentined trace file. In that file _DDD()
>>>>> is at the addresses 2093..20a4. According to the trace no instruction
>>>>> at the address is executed (because that address points to the last
>>>>> byte of a three byte instruction.
>>>>
>>>> In order to make my examples I must edit the code and this changes the
>>>> addresses of some functions.
>>>
>>> Why do you need to make an example when you already have one in the
>>> file mentioned in the subject line?
>>>
>> I had to make a few more examples such as HH1(DD,DD)
> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to
> simulate a function DD1 that only calls HH1?
>
typedef uint32_t u32;
u32 H(u32 P, u32 I);
int P(u32 x)
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(P,P);
}
I am going to have to go through my code and standardize my names.
H(P,P) was the original name. Then I had to make a one parameter
version, a version that is identical to H, except P does not call
it and then versions using different algorithms. People have never
been able to understand the different algorithm.
typedef void (*ptr)();
typedef int (*ptr2)();
int HH(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
int HH1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
int HHH(ptr P); // used with void DDD() that calls HHH
int HHH1(ptr P); // used with void DDD() that calls HHH
*The different algorithm version has been deprecated*
int H(ptr2 , ptr2 I); // used with int D(ptr2 P) that calls H
int H1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls H
*It is much easier for people to see the infinite recursion*
*behavior pattern when they see it actually cycle through the*
*same instructions twice*
The H1, HH1, HHH1 versions are identical to H, HH, HHH
except that their input does not call them.
When we stipulate that the only measure of a correct emulation is the
semantics of the x86 programming language then we see that when DDD is
correctly emulated by H0 that its call to H0(DDD) cannot possibly return.
*HHH and HHH1 are named H0 and H1 in the paper*
When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see
that when DDD is correctly emulated by H0 that its call to
H0(DDD) cannot possibly return.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When we define H1 as identical to H0 except that DDD does not
call H1 then we see that when DDD is correctly emulated by H1
that its call to H0(DDD) does return. This is the same behavior
as the directly executed DDD().
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-24 19:43 -0400 |
| Message-ID | <v5d0a8$10m6o$5@i2pn2.org> |
| In reply to | #107733 |
On 6/24/24 5:04 PM, olcott wrote:
> On 6/24/2024 2:36 PM, joes wrote:
>> Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott:
>>> On 6/24/2024 2:37 AM, Mikko wrote:
>>>> On 2024-06-23 13:17:27 +0000, olcott said:
>>>>> On 6/23/2024 3:22 AM, Mikko wrote:
>>>>>> That code is not from the mentined trace file. In that file _DDD()
>>>>>> is at the addresses 2093..20a4. According to the trace no instruction
>>>>>> at the address is executed (because that address points to the last
>>>>>> byte of a three byte instruction.
>>>>>
>>>>> In order to make my examples I must edit the code and this changes the
>>>>> addresses of some functions.
>>>>
>>>> Why do you need to make an example when you already have one in the
>>>> file mentioned in the subject line?
>>>>
>>> I had to make a few more examples such as HH1(DD,DD)
>> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to
>> simulate a function DD1 that only calls HH1?
>>
>
> typedef uint32_t u32;
> u32 H(u32 P, u32 I);
>
> int P(u32 x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> H(P,P);
> }
>
> I am going to have to go through my code and standardize my names.
> H(P,P) was the original name. Then I had to make a one parameter
> version, a version that is identical to H, except P does not call
> it and then versions using different algorithms. People have never
> been able to understand the different algorithm.
>
> typedef void (*ptr)();
> typedef int (*ptr2)();
> int HH(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
> int HH1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
> int HHH(ptr P); // used with void DDD() that calls HHH
> int HHH1(ptr P); // used with void DDD() that calls HHH
>
> *The different algorithm version has been deprecated*
> int H(ptr2 , ptr2 I); // used with int D(ptr2 P) that calls H
> int H1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls H
>
> *It is much easier for people to see the infinite recursion*
> *behavior pattern when they see it actually cycle through the*
> *same instructions twice*
>
> The H1, HH1, HHH1 versions are identical to H, HH, HHH
> except that their input does not call them.
>
> When we stipulate that the only measure of a correct emulation is the
> semantics of the x86 programming language then we see that when DDD is
> correctly emulated by H0 that its call to H0(DDD) cannot possibly return.
>
> *HHH and HHH1 are named H0 and H1 in the paper*
>
> When we stipulate that the only measure of a correct emulation
> is the semantics of the x86 programming language then we see
> that when DDD is correctly emulated by H0 that its call to
> H0(DDD) cannot possibly return.
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> When we define H1 as identical to H0 except that DDD does not
> call H1 then we see that when DDD is correctly emulated by H1
> that its call to H0(DDD) does return. This is the same behavior
> as the directly executed DDD().
>
>
Which just shows that you don't understand the rules and principles of
the field you are talking about.
When you stipulate the measure, you remove all possibility for your
decider to be a Halt decider, as you have stated you measure is
different than what a Halt Decider must use.
It seems, you just don't understand the concept of what a Definition or
a Requirement actually is.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-25 14:08 +0200 |
| Message-ID | <v5ebvr$1hs89$1@dont-email.me> |
| In reply to | #107733 |
Op 24.jun.2024 om 23:04 schreef olcott:
> On 6/24/2024 2:36 PM, joes wrote:
>> Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott:
>>> On 6/24/2024 2:37 AM, Mikko wrote:
>>>> On 2024-06-23 13:17:27 +0000, olcott said:
>>>>> On 6/23/2024 3:22 AM, Mikko wrote:
>>>>>> That code is not from the mentined trace file. In that file _DDD()
>>>>>> is at the addresses 2093..20a4. According to the trace no instruction
>>>>>> at the address is executed (because that address points to the last
>>>>>> byte of a three byte instruction.
>>>>>
>>>>> In order to make my examples I must edit the code and this changes the
>>>>> addresses of some functions.
>>>>
>>>> Why do you need to make an example when you already have one in the
>>>> file mentioned in the subject line?
>>>>
>>> I had to make a few more examples such as HH1(DD,DD)
>> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to
>> simulate a function DD1 that only calls HH1?
>>
>
> typedef uint32_t u32;
> u32 H(u32 P, u32 I);
>
> int P(u32 x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> H(P,P);
> }
>
> I am going to have to go through my code and standardize my names.
> H(P,P) was the original name. Then I had to make a one parameter
> version, a version that is identical to H, except P does not call
> it and then versions using different algorithms. People have never
> been able to understand the different algorithm.
>
> typedef void (*ptr)();
> typedef int (*ptr2)();
> int HH(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
> int HH1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
> int HHH(ptr P); // used with void DDD() that calls HHH
> int HHH1(ptr P); // used with void DDD() that calls HHH
>
> *The different algorithm version has been deprecated*
> int H(ptr2 , ptr2 I); // used with int D(ptr2 P) that calls H
> int H1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls H
>
> *It is much easier for people to see the infinite recursion*
> *behavior pattern when they see it actually cycle through the*
> *same instructions twice*
Twice is not equal to infinitely. When will you see that?
It is strange that you call that an infinite recursion, when H aborts
after two cycles and the simulated H cannot reach its own abort
operation, because it is aborted when it had only one more cycle to go.
None of the aborted simulations would cycle more than twice, so infinite
recursion is not seen for an H that aborts the simulation of itself.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-25 08:12 -0500 |
| Message-ID | <v5efod$1ikpr$1@dont-email.me> |
| In reply to | #107784 |
On 6/25/2024 7:08 AM, Fred. Zwarts wrote:
> Op 24.jun.2024 om 23:04 schreef olcott:
>> On 6/24/2024 2:36 PM, joes wrote:
>>> Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott:
>>>> On 6/24/2024 2:37 AM, Mikko wrote:
>>>>> On 2024-06-23 13:17:27 +0000, olcott said:
>>>>>> On 6/23/2024 3:22 AM, Mikko wrote:
>>>>>>> That code is not from the mentined trace file. In that file _DDD()
>>>>>>> is at the addresses 2093..20a4. According to the trace no
>>>>>>> instruction
>>>>>>> at the address is executed (because that address points to the last
>>>>>>> byte of a three byte instruction.
>>>>>>
>>>>>> In order to make my examples I must edit the code and this changes
>>>>>> the
>>>>>> addresses of some functions.
>>>>>
>>>>> Why do you need to make an example when you already have one in the
>>>>> file mentioned in the subject line?
>>>>>
>>>> I had to make a few more examples such as HH1(DD,DD)
>>> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to
>>> simulate a function DD1 that only calls HH1?
>>>
>>
>> typedef uint32_t u32;
>> u32 H(u32 P, u32 I);
>>
>> int P(u32 x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> int main()
>> {
>> H(P,P);
>> }
>>
>> I am going to have to go through my code and standardize my names.
>> H(P,P) was the original name. Then I had to make a one parameter
>> version, a version that is identical to H, except P does not call
>> it and then versions using different algorithms. People have never
>> been able to understand the different algorithm.
>>
>> typedef void (*ptr)();
>> typedef int (*ptr2)();
>> int HH(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>> int HH1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>> int HHH(ptr P); // used with void DDD() that calls HHH
>> int HHH1(ptr P); // used with void DDD() that calls HHH
>>
>> *The different algorithm version has been deprecated*
>> int H(ptr2 , ptr2 I); // used with int D(ptr2 P) that calls H
>> int H1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls H
>>
>> *It is much easier for people to see the infinite recursion*
>> *behavior pattern when they see it actually cycle through the*
>> *same instructions twice*
>
> Twice is not equal to infinitely. When will you see that?
> It is strange that you call that an infinite recursion, when H aborts
> after two cycles and the simulated H cannot reach its own abort
> operation, because it is aborted when it had only one more cycle to go.
> None of the aborted simulations would cycle more than twice, so infinite
> recursion is not seen for an H that aborts the simulation of itself.
typedef void (*ptr)();
int H0(ptr P);
void DDD()
{
H0(DDD);
}
int main()
{
H0(DDD);
}
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.
Until you acknowledge this is true, this is the
only thing that I am willing to talk to you about.
--
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-25 16:13 +0200 |
| Message-ID | <v5ejau$1iq57$1@dont-email.me> |
| In reply to | #107787 |
Op 25.jun.2024 om 15:12 schreef olcott:
> On 6/25/2024 7:08 AM, Fred. Zwarts wrote:
>> Op 24.jun.2024 om 23:04 schreef olcott:
>>> On 6/24/2024 2:36 PM, joes wrote:
>>>> Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott:
>>>>> On 6/24/2024 2:37 AM, Mikko wrote:
>>>>>> On 2024-06-23 13:17:27 +0000, olcott said:
>>>>>>> On 6/23/2024 3:22 AM, Mikko wrote:
>>>>>>>> That code is not from the mentined trace file. In that file _DDD()
>>>>>>>> is at the addresses 2093..20a4. According to the trace no
>>>>>>>> instruction
>>>>>>>> at the address is executed (because that address points to the last
>>>>>>>> byte of a three byte instruction.
>>>>>>>
>>>>>>> In order to make my examples I must edit the code and this
>>>>>>> changes the
>>>>>>> addresses of some functions.
>>>>>>
>>>>>> Why do you need to make an example when you already have one in the
>>>>>> file mentioned in the subject line?
>>>>>>
>>>>> I had to make a few more examples such as HH1(DD,DD)
>>>> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to
>>>> simulate a function DD1 that only calls HH1?
>>>>
>>>
>>> typedef uint32_t u32;
>>> u32 H(u32 P, u32 I);
>>>
>>> int P(u32 x)
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>> H(P,P);
>>> }
>>>
>>> I am going to have to go through my code and standardize my names.
>>> H(P,P) was the original name. Then I had to make a one parameter
>>> version, a version that is identical to H, except P does not call
>>> it and then versions using different algorithms. People have never
>>> been able to understand the different algorithm.
>>>
>>> typedef void (*ptr)();
>>> typedef int (*ptr2)();
>>> int HH(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>>> int HH1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>>> int HHH(ptr P); // used with void DDD() that calls HHH
>>> int HHH1(ptr P); // used with void DDD() that calls HHH
>>>
>>> *The different algorithm version has been deprecated*
>>> int H(ptr2 , ptr2 I); // used with int D(ptr2 P) that calls H
>>> int H1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls H
>>>
>>> *It is much easier for people to see the infinite recursion*
>>> *behavior pattern when they see it actually cycle through the*
>>> *same instructions twice*
>>
>> Twice is not equal to infinitely. When will you see that?
>> It is strange that you call that an infinite recursion, when H aborts
>> after two cycles and the simulated H cannot reach its own abort
>> operation, because it is aborted when it had only one more cycle to go.
>> None of the aborted simulations would cycle more than twice, so
>> infinite recursion is not seen for an H that aborts the simulation of
>> itself.
>
> typedef void (*ptr)();
> int H0(ptr P);
>
> void DDD()
> {
> H0(DDD);
> }
>
> int main()
> {
> H0(DDD);
> }
>
> _DDD()
> [00002172] 55 push ebp ; housekeeping
> [00002173] 8bec mov ebp,esp ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
> [0000217f] 83c404 add esp,+04
> [00002182] 5d pop ebp
> [00002183] c3 ret
> Size in bytes:(0018) [00002183]
>
> The call from DDD to H0(DDD) when DDD is correctly emulated
> by H0 cannot possibly return.
Contradictio in terminis. The fact that the simulated H0 does not return
shows that the simulation is incorrect.
The simulated H0 does not return, because it is aborted one cycle too
soon. One cycle later it would return. This is what the simulation by H1
and the direct execution shows.
You could as well claim that the correct addition 1+1=3 shows that 1+1>2.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-25 12:29 -0500 |
| Message-ID | <v5eup8$1lar1$2@dont-email.me> |
| In reply to | #107795 |
On 6/25/2024 9:13 AM, Fred. Zwarts wrote:
> Op 25.jun.2024 om 15:12 schreef olcott:
>> On 6/25/2024 7:08 AM, Fred. Zwarts wrote:
>>> Op 24.jun.2024 om 23:04 schreef olcott:
>>>> On 6/24/2024 2:36 PM, joes wrote:
>>>>> Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott:
>>>>>> On 6/24/2024 2:37 AM, Mikko wrote:
>>>>>>> On 2024-06-23 13:17:27 +0000, olcott said:
>>>>>>>> On 6/23/2024 3:22 AM, Mikko wrote:
>>>>>>>>> That code is not from the mentined trace file. In that file _DDD()
>>>>>>>>> is at the addresses 2093..20a4. According to the trace no
>>>>>>>>> instruction
>>>>>>>>> at the address is executed (because that address points to the
>>>>>>>>> last
>>>>>>>>> byte of a three byte instruction.
>>>>>>>>
>>>>>>>> In order to make my examples I must edit the code and this
>>>>>>>> changes the
>>>>>>>> addresses of some functions.
>>>>>>>
>>>>>>> Why do you need to make an example when you already have one in the
>>>>>>> file mentioned in the subject line?
>>>>>>>
>>>>>> I had to make a few more examples such as HH1(DD,DD)
>>>>> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to
>>>>> simulate a function DD1 that only calls HH1?
>>>>>
>>>>
>>>> typedef uint32_t u32;
>>>> u32 H(u32 P, u32 I);
>>>>
>>>> int P(u32 x)
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> H(P,P);
>>>> }
>>>>
>>>> I am going to have to go through my code and standardize my names.
>>>> H(P,P) was the original name. Then I had to make a one parameter
>>>> version, a version that is identical to H, except P does not call
>>>> it and then versions using different algorithms. People have never
>>>> been able to understand the different algorithm.
>>>>
>>>> typedef void (*ptr)();
>>>> typedef int (*ptr2)();
>>>> int HH(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>>>> int HH1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>>>> int HHH(ptr P); // used with void DDD() that calls HHH
>>>> int HHH1(ptr P); // used with void DDD() that calls HHH
>>>>
>>>> *The different algorithm version has been deprecated*
>>>> int H(ptr2 , ptr2 I); // used with int D(ptr2 P) that calls H
>>>> int H1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls H
>>>>
>>>> *It is much easier for people to see the infinite recursion*
>>>> *behavior pattern when they see it actually cycle through the*
>>>> *same instructions twice*
>>>
>>> Twice is not equal to infinitely. When will you see that?
>>> It is strange that you call that an infinite recursion, when H aborts
>>> after two cycles and the simulated H cannot reach its own abort
>>> operation, because it is aborted when it had only one more cycle to go.
>>> None of the aborted simulations would cycle more than twice, so
>>> infinite recursion is not seen for an H that aborts the simulation of
>>> itself.
>>
>> typedef void (*ptr)();
>> int H0(ptr P);
>>
>> void DDD()
>> {
>> H0(DDD);
>> }
>>
>> int main()
>> {
>> H0(DDD);
>> }
>>
>> _DDD()
>> [00002172] 55 push ebp ; housekeeping
>> [00002173] 8bec mov ebp,esp ; housekeeping
>> [00002175] 6872210000 push 00002172 ; push DDD
>> [0000217a] e853f4ffff call 000015d2 ; call H0(DDD)
>> [0000217f] 83c404 add esp,+04
>> [00002182] 5d pop ebp
>> [00002183] c3 ret
>> Size in bytes:(0018) [00002183]
>>
>> The call from DDD to H0(DDD) when DDD is correctly emulated
>> by H0 cannot possibly return.
>
> Contradictio in terminis. The fact that the simulated H0 does not return
> shows that the simulation is incorrect.
void Infinite_Recursion()
{
Infinite_Recursion();
}
Ah so you simply *DON'T BELIEVE IN* infinite recursion where a
correct simulating termination analyzer would be required to
abort its simulation to correctly report non-terminating behavior.
That seems quite dumb of you.
> The simulated H0 does not return, because it is aborted one cycle too
> soon. One cycle later it would return.
Complete lack of sufficient software engineering skill.
Unless the outermost directly executed H0 aborts its
simulation after a fixed number of recursive invocations
NONE OF THEM DO.
This did baffle me for three days 3.5 years ago until
I took the time to THINK IT ALL THE WAY THROUGH.
> This is what the simulation by H1
> and the direct execution shows.
> You could as well claim that the correct addition 1+1=3 shows that 1+1>2.
>
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.theory
csiph-web