Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: Simulation vs. Execution in the Halting Problem
Date: Thu, 12 Jun 2025 16:22:42 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <a2c82f9e0c497289a73c604f39c50b226fa29dda@i2pn2.org>
References: <yU0_P.1529838$4AM6.776697@fx17.ams4>
	<102cdon$23jal$1@dont-email.me>
	<2e40a87aeb9e28ce23b5ebf3fcbf23dad6728a9b.camel@gmail.com>
	<102cg6f$246h5$1@dont-email.me>
	<822e204898d419545ca400a9088970f0b6a5107f.camel@gmail.com>
	<102ckje$25dg0$2@dont-email.me>
	<c5adb4ff9ac0a31da990ff83ab1ef7f242a2f7a7.camel@gmail.com>
	<102cm0u$25dg0$3@dont-email.me>
	<610e2a54b66e8576b80bda3a0fe188d025b9798e.camel@gmail.com>
	<102cp0e$26clp$1@dont-email.me>
	<d4b02c8deb6dd72c7bf143b07c2752d93b825b1d.camel@gmail.com>
	<102crbv$26rt0$1@dont-email.me>
	<ade2f19a880169bbaf09794b496e585b7eb8b677.camel@gmail.com>
	<102ctbg$26rt0$2@dont-email.me>
	<f09964feafdca25ea8efbe546868084bcd9df3a0.camel@gmail.com>
	<102d082$28067$1@dont-email.me>
	<a480d0b388903cc2c039fb39792007fc8c88841f.camel@gmail.com>
	<102d4fa$291mi$1@dont-email.me>
	<27181e2fc0e06453f53994e2a92e3a5c8808e581.camel@gmail.com>
	<102d6ge$29fp7$1@dont-email.me>
	<c060351cc5556e7d383b48eae51c3ccfacdb6fd4@i2pn2.org>
	<102esp9$2ohps$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 12 Jun 2025 16:22:42 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="214065"; 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

Am Thu, 12 Jun 2025 10:46:48 -0500 schrieb olcott:
> On 6/12/2025 3:50 AM, joes wrote:
>> Am Wed, 11 Jun 2025 19:20:30 -0500 schrieb olcott:
>>> On 6/11/2025 7:03 PM, wij wrote:
>>>> On Wed, 2025-06-11 at 18:45 -0500, olcott wrote:
>>>>> On 6/11/2025 6:25 PM, wij wrote:
>>>>>> On Wed, 2025-06-11 at 17:33 -0500, olcott wrote:
>>>>>>> On 6/11/2025 4:57 PM, wij wrote:
>>>>>>>> On Wed, 2025-06-11 at 16:44 -0500, olcott wrote:
>>>>>>>>> On 6/11/2025 4:23 PM, wij wrote:
>>>>>>>>>> On Wed, 2025-06-11 at 16:10 -0500, olcott wrote:
>>>>>>>>>>> On 6/11/2025 3:59 PM, wij wrote:
>>>>>>>>>>>> On Wed, 2025-06-11 at 15:30 -0500, olcott wrote:
>>>>>>>>>>>>> On 6/11/2025 2:45 PM, wij wrote:
>>>>>>>>>>>>>> On Wed, 2025-06-11 at 14:39 -0500, olcott wrote:
>>>>>>>>>>>>>>> On 6/11/2025 2:31 PM, wij wrote:
>>>>>>>>>>>>>>>> On Wed, 2025-06-11 at 14:14 -0500, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/11/2025 1:25 PM, wij wrote:
>>>>>>>>>>>>>>>>>> On Wed, 2025-06-11 at 12:59 -0500, olcott wrote:
>> 
>>>>>>>>>>>>>>>>>>> It turns out that no one ever noticed that simulating
>>>>>>>>>>>>>>>>>>> halt deciders nullify the HP counter-example input in
>>>>>>>>>>>>>>>>>>> that this input cannot possibly reach its
>>>>>>>>>>>>>>>>>>> contradictory part.
>> 
>> DDD does reach that part; HHH doesn't. When HHH simulates DDD, DDD is
>> not running (on the processor), it is passive data executed by HHH.
>> 
>>>>>>>>>>>>>>>>>>> Which requires H(D) to report on the behavior of its
>>>>>>>>>>>>>>>>>>> caller instead of reporting on the behavior that its
>>>>>>>>>>>>>>>>>>> input actually specifies.
>> 
>> What do you mean by "actually specifies"?
>> 
>>>>>>>>> There cannot possibly exist any D mine or anyone else's that is
>>>>>>>>> encoded to do the opposite of whatever value that H returns.
>> 
>> What does your DDD do? Do as HHH says?
>> 
>>>>> I am not going to get into that until after you totally understand
>>>>> this at the C level. I am unwilling to talk about this endlessly in
>>>>> circles.
>> lol.
>> 
>>> No D that anyone in the universe can define can simultaneously be the
>>> caller of a function and the input to the same function.
>>> If you think that it can then provide such a D.
>> 
>> Oh, how you are wrong. It is an elementary part of CS that data can be
>> interpreted as code and code has a data representation.
> 
> int main()
> {
>    DDD(); // calls HHH(DDD) its parameter is not its caller
> }
I mean... yes, it is? Unless your execution environment allows assigning
different things the same name, DDD refers to exactly one function at
one address. Why don't you say that you mean the specific invocation at
this point in the call stack?

And what about the rest of my reply above and what you snipped?

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