Re: DDD correctly emulated by HHH is Correctly rejected as non-halting V2 ---woefully mistaken rebuttal

Op 25.jul.2024 om 20:45 schreef olcott:

On 7/25/2024 11:06 AM, Mike Terry wrote:

On 25/07/2024 15:27, Fred. Zwarts wrote:

Op 25.jul.2024 om 15:56 schreef olcott:

On 7/24/2024 10:29 PM, Mike Terry wrote:

On 23/07/2024 14:31, olcott wrote:

On 7/23/2024 1:32 AM, 0 wrote:

On 2024-07-22 13:46:21 +0000, olcott said:
>

On 7/22/2024 2:57 AM, Mikko wrote:

On 2024-07-21 13:34:40 +0000, olcott said:
>

On 7/21/2024 4:34 AM, Mikko wrote:

On 2024-07-20 13:11:03 +0000, olcott said:
>

On 7/20/2024 3:21 AM, Mikko wrote:

On 2024-07-19 14:08:24 +0000, olcott said:
>

When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.

>
You and your HHH can reason or at least conclude correctly about
Infinite_Loop but not about DDD. Possibly because it prefers to
say "no", which is correct about Infinte_loop but not about DDD.
>

>
*Because this is true I don't understand how you are not simply lying*
int main
{
   DDD();
}
>
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.

>
You are the lying one.
>
If HHH(DDD) abrots its simulation and returns true it is correct as a
halt decider for DDD really halts.
>

