| Deutsch English Français Italiano |
|
<102f055$2ohps$11@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Simulation vs. Execution in the Halting Problem
Date: Thu, 12 Jun 2025 11:44:21 -0500
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <102f055$2ohps$11@dont-email.me>
References: <yU0_P.1529838$4AM6.776697@fx17.ams4>
<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>
<a2c82f9e0c497289a73c604f39c50b226fa29dda@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Jun 2025 18:44:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9f0ba097a1221e597ea76cc26b2e661a";
logging-data="2901820"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ybXJgwLdW2KB5XjUAKMwb"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:OoYvi3WDvCqAwxuey/awrWeJL2c=
X-Antivirus: Norton (VPS 250612-2, 6/12/2025), Outbound message
In-Reply-To: <a2c82f9e0c497289a73c604f39c50b226fa29dda@i2pn2.org>
Content-Language: en-US
X-Antivirus-Status: Clean
On 6/12/2025 11:22 AM, joes wrote:
> 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?
No you are wrong.
I have proven this too many times, you just aren't bright enough.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH cannot possibly reach its own
simulated "return" statement final halt state. If you think
that it can that only proves your lack of sufficient technical
competence.
> 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?
>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer