Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.logic > #335726 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-06-19 19:00 -0500 |
| Last post | 2024-06-25 16:38 -0500 |
| Articles | 20 on this page of 113 — 5 participants |
Back to article view | Back to sci.logic
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 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: 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: 197 page execution trace of DDD correctly simulated by HHH Richard Damon <richard@damon-family.org> - 2024-06-30 08:34 -0400
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 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
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 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 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
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-21 15:11 -0400 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v54j99$lkkc$10@i2pn2.org> |
| In reply to | #335788 |
On 6/21/24 2:51 PM, olcott wrote: > On 6/21/2024 1:39 PM, Richard Damon wrote: >> On 6/21/24 2:22 PM, olcott wrote: >>> On 6/21/2024 1:00 PM, Richard Damon wrote: >>>> On 6/21/24 1:55 PM, olcott wrote: >>>>> On 6/21/2024 12:40 PM, Richard Damon wrote: >>>>>> On 6/21/24 1:22 PM, olcott wrote: >>>>>>> >>>>>>> When there is no mapping from the finite string x86 machine >>>>>>> language input to H(D,D) to the behavior of D(D) then >>>>>>> H(D,D) IS NOT being asked about the behavior of D(D). >>>>>> >>>>>> But there *IS* a mapping, it just isn't a COMPUTABLE MAPPING. >>>>>> >>>>> >>>>> If there is a mapping yet not a computable mapping then >>>>> the actual halt decider cannot even see the question that >>>>> the textbooks expect it to see. >>>> >>>> But a decider doesn't "See" the question. it just computes the >>>> result it was programmed to give. >>>> >>> >>> It must be the behavior that the input finite string actually specifies. >>> It cannot be the behavior that the programmer imagines that it >>> specifies. >>> >> >> But strings don't "have" behavior, or even "specify" behavior by >> themselves, the behavior comes from applying the string to the >> DEFINITION of the problem. >> > > In this case the definition of the x86 language specifies > the behavior of DDD. If you deny this then you are a liar. But only when the problem statement says the byte string is to be interpreded as x86 code. > > No matter how much textbooks expect that the input to HH0(DDD) > does not specify recursive simulation their counter-factual > expectations are refuted. Nope. Just more of your lies. Maybe it specifies FINITELY recursive simulation because HH0 will abort its simulation. Anything else is just counter factual to the actual behavior of the FULL input. Of course, if you keep on insisting that you input is JUST what you show, I will point out that your problem is just INVALID as the byte sequence alone does NOT actually specify the behavior of the program, as it goes into territory with no defined values. That is like asking for "the sum of 2 and" (and then not giving the rest of the input), > > _DDD() > [00002093] 55 push ebp > [00002094] 8bec mov ebp,esp > [00002096] 6893200000 push 00002093 ; push DDD > [0000209b] e853f4ffff call 000014f3 ; call HH0 > [000020a0] 83c404 add esp,+04 > [000020a3] 5d pop ebp > [000020a4] c3 ret > Size in bytes:(0018) [000020a4] > > It is as if you have been indoctrinated like the > Moonies: (cult members must be deprogrammed) > https://en.wikipedia.org/wiki/Unification_Church > I understand the Moonies, YOU are the one that has been brainwashed, and it seems you did it to yourself.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-21 14:23 -0500 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v54jvd$3a7vo$2@dont-email.me> |
| In reply to | #335791 |
On 6/21/2024 2:11 PM, Richard Damon wrote: > On 6/21/24 2:51 PM, olcott wrote: >> On 6/21/2024 1:39 PM, Richard Damon wrote: >>> On 6/21/24 2:22 PM, olcott wrote: >>>> On 6/21/2024 1:00 PM, Richard Damon wrote: >>>>> On 6/21/24 1:55 PM, olcott wrote: >>>>>> On 6/21/2024 12:40 PM, Richard Damon wrote: >>>>>>> On 6/21/24 1:22 PM, olcott wrote: >>>>>>>> >>>>>>>> When there is no mapping from the finite string x86 machine >>>>>>>> language input to H(D,D) to the behavior of D(D) then >>>>>>>> H(D,D) IS NOT being asked about the behavior of D(D). >>>>>>> >>>>>>> But there *IS* a mapping, it just isn't a COMPUTABLE MAPPING. >>>>>>> >>>>>> >>>>>> If there is a mapping yet not a computable mapping then >>>>>> the actual halt decider cannot even see the question that >>>>>> the textbooks expect it to see. >>>>> >>>>> But a decider doesn't "See" the question. it just computes the >>>>> result it was programmed to give. >>>>> >>>> >>>> It must be the behavior that the input finite string actually >>>> specifies. >>>> It cannot be the behavior that the programmer imagines that it >>>> specifies. >>>> >>> >>> But strings don't "have" behavior, or even "specify" behavior by >>> themselves, the behavior comes from applying the string to the >>> DEFINITION of the problem. >>> >> >> In this case the definition of the x86 language specifies >> the behavior of DDD. If you deny this then you are a liar. > > But only when the problem statement says the byte string is to be > interpreded as x86 code. > Yeah maybe the programmer meant it to be interpreted as a recipe for spaghetti sauce. In this case the programmer 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-21 15:54 -0400 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v54lq6$lkkc$11@i2pn2.org> |
| In reply to | #335793 |
On 6/21/24 3:23 PM, olcott wrote: > On 6/21/2024 2:11 PM, Richard Damon wrote: >> On 6/21/24 2:51 PM, olcott wrote: >>> On 6/21/2024 1:39 PM, Richard Damon wrote: >>>> On 6/21/24 2:22 PM, olcott wrote: >>>>> On 6/21/2024 1:00 PM, Richard Damon wrote: >>>>>> On 6/21/24 1:55 PM, olcott wrote: >>>>>>> On 6/21/2024 12:40 PM, Richard Damon wrote: >>>>>>>> On 6/21/24 1:22 PM, olcott wrote: >>>>>>>>> >>>>>>>>> When there is no mapping from the finite string x86 machine >>>>>>>>> language input to H(D,D) to the behavior of D(D) then >>>>>>>>> H(D,D) IS NOT being asked about the behavior of D(D). >>>>>>>> >>>>>>>> But there *IS* a mapping, it just isn't a COMPUTABLE MAPPING. >>>>>>>> >>>>>>> >>>>>>> If there is a mapping yet not a computable mapping then >>>>>>> the actual halt decider cannot even see the question that >>>>>>> the textbooks expect it to see. >>>>>> >>>>>> But a decider doesn't "See" the question. it just computes the >>>>>> result it was programmed to give. >>>>>> >>>>> >>>>> It must be the behavior that the input finite string actually >>>>> specifies. >>>>> It cannot be the behavior that the programmer imagines that it >>>>> specifies. >>>>> >>>> >>>> But strings don't "have" behavior, or even "specify" behavior by >>>> themselves, the behavior comes from applying the string to the >>>> DEFINITION of the problem. >>>> >>> >>> In this case the definition of the x86 language specifies >>> the behavior of DDD. If you deny this then you are a liar. >> >> But only when the problem statement says the byte string is to be >> interpreded as x86 code. >> > > Yeah maybe the programmer meant it to be interpreted > as a recipe for spaghetti sauce. In this case the > programmer IS WRONG !!! > And thus the program isn't a halt decider. Remember, the DEFINITION of the operation the input specifies is deteremened by the problem the program is claimed to be solving. It seems, you just don't understand what DEFINITIONS are, so I guess all your claims about True by the meaning of the words are just lies too,
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-25 20:31 +0000 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5f9fh$134dk$3@i2pn2.org> |
| In reply to | #335777 |
Am Fri, 21 Jun 2024 12:22:04 -0500 schrieb olcott: > On 6/21/2024 12:09 PM, Richard Damon wrote: >> On 6/21/24 1:04 PM, olcott wrote: >>> On 6/21/2024 10:25 AM, Richard Damon wrote: >>>> On 6/21/24 10:44 AM, olcott wrote: >>>>> On 6/21/2024 9:02 AM, Richard Damon wrote: >>>>>> On 6/21/24 9:01 AM, olcott wrote: >>>>>>> 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: >>>>>>>>>> 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. >>>> First, NO ONE has said that *H* (or what every you are calling your >>>> decider today) can correct simulate the input to a final state. > When there is no mapping from the finite string x86 machine language > input to H(D,D) to the behavior of D(D) then H(D,D) IS NOT being asked > about the behavior of D(D). It means that H can't do the mapping, i.e. it is not simulating correctly. It does a different map that doesn't fit its specification. > Not even being asked about the behavior of D(D) is not the same > situation as: > the logical impossibility of specifying a halt decider H that correctly > reports the halt status of input D that is defined to do the opposite of > whatever value that H reports. > Of course this is impossible. Thank you. So what are we arguing about? >> Nothing says that the decider has to actually be ABLE to answer the >> question, only that the answer exists. Uncomputable problems just can't >> be solved with a computation. QFT -- 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:22 -0500 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5fce0$1nsua$1@dont-email.me> |
| In reply to | #335986 |
On 6/25/2024 3:31 PM, joes wrote: > Am Fri, 21 Jun 2024 12:22:04 -0500 schrieb olcott: >> On 6/21/2024 12:09 PM, Richard Damon wrote: >>> On 6/21/24 1:04 PM, olcott wrote: >>>> On 6/21/2024 10:25 AM, Richard Damon wrote: >>>>> On 6/21/24 10:44 AM, olcott wrote: >>>>>> On 6/21/2024 9:02 AM, Richard Damon wrote: >>>>>>> On 6/21/24 9:01 AM, olcott wrote: >>>>>>>> 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: > >>>>>>>>>>> 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. > >>>>> First, NO ONE has said that *H* (or what every you are calling your >>>>> decider today) can correct simulate the input to a final state. > >> When there is no mapping from the finite string x86 machine language >> input to H(D,D) to the behavior of D(D) then H(D,D) IS NOT being asked >> about the behavior of D(D). > It means that H can't do the mapping, i.e. it is not simulating correctly. > It does a different map that doesn't fit its specification. > No that is incorrect. D correctly simulated by every H that can possibly exist does not have the same behavior of any directly executed D(D) that halts. If I ask you: What time is it? How do you know that my actual question is what are you planning on having for dinner? -- 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 21:47 -0400 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5frvp$14bcm$7@i2pn2.org> |
| In reply to | #335989 |
On 6/25/24 5:22 PM, olcott wrote: > On 6/25/2024 3:31 PM, joes wrote: >> Am Fri, 21 Jun 2024 12:22:04 -0500 schrieb olcott: >>> On 6/21/2024 12:09 PM, Richard Damon wrote: >>>> On 6/21/24 1:04 PM, olcott wrote: >>>>> On 6/21/2024 10:25 AM, Richard Damon wrote: >>>>>> On 6/21/24 10:44 AM, olcott wrote: >>>>>>> On 6/21/2024 9:02 AM, Richard Damon wrote: >>>>>>>> On 6/21/24 9:01 AM, olcott wrote: >>>>>>>>> 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: >> >>>>>>>>>>>> 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. >> >>>>>> First, NO ONE has said that *H* (or what every you are calling your >>>>>> decider today) can correct simulate the input to a final state. >> >>> When there is no mapping from the finite string x86 machine language >>> input to H(D,D) to the behavior of D(D) then H(D,D) IS NOT being asked >>> about the behavior of D(D). > >> It means that H can't do the mapping, i.e. it is not simulating >> correctly. >> It does a different map that doesn't fit its specification. >> > > No that is incorrect. D correctly simulated by every H that can > possibly exist does not have the same behavior of any directly > executed D(D) that halts. > > If I ask you: What time is it? > How do you know that my actual question is > what are you planning on having for dinner? > > Nope, it has EXACTLY the same behavior as the simulation did, and then it continues to the return. Aborted simulation do not indicate behavior of the input after the point of aborting, so you can't validly say that the behavior of the input is that it will never return, just that it DIDN'T return by the point that the simulation was aborted. KEY DIFFERENCE.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-26 08:11 +0000 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5gig3$158st$1@i2pn2.org> |
| In reply to | #335989 |
Am Tue, 25 Jun 2024 16:22:08 -0500 schrieb olcott: > On 6/25/2024 3:31 PM, joes wrote: >> Am Fri, 21 Jun 2024 12:22:04 -0500 schrieb olcott: >>> When there is no mapping from the finite string x86 machine language >>> input to H(D,D) to the behavior of D(D) then H(D,D) IS NOT being asked >>> about the behavior of D(D). >> It means that H can't do the mapping, i.e. it is not simulating >> correctly. >> It does a different map that doesn't fit its specification. > No that is incorrect. D correctly simulated by every H that can possibly > exist does not have the same behavior of any directly executed D(D) that > halts. H1 simulates D the same way it would actually behave. Is that wrong? -- 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 08:32 -0500 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v5h59i$24jbd$8@dont-email.me> |
| In reply to | #336015 |
On 6/26/2024 3:11 AM, joes wrote: > Am Tue, 25 Jun 2024 16:22:08 -0500 schrieb olcott: >> On 6/25/2024 3:31 PM, joes wrote: >>> Am Fri, 21 Jun 2024 12:22:04 -0500 schrieb olcott: > >>>> When there is no mapping from the finite string x86 machine language >>>> input to H(D,D) to the behavior of D(D) then H(D,D) IS NOT being asked >>>> about the behavior of D(D). >>> It means that H can't do the mapping, i.e. it is not simulating >>> correctly. >>> It does a different map that doesn't fit its specification. >> No that is incorrect. D correctly simulated by every H that can possibly >> exist does not have the same behavior of any directly executed D(D) that >> halts. > H1 simulates D the same way it would actually behave. Is that wrong? > When H1 simulates D there is no recursive simulation because D calls H(D,D) and does not call H1(D,D). When H simulates D there IS recursive simulation because D calls H(D,D) and does not call H1(D,D). -- 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-22 11:27 +0200 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v565d9$3mg7e$1@dont-email.me> |
| In reply to | #335763 |
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?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-22 08:11 -0500 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v56iht$3or0r$4@dont-email.me> |
| In reply to | #335815 |
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. -- 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-22 09:38 -0400 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v56k4h$onl4$4@i2pn2.org> |
| In reply to | #335821 |
On 6/22/24 9:11 AM, olcott wrote: > 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. > The problem is that the "behavior" that the finite string DDD presents to HH0, is DEFINED by the problem. And if that problem is the Halting Problem, that behavior is the behavior of the machine the input represents. If HH0 treats the input as having a different behavior, then HH0 just isn't a Halting Decider, but something else. If HH0 is supposed to be a Halting decider, but uses a method that makes it see something other than that behavior, then it is just an incorrect Halting Decider, and its algorithm just creates an incorrect recreation of the property of the input it is supposed to be working on. A bit of a side note, the actual "Input" to HH0, is a pointer to memory, and as such it passes a reference to ALL of memory considering the starting point to be that address, so your "Input" isn't actually the few bytes of DDD, but ALL of memory and a starting point. If you actually mean that the input is just those few bytes pointed to by the address, then the input is improperly formed and is NOT a proper representation of the input machine, becuase it is incomplete. The fact you don't understand this, seems to imply you are lacking the basic knowledge to be talking about this sort of thing.
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-22 14:41 +0000 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v56nr7$ov4f$2@i2pn2.org> |
| In reply to | #335821 |
Am Sat, 22 Jun 2024 08:11:25 -0500 schrieb 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: >> 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. Why are you changing the topic here? > 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. DDD by itself always specifies the same behaviour. A better phrasing would be that the different H's execute it differently; so at least one of them must be wrong. > I don't get why people here insist on lying about verified facts. They are not true, let alone proven. -- Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik sind sie vollkommen nutzlos. --Wolfgang Mückenheim
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-22 10:53 -0400 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v56oha$onl4$9@i2pn2.org> |
| In reply to | #335834 |
On 6/22/24 10:41 AM, joes wrote: > Am Sat, 22 Jun 2024 08:11:25 -0500 schrieb 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: > >>> 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. > Why are you changing the topic here? > >> 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. > > DDD by itself always specifies the same behaviour. A better phrasing would > be that the different H's execute it differently; so at least one of them > must be wrong. Actually, that is part of his problem. He doesn't pin down the behavior of DDD, as it depends on the behavior of HH0, which he won't pin down, as he things that can be variable depending on what he wants. This is where the non-sense of "an infinite set of decider-input pairs" comes form, which just means he has left the logic of normal programming theory. For us to ask a decider about an input program, it needs to be A PROGRAM, which means that DDD needs to be tied to a SPECIFIC HH0 with specific behavior. This means that when he talks about "NO HH0 can ..." it is just double talk that means "HH0 doesn't. ...", since at that point HH0 must be a single defined machine, and DDD fixed to using that single defined machine. Which is also why his description of the input is incorrect, you can't just list the x86 code of DDD, as it, by reference, includes all the code of HH0, which by his other publications comes out to about 33 pages of code, and even that has some routines stubbed out. So, he fundamentally is confusing what he is talking about, not knowing what a "program" actually is, and what we can ask a Halting decider to decide on. > >> I don't get why people here insist on lying about verified facts. > They are not true, let alone proven. >
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-06-22 20:50 +0200 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v576d7$3sg5p$2@dont-email.me> |
| In reply to | #335821 |
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'. Your wishes are irrelevant. The simulation of DDD by HH0 does not return, because it was aborted prematurely. HH0 aborts after N levels of recursive simulation, but it simulates only N-1 levels of recursive simulation of itself. So, the abort is one level too soon. Why do you insist that N is infinite? Don't you see that the input that DDD presents is independent to whom it is presented? Of course, you will not try to find errors in what I say, in order to protect yourself against not finding any error. Probably, you will just repeat an old baseless claim.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-22 13:53 -0500 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v576k6$3soh6$3@dont-email.me> |
| In reply to | #335851 |
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(). -- 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-22 15:22 -0400 |
| Subject | Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply |
| Message-ID | <v578a9$onl3$16@i2pn2.org> |
| In reply to | #335852 |
On 6/22/24 2:53 PM, olcott wrote: > 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(). > By a strict interpreation of your measure, this input has UNDEFIINED BEHAVIOR, so it is improper to ask about it. The problem is the input DDD doesn't have all its x86 code defined, as it call a function not defined in its code. When we include the contents of the all the memory, so we can correctly simulate the input, then the two "Correct Simulations" of H0 and H1 will be exactly IDENTICAL to each other up to the point that H0 stops simulatng, so all H0 can say is that it doesn't know the halting behavior of its input. And you still need to properly define POOPing to know if it is correct for that, it might be, but we need the definitions,
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-22 14:45 -0500 |
| Subject | DDD correctly emulated by H0 |
| Message-ID | <v579lm$3t97b$2@dont-email.me> |
| In reply to | #335859 |
On 6/22/2024 2:22 PM, Richard Damon wrote: > On 6/22/24 2:53 PM, olcott wrote: >> On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >>> Op 22.jun.2024 om 15:11 schreef olcott: >>>> >>>> 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(). >> > > By a strict interpreation of your measure, this input has UNDEFIINED > BEHAVIOR, so it is improper to ask about it. > That is a stupid thing to say. The behavior of THE INPUT is specified by the semantics of the x86 programming language. -- 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-22 16:10 -0400 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <v57b2q$onl3$19@i2pn2.org> |
| In reply to | #335862 |
On 6/22/24 3:45 PM, olcott wrote: > On 6/22/2024 2:22 PM, Richard Damon wrote: >> On 6/22/24 2:53 PM, olcott wrote: >>> On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >>>> Op 22.jun.2024 om 15:11 schreef olcott: >>>>> >>>>> 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(). >>> >> >> By a strict interpreation of your measure, this input has UNDEFIINED >> BEHAVIOR, so it is improper to ask about it. >> > > That is a stupid thing to say. The behavior of THE INPUT > is specified by the semantics of the x86 programming language. > Right, so what does a call to a location of memory that doesn't exist do?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-22 19:01 -0500 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <v57ok9$5d7$3@dont-email.me> |
| In reply to | #335866 |
On 6/22/2024 3:10 PM, Richard Damon wrote: > On 6/22/24 3:45 PM, olcott wrote: >> On 6/22/2024 2:22 PM, Richard Damon wrote: >>> On 6/22/24 2:53 PM, olcott wrote: >>>> On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >>>>> Op 22.jun.2024 om 15:11 schreef olcott: >>>>>> >>>>>> 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(). >>>> >>> >>> By a strict interpreation of your measure, this input has UNDEFIINED >>> BEHAVIOR, so it is improper to ask about it. >>> >> >> That is a stupid thing to say. The behavior of THE INPUT >> is specified by the semantics of the x86 programming language. >> > > Right, so what does a call to a location of memory that doesn't exist do? Liar 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] -- 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-22 20:14 -0400 |
| Subject | Re: DDD correctly emulated by H0 |
| Message-ID | <v57pcq$onl3$21@i2pn2.org> |
| In reply to | #335869 |
On 6/22/24 8:01 PM, olcott wrote: > On 6/22/2024 3:10 PM, Richard Damon wrote: >> On 6/22/24 3:45 PM, olcott wrote: >>> On 6/22/2024 2:22 PM, Richard Damon wrote: >>>> On 6/22/24 2:53 PM, olcott wrote: >>>>> On 6/22/2024 1:50 PM, Fred. Zwarts wrote: >>>>>> Op 22.jun.2024 om 15:11 schreef olcott: >>>>>>> >>>>>>> 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(). >>>>> >>>> >>>> By a strict interpreation of your measure, this input has UNDEFIINED >>>> BEHAVIOR, so it is improper to ask about it. >>>> >>> >>> That is a stupid thing to say. The behavior of THE INPUT >>> is specified by the semantics of the x86 programming language. >>> >> >> Right, so what does a call to a location of memory that doesn't exist do? > > Liar How is a QUESTION a LIE? I guess you feel it must be because I put you on the spot about your deciet in your framing of the problem. > > 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. > > _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]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | sci.logic
csiph-web