Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Why do people here insist on denying these verified facts?
Date: Sat, 22 Jun 2024 13:13:09 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v570n5$onl4$11@i2pn2.org>
References: <v56n8h$3pr25$1@dont-email.me> <v56ntj$onl3$7@i2pn2.org>
 <v56ps2$3q4ea$1@dont-email.me> <v56sk3$p1du$2@i2pn2.org>
 <v56tfv$3ql1v$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 22 Jun 2024 17:13:09 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="810660"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v56tfv$3ql1v$2@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5812
Lines: 117

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