On 7/26/2024 3:50 AM, joes wrote:
Am Thu, 25 Jul 2024 23:25:59 -0500 schrieb olcott:
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:
(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.
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.
In this case we have two x86utm machines that are identical except
that DDD calls HHH and DDD does not call HHH1.
I don't see how the outside use of a function can influence it.
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.
Thanks, Mike, for the detailed analysis.
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.
How is the trace passed?
That does not matter. As long as we understand that Mike is correct about this:
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.
Then we know that HHH can see the the first four instructions of
DDD have no conditional code that could prevent them from endlessly
repeating.
This is the exact same pattern with Infinite_Recursion()
where there are no conditional branch instructions that
would prevent the first three instructions of
Infinite_Recursion() from endlessly repeating.
_Infinite_Recursion()
[0000215a] 55 push ebp
[0000215b] 8bec mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d pop ebp
[00002163] c3 ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation Execution Trace Stored at:113934
Decide_Halting_HH:1
[0000215a][00113924][00113928] 55 push ebp
[0000215b][00113924][00113928] 8bec mov ebp,esp
[0000215d][00113920][00002162] e8f8ffffff call 0000215a
[0000215a][0011391c][00113924] 55 push ebp
[0000215b][0011391c][00113924] 8bec mov ebp,esp
[0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
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.
I bet my nonexistent soul that there are bugs left in libx86. Apart
from that, your use of the library may be buggy.
That is irrelevant. We can see by the execution trace of
DDD emulated by HHH that this emulation does precisely
match the semantics of the first four x86 machine language
instructions of DDD.
We can also see that DDD emulated by HHH1 does precisely
match the semantics of the x86 machine language instructions
of DDD.
People have been saying that I am wrong about the for three
years never bothering to notice that I have always proved
that I am correct about this.
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.
How is it coded?
That does not matter as long as we understand that this:
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.
Proves that it is possible for the outer HHH to see the repeating
state of DDD then the details of how my HHH does this become moot.
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.)
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.
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.
But whyyy?
(a) Because people so stupidly assume that I must be wrong that
they make sure to not pay attention to the proof that I am correct?
(b) People don't have a clue about the semantics of the x86 language
and try to bluff using pure bluster.
Look, here is a rough sketch of the two traces side by side just done
by hand:
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.
No, 2+3 = 3+2. You have two copies of the same function that behave
differently. How is that possible?
Try to find one x86 instruction that is emulated incorrectly.
Can you please point us to where they diverge?
_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?
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.
_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.
I thought HHH aborts?
DDD correctly emulated by HHH exactly matches the following
infinite recursion behavior pattern where the first few
instructions repeat and have no conditional code within
them that prevents this from endlessly repeating.
Neither _Infinite_Recursion() nor DDD correctly
emulated by HHH can possibly reach their own "ret"
instructions thus never halt even though both of
them are forced to stop running.
_Infinite_Recursion()
[0000215a] 55 push ebp
[0000215b] 8bec mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d pop ebp
[00002163] c3 ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation Execution Trace Stored at:113934
Decide_Halting_HH:1
[0000215a][00113924][00113928] 55 push ebp
[0000215b][00113924][00113928] 8bec mov ebp,esp
[0000215d][00113920][00002162] e8f8ffffff call 0000215a
[0000215a][0011391c][00113924] 55 push ebp
[0000215b][0011391c][00113924] 8bec mov ebp,esp
[0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
-- Copyright 2024 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
…