Re: Why do people here insist on denying these verified facts?

On 6/26/24 8:53 AM, olcott wrote:

On 6/26/2024 2:54 AM, Mikko wrote:

On 2024-06-25 13:19:46 +0000, olcott said:
>

On 6/25/2024 4:48 AM, Mikko wrote:

On 2024-06-24 14:03:12 +0000, immibis said:
>

On 24/06/24 15:50, olcott wrote:

On 6/24/2024 2:32 AM, Mikko wrote:

On 2024-06-23 13:23:10 +0000, olcott said:
>

On 6/23/2024 4:42 AM, Mikko wrote:

When the head line has the words "these verified facts" the message should
first tell what facts are "these verified facts" and who verified them
before any further discussion.
>

>
It is a verified fact that 2 + 3 = 5 according to the semantics
of arithmetic. Anyone having an opinion that contradicts this is WRONG.

>
Sure, but that was not the first thing mentioned in the initial message.
>

>
>
int P(ptr2 x)
{
  int Halt_Status = H(x, x);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
>
The call from P to H(P,P) when P is correctly emulated
by H cannot possibly return.
>
The call from P to H(P,P) when P is correctly emulated
by H1 DOES return.
>
>

>
Verified fact: the emulation is incorrect

>
But which emulation? By H or by H1?
>

>
Both of them are correct.
Because P never calls H1(P,P) and P does call H(P,P)
the call from P to H(P,P) returns in the first case
and cannot possibly return in the second case.

>
Obviously false. The meaning of H(P,P) is determined by the text of H.
The meaning is fully determined by the complier that complies to the
x86 code and the semantics of x86. If one simulator interpretes the
x86 code differently from another simulator then one of them does not
follow the x86 semantics and is therefore incorrect.

By that logic, ALL deciders are "Correct" as they answer what they answer. That seems to be the sort of logic system you want.
What H is SUPPOSED to do, and the meaning of the input to H, is determined by the SPECIFICATION of H.

>

 _DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]
 The call from DDD to
the x86 emulator H0(DDD) at machine address 0000217a
when DDD is correctly emulated by H0 cannot possibly return.

And "Correct Emulation" of an input is only really correct if carried to completion, because that IS the semantics of the x86 instruction set. Otherwise it is just a PARTIAL emulation.

 When DDD is correctly emulated by H0 then H0 must emulate itself
emulating DDD. This derives recursive emulation.

So, is H0 defined to be an UNCONDITIONAL emulator, or are you going to claim at some point that it can stop and still meet its requirements.

 When DDD is correctly emulated by H1 then H1 NEED NOT emulate itself
emulating DDD. This DOES NOT derive recursive emulation.

But, if H0 never stops emulating its input, then H1 will never reach the end either.
So, if H1 can see an end, then H0 MUST have returned. If H0 didn't see that in its emulation, it must have aborted it too soon.

 *You probably lack suffcient technical competence*
 

YOU clearly don't have the needed technical competence.