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

On 7/26/24 12:25 AM, olcott wrote:

On 7/25/2024 10:35 PM, Mike Terry wrote:

On 26/07/2024 01:53, olcott wrote:

On 7/25/2024 4:03 PM, Mike Terry wrote:

On 25/07/2024 14:56, olcott wrote:

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.

>
Perhaps your actual code does behave differently!
>

>
>
OK great, we are making headway.
>

The questions are:
a)  are HHH and HHH1 "identical copies", in the TM machine sense of incorporating
     the algorithm of one TM inside another TM?  (As Linz incorporates H
     inside H^, meaning that the behaviours of H and embedded_H MUST be identical for any
     input.)
     [You claim HHH and HHH1 /are/ proper copies, and yet give different results for
     input (D), which is impossible.]

>
They are identical in the that have identical x86 machine
code except for the x86 quirk that function calls are to
a relative rather than absolute address. So when HHH calls
the same function that HHH1 calls the machine code is not
the same.  The only other case where the machine code of
HHH1 and HHH is not identical is the way for slave instances
of HHH to pass its execution trace up to the master.

>
The relative addressing is to be expected as a difference, and is fine provided the actual target is the same. [Which it seems to be...]
>
The whole thing with the slave instances might well be where the bug lies!  That would be slightly funny, as I pointed out that problem on some completely unrelated post, and this could be a follow-on issue where it has caused observable misbehavior in the code.  (Needs a bit more investigation...)
>

 There never is any actual bug with the simulation.

That is just a LIE.

My system uses libx86emu with decades of development
experience. The current maintainer upgraded the system
to operate in 32-bit mode for me.

But you have added code that has bugs to it.
The instructions that it simulates, it does correctly, except for the fact that you stop the simulation.
Also, when it is ready to simulate the call instruction, you don't follow it simulation, but invent you own LIES about what that instruction will do.

 Whether or not my implementation of the decider portion is a
computable function is moot as long as some code can see the
repeating state behavior pattern that we can all see where
the first four lines of DDD emulated by HHH repeat.

Nope, since you have broken the simulation part, and don't let it just simulate, you whole program is buggy.

 

>
Although it seems that I have been correct all along about the
idea that slave instances can pass their execution trace up to
the master without breaking computability this is not the way
it has been actually encoded.
>
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
 >
 > Obviously a simulator has access to the internal state
 > (tape contents etc.) of the simulated machine. No problem there.
>
>

b)  If the two behaviours HHH/HHH1 are indeed different, WHAT precisely is the coding
     difference that accounts for that different behaviour?  (Like, with your H/H1 the
     difference was that H used H's address as part of its algorithm, while H1 used H1's
     address.)
>

>
*I have said this about 500 times in the last three years*
DDD calls HHH(DDD) in recursive simulation and does
not call HHH1(DDD) in recursive simulation.

>
You may have said it 500 times, but it doesn't answer my question!
>

 The problem is that the code itself has already answered this
question 500 times in three years and people just ignore it.

Nope, you have LIED that 500 times.

 Blah, Blah , Blah I know you must be wrong so I will not look
at anything that you say.

Nope, we point your error, and YOU ignord it

 When DDD emulated by HHH calls HHH(DDD) this call cannot possibly return. When DDD emulated by HHH1 calls HHH(DDD) this call DOES return.

Nope, you use of dishonest words just proves you are a liar.
It is the emulation of DDD by HHH that can not reach the return.
The full behavior of the DDD (that happens to be partially observed by HHH's emulation of it) does reach that point.

 I have showed this 500 times with H(D,D) and H1(D,D) or with
H(P,P) and H1(P,P).

Nope, just repeated your lies.

 

Look, here is a rough sketch of the two traces side by side just done by hand:
>
[VIEW WITH FIXED FONT!!]
>
   HHH1 (DDD)                          HHH (DDD)
   -----------------------------------------------------------------
1 main ()                             main ()
2   HHH1 (DDD)                          HHH (DDD)
4     Simulate (DDD)                      Simulate (DDD)
5     | DDD()                             | DDD()
6     |   HHH (DDD)                       |   HHH (DDD)
7     |     Simulate (DDD)                |     Simulate (DDD)
8     |     | DDD()                       |       DDD()
9     |     |   HHH (DDD)                 |         HHH (DDD)
10    |     |     Simulate (DDD)          Abort
11    |     |       DDD()                 ret 0
12    |     |         HHH (DDD)         ret 0
13    |     Abort
14    |     ret 0
15    |   ret
16    ret 1
17  ret 0
>
So HHH/HHH1 behaviour is different, but shouldn't be if HHH1 is a correct copy of HHH.
>

 And by your same reasoning 2 + 3 shouldn't = 5.
Try to find one x86 instruction that is emulated incorrectly.

Noope, you just show that your logic is broken.

 _DDD()
[00002177] 55         push ebp
[00002178] 8bec       mov ebp,esp
[0000217a] 6877210000 push 00002177 ; push DDD
[0000217f] e853f4ffff call 000015d7 ; call HHH
[00002184] 83c404     add esp,+04
[00002187] 5d         pop ebp
[00002188] c3         ret
 Maybe you think that push 00002177 should jmp 00002188?

No, only you might say that.
Why does your "Call 000015d7" not go to 000015d7"
Until you answer that, you are just admitting to the whole world you are a liar.
YOu claim you emulation follows the semantics of the x86, and then don't follow that definition.
YOU LIE.  PERIOD.

 

Your explanation makes NO SENSE AT ALL.  It's just one of those things you repeat 500 times, and nobody bothers to call you out.
>

 When people disagree with the semantics of the x86 instructions
that is no actual rebuttal at all and merely proves their own
technical incompetence.

No, YOU DISAGREE.  Call 000015d7 must go to 000015d7, not "create a new stack frame" at a totally new memory address.

 

You say DDD calls HHH(DDD) in recursive simulation and does not call HHH1 in recursive simulation.
>

 Right and 2 + 3 = 5.

and call HHH goes into HHH.

 

Well that's correct [lines 6,9,12] - but it's irrelevant, because IT'S THE SAME ON BOTH SIDES ABOVE.  Both HHH/HHH1 simulate DDD [line 4] and BOTH of those simulations call HHH in recursive simulation, so BOTH SIDES MUST HAVE THE SAME BEHAVIOUR.
>

 In other words you are totally incompetent with the x86
language or disagree with this language.
 

No, you are. CALL Instructions are followed by the code of the subroutine called.

when the instruction says mov eax, 5
and you "interpret" that add edx, 10 YOU ARE WRONG

No, when the instruction says CALL HHH, you think it means start an immulation of the program at the top of the stack.

 _DDD()
[00002177] 55         push ebp
[00002178] 8bec       mov ebp,esp
[0000217a] 6877210000 push 00002177 ; push DDD
[0000217f] e853f4ffff call 000015d7 ; call HHH
 DDD emulated by HHH endlessly repeats as if it was infinite
recursion such that DDD emulated by HHH cannot possibly reach
past 0000217f no matter what HHH does.

Nope, because HHH aborts its emulation and returns to it.
Thus every DDD gets there, it is only the PARTIAL emulation of HHH that doesn't see that.

 *This version is better annotated*
Because I have repeated this same point 500 times in the last three years...
 

You are just learning to lie better, but you are still wrong, and still lying.
My guess is you are going to be stuck doing this for eternity.