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 | 17 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 10 of 10 — ← Prev page 1 … 8 9 [10]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-26 20:55 +0000 |
| Subject | Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure |
| Message-ID | <v5hv8o$174q9$1@i2pn2.org> |
| In reply to | #107870 |
Am Wed, 26 Jun 2024 15:10:36 -0500 schrieb olcott: > On 6/26/2024 2:43 PM, Alan Mackenzie wrote: >> olcott <polcott333@gmail.com> wrote: >> Your posts are, in the main, tedious in the extreme. When you repeat >> the same thing 30 times over, you can't expect anybody to read each of >> the repetitions as though it were fresh and new. > I must keep repeating them until they bother to pay attention to the > exact words that I am exactly saying because every fake rebuttal is the > strawman deception. That's not how it works. You should try to rephrase if you are not understood. A strawman is a misrepresentation. I think we understand you correctly, if at all. >> All the people you are debating with care about the truth. That's why >> they're in this group debating with you. > It seems to me that they are only here to play the troll. This made me laugh hysterically. >> Anything "like" what an x86 emulator does is insufficiently precise. > An x86 emulator is already 100% perfectly precise if the trolls that > review my work don't think so then that proves that they are trolls. Then why do you think that emulator can abort or otherwise change the behaviour of its input? >> And the "semantics of x86" don't specify anthing beyond the meaning of >> x86 programs in general. > *That is a stupid thing to say* > The semantics of the x86 language provides 100% of all of the details of > the behavior of these two functions. There is nothing that makes this specific to x86. (Also C is not asm.) >>> That DDD correctly emulated by H0 must continue to repeat its first >>> four instructions is self-evident true to anyone knowing what an x86 >>> emulator is and having sufficient basic knowledge of the x86 >>> programming language. >> It is not self-evident. > To anyone that is mostly clueless about the x86 language. Who are you talking to then, if you disregard our qualifications? >>> The CS courses that fulfilled the requirements for a BSCS degree at my >>> university had quite a bit of programming. One of the projects for the >>> data structures course was to write a LISP interpreter that could do >>> car, cdr and cons. >>> https://www.gnu.org/software/emacs/manual/html_node/eintr/car-cdr- _0026-cons.html >> I'm familiar with that page, being a member of the Emacs maintenance >> team. RIP >>>> I haven't seen other people here lying. >>> When they say that I am wrong knowing that they do not understand what >>> I am saying this would be a lie. It's your responsibility to make yourself clear. -- 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-26 16:15 -0500 |
| Subject | Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure |
| Message-ID | <v5i0cs$2b1r9$1@dont-email.me> |
| In reply to | #107872 |
On 6/26/2024 3:55 PM, joes wrote: > Am Wed, 26 Jun 2024 15:10:36 -0500 schrieb olcott: >> On 6/26/2024 2:43 PM, Alan Mackenzie wrote: >>> olcott <polcott333@gmail.com> wrote: > >>> Your posts are, in the main, tedious in the extreme. When you repeat >>> the same thing 30 times over, you can't expect anybody to read each of >>> the repetitions as though it were fresh and new. >> I must keep repeating them until they bother to pay attention to the >> exact words that I am exactly saying because every fake rebuttal is the >> strawman deception. > That's not how it works. You should try to rephrase if you are not > understood. > A strawman is a misrepresentation. I think we understand you correctly, > if at all. > >>> All the people you are debating with care about the truth. That's why >>> they're in this group debating with you. >> It seems to me that they are only here to play the troll. > This made me laugh hysterically. > >>> Anything "like" what an x86 emulator does is insufficiently precise. >> An x86 emulator is already 100% perfectly precise if the trolls that >> review my work don't think so then that proves that they are trolls. > Then why do you think that emulator can abort or otherwise change the > behaviour of its input? > >>> And the "semantics of x86" don't specify anthing beyond the meaning of >>> x86 programs in general. >> *That is a stupid thing to say* >> The semantics of the x86 language provides 100% of all of the details of >> the behavior of these two functions. > There is nothing that makes this specific to x86. (Also C is not asm.) > Yes stupid this makes it 100% specific to the x86 language. _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 x86 emulator H0 cannot possibly return. -- 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-27 09:34 +0300 |
| Message-ID | <v5j15p$2k7r0$1@dont-email.me> |
| In reply to | #107856 |
On 2024-06-26 12:55:43 +0000, olcott said:
> On 6/26/2024 3:10 AM, Mikko wrote:
>> On 2024-06-25 17:29:12 +0000, olcott said:
>>
>>> 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.
>>
>> The relevant area of software engineering is testing. The usual attitude of
>> software engineers is that a program is accpted when it has been sufficiently
>> tested and passed all tests. Consequently, an important part of sofware work
>> is the design of tests.
>>
>> In the current context the program to be tested is a halting decider.
>
> *NO IT IS NOT. H0 IS ONLY AN X86 EMULATOR*
> After you quit lying about the behavior of DDD correctly
> emulated by H0 then we can move on to the next point.
This discussion is about HH0. The larger context of this discussion is
halting deiders and proofs of non-existence of halting deciders.
You have not disagreed with anyting I said, so if you say that I lied
then you reveal that you lied.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-27 12:07 -0500 |
| Message-ID | <v5k688$2qsdr$2@dont-email.me> |
| In reply to | #107916 |
On 6/27/2024 1:34 AM, Mikko wrote:
> On 2024-06-26 12:55:43 +0000, olcott said:
>
>> On 6/26/2024 3:10 AM, Mikko wrote:
>>> On 2024-06-25 17:29:12 +0000, olcott said:
>>>
>>>> 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.
>>>
>>> The relevant area of software engineering is testing. The usual
>>> attitude of
>>> software engineers is that a program is accpted when it has been
>>> sufficiently
>>> tested and passed all tests. Consequently, an important part of
>>> sofware work
>>> is the design of tests.
>>>
>>> In the current context the program to be tested is a halting decider.
>>
>> *NO IT IS NOT. H0 IS ONLY AN X86 EMULATOR*
>> After you quit lying about the behavior of DDD correctly
>> emulated by H0 then we can move on to the next point.
>
> This discussion is about HH0. The larger context of this discussion is
> halting deiders and proofs of non-existence of halting deciders.
>
> You have not disagreed with anyting I said, so if you say that I lied
> then you reveal that you lied.
>
Until you agree with this we cannot move on to the next
and final point that proves I am correct. Proving that
point may possibly take longer than the rest of my life
so let's not delay this OK?
[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 x86 emulator H0 cannot possibly return.
--
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-28 10:17 +0300 |
| Message-ID | <v5lo1l$3843b$1@dont-email.me> |
| In reply to | #107932 |
On 2024-06-27 17:07:20 +0000, olcott said:
> On 6/27/2024 1:34 AM, Mikko wrote:
>> On 2024-06-26 12:55:43 +0000, olcott said:
>>
>>> On 6/26/2024 3:10 AM, Mikko wrote:
>>>> On 2024-06-25 17:29:12 +0000, olcott said:
>>>>
>>>>> 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.
>>>>
>>>> The relevant area of software engineering is testing. The usual attitude of
>>>> software engineers is that a program is accpted when it has been sufficiently
>>>> tested and passed all tests. Consequently, an important part of sofware work
>>>> is the design of tests.
>>>>
>>>> In the current context the program to be tested is a halting decider.
>>>
>>> *NO IT IS NOT. H0 IS ONLY AN X86 EMULATOR*
>>> After you quit lying about the behavior of DDD correctly
>>> emulated by H0 then we can move on to the next point.
>>
>> This discussion is about HH0. The larger context of this discussion is
>> halting deiders and proofs of non-existence of halting deciders.
>>
>> You have not disagreed with anyting I said, so if you say that I lied
>> then you reveal that you lied.
>>
> Until you agree with this we cannot move on to the next
> and final point that proves I am correct. Proving that
> point may possibly take longer than the rest of my life
> so let's not delay this OK?
>
> [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 x86 emulator H0 cannot possibly return.
If it is too hard to prove that H0 has the properties you claim
then an agreement is unlikely. Perhaps you should Δ instead and
just assume it has the properties you consider essential. The
full proof of your claim does not need much more.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-28 10:28 -0500 |
| Subject | Re: 197 page execution trace of DDD correctly simulated by HHH |
| Message-ID | <v5mkrn$3cibm$8@dont-email.me> |
| In reply to | #107947 |
On 6/28/2024 2:17 AM, Mikko wrote: > On 2024-06-27 17:07:20 +0000, olcott said: > >> Until you agree with this we cannot move on to the next >> and final point that proves I am correct. Proving that >> point may possibly take longer than the rest of my life >> so let's not delay this OK? >> >> [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 x86 emulator H0 cannot possibly return. > > If it is too hard to prove that H0 has the properties you claim > then an agreement is unlikely. Perhaps you should Δ instead and > just assume it has the properties you consider essential. The > full proof of your claim does not need much more. > It is not at all too hard to prove. It is easy to prove if you know, C, x86 emulators and the x86 language sufficiently well and impossible otherwise. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf _DDD() [00002172] 55 push ebp ; housekeeping [00002173] 8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push 00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) [0000217f] 83c404 add esp,+04 [00002182] 5d pop ebp [00002183] c3 ret Size in bytes:(0018) [00002183] The call from DDD to HHH(DDD) when N steps of DDD are correctly emulated by any pure function x86 emulator HHH cannot possibly return. The behavior of the directly executed DDD() is irrelevant because that is not the behavior of the input. Deciders compute the mapping from their actual finite string input to an output by a sequence of finite string transformations. In this case the sequence is the line-by-line execution trace of the behavior of DDD correctly emulated by HHH. The behavior of this input must include and cannot ignore the recursive emulation specified by the fact that DDD is calling its own emulator. That people think they can just pretend that this is not happening is ridiculous. -- 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-29 10:23 +0300 |
| Subject | Re: 197 page execution trace of DDD correctly simulated by HHH |
| Message-ID | <v5ocpr$3qno4$1@dont-email.me> |
| In reply to | #107973 |
On 2024-06-28 15:28:55 +0000, olcott said: > On 6/28/2024 2:17 AM, Mikko wrote: >> On 2024-06-27 17:07:20 +0000, olcott said: >> >>> Until you agree with this we cannot move on to the next >>> and final point that proves I am correct. Proving that >>> point may possibly take longer than the rest of my life >>> so let's not delay this OK? >>> >>> [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 x86 emulator H0 cannot possibly return. >> >> If it is too hard to prove that H0 has the properties you claim >> then an agreement is unlikely. Perhaps you should Δ instead and >> just assume it has the properties you consider essential. The >> full proof of your claim does not need much more. >> > > It is not at all too hard to prove. Then prove it. The following does not even mention H0 and therefore does not prove anything about it. > It is easy to prove > if you know, C, x86 emulators and the x86 language > sufficiently well and impossible otherwise. > > https://liarparadox.org/HHH(DDD)_Full_Trace.pdf > > _DDD() > [00002172] 55 push ebp ; housekeeping > [00002173] 8bec mov ebp,esp ; housekeeping > [00002175] 6872210000 push 00002172 ; push DDD > [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) > [0000217f] 83c404 add esp,+04 > [00002182] 5d pop ebp > [00002183] c3 ret > Size in bytes:(0018) [00002183] > > The call from DDD to HHH(DDD) when N steps of DDD are correctly > emulated by any pure function x86 emulator HHH cannot possibly return. The phrase "any pure function x86 emulator HHH" is incorrect. In particular, the word "any" is wrong. At 217a DDD calls 15d2 and that is the only call in DDD. The function at 15d2 either is or is not pure, we just don't konw as long as no proof is shown; and it either is ir is not a x86 emulator, we just don't as long as no proof is shown; and it ehither does or does not return, we just don't know as long as no proof is shown. It does not make sense to say "cannot": as long as you dont't prove that it does return and don't prove that it does not return the main point remains unproven. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-29 21:50 -0500 |
| Subject | Re: 197 page execution trace of DDD correctly simulated by HHH |
| Message-ID | <v5qh5o$aulp$2@dont-email.me> |
| In reply to | #107997 |
On 6/29/2024 2:23 AM, Mikko wrote: > On 2024-06-28 15:28:55 +0000, olcott said: > >> On 6/28/2024 2:17 AM, Mikko wrote: >>> On 2024-06-27 17:07:20 +0000, olcott said: >>> >>>> Until you agree with this we cannot move on to the next >>>> and final point that proves I am correct. Proving that >>>> point may possibly take longer than the rest of my life >>>> so let's not delay this OK? >>>> >>>> [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 x86 emulator H0 cannot possibly return. >>> >>> If it is too hard to prove that H0 has the properties you claim >>> then an agreement is unlikely. Perhaps you should Δ instead and >>> just assume it has the properties you consider essential. The >>> full proof of your claim does not need much more. >>> >> >> It is not at all too hard to prove. > > Then prove it. The following does not even mention H0 and therefore > does not prove anything about it. > >> It is easy to prove >> if you know, C, x86 emulators and the x86 language >> sufficiently well and impossible otherwise. >> >> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >> >> _DDD() >> [00002172] 55 push ebp ; housekeeping >> [00002173] 8bec mov ebp,esp ; housekeeping >> [00002175] 6872210000 push 00002172 ; push DDD >> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >> [0000217f] 83c404 add esp,+04 >> [00002182] 5d pop ebp >> [00002183] c3 ret >> Size in bytes:(0018) [00002183] >> >> The call from DDD to HHH(DDD) when N steps of DDD are correctly >> emulated by any pure function x86 emulator HHH cannot possibly return. > > The phrase "any pure function x86 emulator HHH" is incorrect. In > particular, > the word "any" is wrong. At 217a DDD calls 15d2 and that is the only call > in DDD. The function at 15d2 either is or is not pure, we just don't konw > as long as no proof is shown; < and it either is ir is not a x86 > emulator, we just don't as long as no proof is shown; and it ehither does > or does not return, we just don't know as long as no proof is shown. > It does not make sense to say "cannot": as long as you dont't prove that > it does return and don't prove that it does not return the main point > remains unproven. > In other words when HHH emulates the first four instructions of DDD and HHH is an x86 emulator you have no idea that the emulated HHH would emulate DDD again? -- 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-30 12:12 +0300 |
| Subject | Re: 197 page execution trace of DDD correctly simulated by HHH |
| Message-ID | <v5r7i1$euli$1@dont-email.me> |
| In reply to | #108023 |
On 2024-06-30 02:50:32 +0000, olcott said: > On 6/29/2024 2:23 AM, Mikko wrote: >> On 2024-06-28 15:28:55 +0000, olcott said: >> >>> On 6/28/2024 2:17 AM, Mikko wrote: >>>> On 2024-06-27 17:07:20 +0000, olcott said: >>>> >>>>> Until you agree with this we cannot move on to the next >>>>> and final point that proves I am correct. Proving that >>>>> point may possibly take longer than the rest of my life >>>>> so let's not delay this OK? >>>>> >>>>> [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 x86 emulator H0 cannot possibly return. >>>> >>>> If it is too hard to prove that H0 has the properties you claim >>>> then an agreement is unlikely. Perhaps you should Δ instead and >>>> just assume it has the properties you consider essential. The >>>> full proof of your claim does not need much more. >>>> >>> >>> It is not at all too hard to prove. >> >> Then prove it. The following does not even mention H0 and therefore >> does not prove anything about it. >> >>> It is easy to prove >>> if you know, C, x86 emulators and the x86 language >>> sufficiently well and impossible otherwise. >>> >>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>> >>> _DDD() >>> [00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping >>> [00002175] 6872210000 push 00002172 ; push DDD >>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>> [0000217f] 83c404 add esp,+04 >>> [00002182] 5d pop ebp >>> [00002183] c3 ret >>> Size in bytes:(0018) [00002183] >>> >>> The call from DDD to HHH(DDD) when N steps of DDD are correctly >>> emulated by any pure function x86 emulator HHH cannot possibly return. >> >> The phrase "any pure function x86 emulator HHH" is incorrect. In particular, >> the word "any" is wrong. At 217a DDD calls 15d2 and that is the only call >> in DDD. The function at 15d2 either is or is not pure, we just don't konw >> as long as no proof is shown; < and it either is ir is not a x86 >> emulator, we just don't as long as no proof is shown; and it ehither does >> or does not return, we just don't know as long as no proof is shown. >> It does not make sense to say "cannot": as long as you dont't prove that >> it does return and don't prove that it does not return the main point >> remains unproven. >> > > In other words when HHH emulates the first four instructions > of DDD and HHH is an x86 emulator you have no idea that the > emulated HHH would emulate DDD again? It is your HHH so you should present the idea and a proof. So far I only know that you have not proven anything about your HHH. But there are good reasons to expect that HHH does not do anything interesting. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-30 08:34 -0400 |
| Subject | Re: 197 page execution trace of DDD correctly simulated by HHH |
| Message-ID | <v5rjcr$1jcrr$3@i2pn2.org> |
| In reply to | #108023 |
On 6/29/24 10:50 PM, olcott wrote: > On 6/29/2024 2:23 AM, Mikko wrote: >> On 2024-06-28 15:28:55 +0000, olcott said: >> >>> On 6/28/2024 2:17 AM, Mikko wrote: >>>> On 2024-06-27 17:07:20 +0000, olcott said: >>>> >>>>> Until you agree with this we cannot move on to the next >>>>> and final point that proves I am correct. Proving that >>>>> point may possibly take longer than the rest of my life >>>>> so let's not delay this OK? >>>>> >>>>> [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 x86 emulator H0 cannot possibly return. >>>> >>>> If it is too hard to prove that H0 has the properties you claim >>>> then an agreement is unlikely. Perhaps you should Δ instead and >>>> just assume it has the properties you consider essential. The >>>> full proof of your claim does not need much more. >>>> >>> >>> It is not at all too hard to prove. >> >> Then prove it. The following does not even mention H0 and therefore >> does not prove anything about it. >> >>> It is easy to prove >>> if you know, C, x86 emulators and the x86 language >>> sufficiently well and impossible otherwise. >>> >>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>> >>> _DDD() >>> [00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping >>> [00002175] 6872210000 push 00002172 ; push DDD >>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>> [0000217f] 83c404 add esp,+04 >>> [00002182] 5d pop ebp >>> [00002183] c3 ret >>> Size in bytes:(0018) [00002183] >>> >>> The call from DDD to HHH(DDD) when N steps of DDD are correctly >>> emulated by any pure function x86 emulator HHH cannot possibly return. >> >> The phrase "any pure function x86 emulator HHH" is incorrect. In >> particular, >> the word "any" is wrong. At 217a DDD calls 15d2 and that is the only call >> in DDD. The function at 15d2 either is or is not pure, we just don't konw >> as long as no proof is shown; < and it either is ir is not a x86 >> emulator, we just don't as long as no proof is shown; and it ehither does >> or does not return, we just don't know as long as no proof is shown. >> It does not make sense to say "cannot": as long as you dont't prove that >> it does return and don't prove that it does not return the main point >> remains unproven. >> > > In other words when HHH emulates the first four instructions > of DDD and HHH is an x86 emulator you have no idea that the > emulated HHH would emulate DDD again? > Right, the EMULATED HHH emulated DDD (not again, as it wasn't the one that did the first one), the EMULATING HHH (the outer level) doesn't, but emulates HHH emulating DDD, which is different. You just can't keep two separate things seperate (the two instances of HHH), perhaps because of a severe mental deficiency in your brain.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-25 21:47 -0400 |
| Message-ID | <v5frvq$14bcm$8@i2pn2.org> |
| In reply to | #107787 |
On 6/25/24 9:12 AM, olcott wrote:
> 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.
In the section thaty was correctly simulated.
It can return after that point.
Aborted simulations do NOT stop the behavior represented by the input.
>
> Until you acknowledge this is true, this is the
> only thing that I am willing to talk to you about.
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-25 21:12 -0500 |
| Message-ID | <v5ftds$1uc3o$3@dont-email.me> |
| In reply to | #107825 |
On 6/25/2024 8:47 PM, Richard Damon wrote:
> On 6/25/24 9:12 AM, olcott wrote:
>> 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.
>
> In the section thaty was correctly simulated.
>
> It can return after that point.
>
> Aborted simulations do NOT stop the behavior represented by the input.
>
I am not even talking about termination analyzers.
Please do not deceptively twist my words. The entire
universe of discourse is DDD correctly simulated by H0.
I am beginning to think that you lack sufficient technical
competence. That is much better for you than lying.
--
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-25 22:20 -0400 |
| Message-ID | <v5fttt$14bcn$1@i2pn2.org> |
| In reply to | #107828 |
On 6/25/24 10:12 PM, olcott wrote:
> On 6/25/2024 8:47 PM, Richard Damon wrote:
>> On 6/25/24 9:12 AM, olcott wrote:
>>> 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.
>>
>> In the section thaty was correctly simulated.
>>
>> It can return after that point.
>>
>> Aborted simulations do NOT stop the behavior represented by the input.
>>
>
> I am not even talking about termination analyzers.
> Please do not deceptively twist my words. The entire
> universe of discourse is DDD correctly simulated by H0.
Which isn't a valid property\, since it is subjective.
The behavior of "the input" needs to be an OBJECTIVE property.
And if you are say we need to ignore what you have said in the past,
then h0 just neded to begin as:
int H0(ptr x) {
static int flag = 0;
if (flag) return 0;
flag = 1;
...
and it can do the simulation.
It seems you are incapable of learning.
>
> I am beginning to think that you lack sufficient technical
> competence. That is much better for you than lying.
>
No, you are just incompetent.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-25 20:44 +0000 |
| Message-ID | <v5fa6r$134dk$5@i2pn2.org> |
| In reply to | #107733 |
Am Mon, 24 Jun 2024 16:04:00 -0500 schrieb olcott: > On 6/24/2024 2:36 PM, joes wrote: >> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to >> simulate a function DD1 that only calls HH1? HH1 terminates, right? > I am going to have to go through my code and standardize my names. Yes, please. > 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. Can you explain them? -- 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-25 16:38 -0500 |
| Message-ID | <v5fdc5$1nsua$3@dont-email.me> |
| In reply to | #107814 |
On 6/25/2024 3:44 PM, joes wrote: > Am Mon, 24 Jun 2024 16:04:00 -0500 schrieb olcott: >> On 6/24/2024 2:36 PM, joes wrote: > >>> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to >>> simulate a function DD1 that only calls HH1? > HH1 terminates, right? > >> I am going to have to go through my code and standardize my names. > Yes, please. >> 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. > Can you explain them? > I can't do that now because I have to change too much of the code and I can't use the names that are in code in my paper because they are too complex. H0/H1 in my brand new paper are HHH/HHH1 in my code for input DDD. H in my paper is HH in my code, there is an HH1 in my code that is not referenced in my paper. There are a bunch of functions that use the 0,1,2 to mean number of parameters. -- 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:24 -0400 |
| Message-ID | <v5cv7m$10m6p$3@i2pn2.org> |
| In reply to | #107723 |
On 6/24/24 9:48 AM, olcott wrote: > 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) > Why? And why not show the actual trace that the decider makes, as opposed to the trace of the decider itself.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-30 12:30 +0300 |
| Message-ID | <v5r8kf$f4n6$1@dont-email.me> |
| In reply to | #107463 |
On 2024-06-20 00:00:48 +0000, olcott said: > https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf Contrary to the claime on the subject line, the trace in that file is only 159 pages long. In the beginning of the file there are other material, mainly translations of several functions, many of which do nothing. The trace does not show whether the emulation is correct because relevant register and memory contents are omitted. -- Mikko
[toc] | [prev] | [standalone]
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
Back to top | Article view | comp.theory
csiph-web