>
(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within.

>
No, we don't. There is no such prohibition.
>

>
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.

>
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation,
which only cares about certain properties of Turing machines.
>

Therefore It is not allowed to report on its own behavior.

>
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
>

Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.

>
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
>

In this case we have two x86utm machines that are identical
except that DDD calls HHH and DDD does not call HHH1.
>
It is empirically proven that this changes their behavior
and the behavior of DDD.
>

>
You say a lot about things that are "empirically proven" and without exception they are never "proven" at all.
>

>
It is empirically proven according to the semantics of the
x86 machine code of DDD that DDD correctly emulated by HHH
has different behavior than DDD correctly emulated by HHH1.

>
No, you have proven that the *simulation* is different, not that the behaviour of the simulated function is different.
The simulations differ, because one is correct and the other one is incorrect.
The one that skips x86 instructions (by aborting) does not follow the semantics of the x86 language. Its simulation is incomplete and therefore is wrong.

>
But the point is that PO alleges HHH and HHH1 are identical copies.  If that were the case, why would one abort while the other does not?
>

 I explain that most completely by providing the full execution trace.
I have done that many times over the last three years. You are so
sure that I must be incorrect that you don't bother to examine this
trace that has consistently proven that I am correct for three years.
 

The answer is obviously that they are NOT proper copies, just like PO's earlier H/H1.  Or PO has cheated with misuse of global variables or similar.  (PO has previously insisted these functions are "pure", but that is probably his own wishful thinking rather than fact... so who knows?)
>

 If you understand the semantics of the x86 language then you
can see that N instructions of DDD are correctly emulated by
HHH.

You would also see that HHH skips M instructions of the X86 code, when it aborts. That makes the simulation incomplete and incorrect. It has been pointed out many times that the semantics of the x86 language does not allow skipping instructions and then claim that it will still show the behaviour of the program.

You can also see by the repeating state of DDD correctly
emulated by HHH that HHH must abort it emulation of DDD or
DDD and HHH would never terminate.

And when it aborts, it aborts too soon, because one cycle later the simulated HHH would abort and halt, so the abort by the simulating HHH was premature.
It is clear that HHH cannot possibly simulate itself correctly, because the simulated HHH runs one cycle behind the simulating HHH. The simulating HHH, when it aborts, always one cycle too soon.

  From understanding the semantics of the x86 language you can
also see that after HHH(DDD) has aborted the emulation of its
input that the correct emulation of a different process instance
of DDD by HHH1 does terminate normally.

Yes. HHH1 does a correct simulation of an incorrect simulation by HHH.
DDD is a misleading and unneeded complication. It is easy to eliminate DDD:
        int main() {
          return HHH(main);
        }
This has the same problem. This proves that the problem is not in DDD, but in HHH, which halts when it aborts the simulation, but it decides that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.

 

I would like PO to come clean and explain why HHH1 behaves differently to HHH, in terms of the actual code.  Instead he just says stuff like "HHH1 does not /need/ to abort because [blah blah]", as though he believes program behaviour is determined by their "needs" rather than by their coding.
>
This is a perfectly "concrete" problem - two bits of code behave differently; why?  Even PO should be able to properly understand (and investigate by himself) the answer to this question.  Instead he falls back on nonsense "magical" explanations based on the programs "understanding their needs" or "seeing things" they obviously /don't/ "see" [either literally or figuratively], and somehow changing their behaviour as a result.
>
Mike.
>

 typedef void (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
 void DDD()
{
   HHH(DDD);
}
 int main()
{
   HHH1(DDD);
}
 _DDD()
[00002177] 55         push ebp
[00002178] 8bec       mov ebp,esp
[0000217a] 6877210000 push 00002177
[0000217f] e853f4ffff call 000015d7
[00002184] 83c404     add esp,+04
[00002187] 5d         pop ebp
[00002188] c3         ret
Size in bytes:(0018) [00002188]
 _main()
[00002197] 55         push ebp
[00002198] 8bec       mov ebp,esp
[0000219a] 6877210000 push 00002177
[0000219f] e863f3ffff call 00001507
[000021a4] 83c404     add esp,+04
[000021a7] 33c0       xor eax,eax
[000021a9] 5d         pop ebp
[000021aa] c3         ret
Size in bytes:(0020) [000021aa]
   machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[00002197][001037fb][00000000] 55         push ebp
[00002198][001037fb][00000000] 8bec       mov ebp,esp
[0000219a][001037f7][00002177] 6877210000 push 00002177 ; push DDD
[0000219f][001037f3][000021a4] e863f3ffff call 00001507 ; call HHH1
New slave_stack at:10389f
 Begin Local Halt Decider Simulation   Execution Trace Stored at:1138a7
[00002177][00113897][0011389b] 55         push ebp
[00002178][00113897][0011389b] 8bec       mov ebp,esp
[0000217a][00113893][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0011388f][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:14e2c7
 Begin Local Halt Decider Simulation   Execution Trace Stored at:15e2cf
[00002177][0015e2bf][0015e2c3] 55         push ebp
[00002178][0015e2bf][0015e2c3] 8bec       mov ebp,esp
[0000217a][0015e2bb][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0015e2b7][00002184] e853f4ffff call 000015d7 ; call HHH
New slave_stack at:198cef
[00002177][001a8ce7][001a8ceb] 55         push ebp
[00002178][001a8ce7][001a8ceb] 8bec       mov ebp,esp
[0000217a][001a8ce3][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][001a8cdf][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

This is the error in HHH. It is coded to print an erroneous remark about an infinite recursion when it has seen only two recursions and aborts and halts. One cycle later the simulated HHH would halt by its own, but the simulating HHH is programmed to not try another cycle.
HHH is simply unable to decide about finite recursions.
void Finite_Recursion (int N) {
   if (N > 0) Finite_Recursion (N - 1);
}
It does not see the difference between a finite recursion and an infinite recursion.

 [00002184][00113897][0011389b] 83c404     add esp,+04
[00002187][0011389b][000015bc] 5d         pop ebp
[00002188][0011389f][0003a980] c3         ret
[000021a4][001037fb][00000000] 83c404     add esp,+04
[000021a7][001037fb][00000000] 33c0       xor eax,eax
[000021a9][001037ff][00000018] 5d         pop ebp
[000021aa][00103803][00000000] c3         ret
Number of Instructions Executed(352831) == 5266 Pages
 I just proved that DDD correctly emulated by HHH does
have non-terminating behavior that HHH aborts and DDD
correctly emulated by HHH1 does terminate.

No, you have not even shown a correct simulation of HHH by itself. Since there is no correct simulation, the proof is missing. Only HHH1 does a correct simulation, which proves that a correct simulation HHH (and DDD) do terminate.

 If you "disagree" with this proof on the basis that
(a) You do not know the x86 language well enough
(b) Did not bother to carefully examine the steps

Since there is no proof, this is incorrect. Your claim is based on a erroneous understanding of the x86 language, as if it allows the skipping of instructions to determine the behaviour of a program.

 then your "disagreement" would be a reckless disregard of the truth.
 2 : a reckless lack of attention to the truth that misleads or deceives another
https://dictionary.findlaw.com/definition/reckless-disregard-of-the-truth.html
 

I know that olcott will not understand the logic of what I say, but I find his psychology intriguing.
He misses the mental intelligence to even consider the possibility that there is an error in his ideas. If it is proved to him that such an error is present, he does not bother (or is blocked) to think about it, because is unable to accept it. But he needs an excuse to ignore the proofs presented by several people. His only way to come away with it, is by saying that other people do not speak the truth, i.e. are lying. Maybe he really believes that, when he does not understand those proofs and keeps convinced that there is no error in his ideas.
He does not understand that no matter how much olcott wants it to be correct, or how many times olcott repeats that it is correct, it does not change the fact that such a simulation is incorrect.
Therefore he simply keeps repeating his claims without any evidence, or with evidence that has already been proved to be wrong many times.
He keeps begging for support, even when almost everyone understands that there is no hope to prove something correct when it has been proven incorrect.