Re: DDD INcorrectly emulated by HHH is INCorrectly rejected as non-halting V2 ---woefully mistaken claims

On 7/25/24 8:53 PM, 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.
 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.
 

I think you need to decide if HHH knows that HHHHexists at the address or not. If it does, then it knows that if it aborts its emulation, the the copy would too, and thus is logic of infinite behavior is broken.
But it it doesn't, then it has no basis to not trace the instruction that the call targerts.

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.

But the "recursive simulation" is only finite, since HHH DOES abort.
Thus BOTH are given an input that if fully simulated would return, and thus aborting is not need, even though HHH decides to.
The fact that HHH and HHH1 don't do the same thing shows that they are NOT the same "computation" (or the computation includes some addition, and thus illegal, input).

 

>
_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

This is just NOT a correct x86 emulation of the call HHH1, which means this trace isn't anything that we have been talking about.

>
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

And this is not a correct emulation of the call HHH that HHH1 is emulationg, we need to see the code of HHH showing here.

>
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

As we need to see here.

[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

But since we know that HHH(DDD) does return, this is an incorrect deduction

>
[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
>

>
that seems to be a (partial) trace of HHH1(D).  It's not clear exactly what's happening - for example, who produces the message "Local Halt Decider: Infinite Recursion Detected Simulation Stopped"?  It might be outer HHH1 or one of the inner HHH's.  And what result did HHH1 report?
>

 It is supposed to be the outer most (thus directly executed) HHH.

Then why does it begin with a call to HHH1?
You clearly don't know what you are talking about.

 

And more to the point what did HHH(D) do, and what is the difference?
>

 *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.
 When a function unconditionally calls itself this is infinite
recursion.
 When a function unconditionally calls its own simulator this is
infinite recursive simulation. HHH sees this as infinite recursion
because HHH does not know that DDD is calling itself.

Nope, not if that simulator is conditional.

 

AND WHAT CODING within HHH/HHH1 ACCOUNTS FOR THAT DIFFERENCE?
>

You previously claimed that H and H1 behaviours were different as evidence that "copies of routines" don't necessarily produce the same behaviour as the original routine, due to magical pathelogical relationships.  But if the copies are done properly of course they will produce the same behaviour, because the x86 language is deterministic. I'm assuming you're not just cheating and using the mutable global data trick! or similar...
>

>
If you care study the code that I just provided
(and don't just ignore this and assume that I must be wrong)
you can see that when DDD is correctly emulated by HHH that
DDD does correctly have different behavior than DDD correctly
emulated by HHH1.

>
All I see above is a partial trace of HHH1(DDD).  No behaviour is traced for HHH1, and there is no comparison with HHH(DDD).
>

 If you simply freaking assume that both HHH and HHH1 are x86
emulators you don't really need to know one damn thing else
to know the key essence of what HHH and HHH1 does.
 

But that is a FALSE assumption which gets you into the trouble you are in.
They are CONDITIONAL emulators, and you need to take into account that conditionality. YOu are just admitting to lying to yourself.

Suggestion: make a post starting afresh with both traces, and a statement of how the behaviours differ,

 If you can't read annotated x86 code then you will never get it.
If can then you should have already gotten it three years ago yet
simply did not bother to pay attention.
 

But you still can't show a refference that says a call to HHH should show ANYTHING but the instructions of HHH being emulated.
Thus, proving yourself to be a pathological liar.