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

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?

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.

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?

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?

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?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.