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

On 6/22/24 12:18 PM, olcott wrote:

On 6/22/2024 11:03 AM, joes wrote:

Am Sat, 22 Jun 2024 10:16:18 -0500 schrieb olcott:

On 6/22/2024 9:42 AM, Richard Damon wrote:

On 6/22/24 10:31 AM, olcott wrote:

>

The D(D) that calls H(D,D) such that this call returns has provably
different behavior than D correctly simulated by H is measured by the
actual semantics of the x86 programming language.

[s/is/as?]
No, H of course needs to simulate the call to itself like any other.
x86 has nothing to do with that. A correct simulation has identical
behaviour to the real thing. Why should H simulate something that is
not its input?
>

The input is the finite string.
The MEANING of that finite string is defined by the PROBLEM.

Yes, DDD is coded to call the HHH0 deciding on it.

LIAR. You know that the meaning of the finite string is defined by the
semantics of the x86 language.

>

As Christ said as ye judge ye shall be judged so I do wish the same
thing upon myself. If I am on the wrong path then I sincerely wish for
the minimum adversity required to definitely set me on the right path.

Thanks for the permission. Your minimum seems to be quite high.
Not sure I want to fulfill your wishes.
>

Halting DEFINES the meaning/behavior to be that of the directly run
program represented by the input.

That makes it contradict one of its own axioms, thus conclusively
proving that it is incorrect:

WTF? What contradiction? How can "halting" even be incorrect?
>

The problem is that the "behavior" that the finite string DDD presents
to HH0, is DEFINED by the problem.

LIAR. It is defined by the semantics of the x86 language.

This is just silly. The x86 code of DDD is defined to call HH0.
>

And if that problem is the Halting Problem, that behavior is the
behavior of the machine the input represents. If HH0 treats the input
as having a different behavior, then HH0 just isn't a Halting Decider,
but something else.
If HH0 is supposed to be a Halting decider, but uses a method that
makes it see something other than that behavior, then it is just an
incorrect Halting Decider, and its algorithm just creates an incorrect
recreation of the property of the input it is supposed to be working
on.

Exactly. Like you say, it must follow the semantics of its input.
>

The input to HHH0(DDD) includes itself.
The input to HHH1(DDD) DOES NOT include itself.

Yes, both include HHH0. The second case is boring.
>

DDD correctly emulated by HHH0 correctly determines that the call from
the emulated DDD to HHH0 DOES NOT RETURN.

*incorrectly

DDD correctly emulated by HHH1 correctly determines that the call from
the emulated DDD to HHH0 DOES RETURN.

>

 void DDD()
{
   HHH0(DDD);
}
 The input to HHH0(DDD) includes itself.
The input to HHH1(DDD) DOES NOT include itself.
 It is stipulated that correct emulation is defined by the
semantics of the x86 programming language and nothing else.

And thus, your emulation traces show that your "Simulating Halt Deciders" do not do a "Correct Simulation" as the ONLY correct simulation of the call instruction is the simulitation of the instructions of the routine called, which is NOT what you show.
So, YOU FIL.

 DDD correctly emulated by HHH0 correctly determines that
the call from the emulated DDD to HHH0 DOES NOT RETURN.

But doesn't "Correctly Emulate" the input, so it claim is just invalid.

 DDD correctly emulated by HHH1 correctly determines that
the call from the emulated DDD to HHH0 DOES RETURN.
 The fact that DDD calls HHH0(DDD) and does not call HHH1(DDD)
changes the behavior of DDD correctly emulated by HHH0 relative
to DDD correctly emulated by HHH1.

Nope.
The correct emulation of the exact same code will always be the same.
What instruction was correctly emulated, be the intel x86 instruction specification that differed between the two emulations.
They say EXACTLY the same instruction sequence,
Your inability to answer this quesiton just shows that you are nothing but a pathetic ignorant pathological lying idiot.

 _DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]