Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: Why do people here insist on denying these verified facts?
Date: Sat, 22 Jun 2024 16:03:16 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <v56sk3$p1du$2@i2pn2.org>
References: <v56n8h$3pr25$1@dont-email.me> <v56ntj$onl3$7@i2pn2.org>
	<v56ps2$3q4ea$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 22 Jun 2024 16:03:16 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="820670"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3771
Lines: 59

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.

-- 
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik 
sind sie vollkommen nutzlos. --Wolfgang Mückenheim