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: Wed, 11 Jun 2025 19:52:03 -0500
Organization: A noiseless patient Spider
Lines: 161
Message-ID: <102d8bk$29pam$1@dont-email.me>
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>
 <ce43ca906ca40618fefd39f3fe2388b099bff58b.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 12 Jun 2025 02:52:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9f0ba097a1221e597ea76cc26b2e661a";
	logging-data="2418006"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19brHXJlilUYalVR9a2i+ry"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/6hkbJr6/sCQZZg/ul4WEhLKwWs=
Content-Language: en-US
X-Antivirus-Status: Clean
In-Reply-To: <ce43ca906ca40618fefd39f3fe2388b099bff58b.camel@gmail.com>
X-Antivirus: Norton (VPS 250611-4, 6/11/2025), Outbound message

On 6/11/2025 7:34 PM, wij wrote:
> On Wed, 2025-06-11 at 19:20 -0500, olcott wrote:
>> 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:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yes all other people (especially Dennis Bush) are saying
>>>>>>>>>>>>>>>>>>>> that H(D) is required to report on the behavior of the
>>>>>>>>>>>>>>>>>>>> direct execution of D() never noticing that this stupidly
>>>>>>>>>>>>>>>>>>>> requires H(D) to report on the behavior of its caller.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If the H above means the H that the HP refers to. The H is
>>>>>>>>>>>>>>>>>>> required to
>>>>>>>>>>>>>>>>>>> report its argument's behavior (ie. by H(D)). But NOT required by
>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The HP does not care what D does (simply to say).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Everyone says that H(D) must re[port on the behavior of
>>>>>>>>>>>>>>>>>> the direct execution of D().
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That is what the HP asks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The HP only requires: H(D)==1 iff D() halts
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>             D(); // calls H(D)
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Which requires H(D) to report on the behavior of its
>>>>>>>>>>>>>>>>>> caller instead of reporting on the behavior that its
>>>>>>>>>>>>>>>>>> input actually specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That is no problem. H does not care what D does inside (simply to
>>>>>>>>>>>>>>>>> say).
>>>>>>>>>>>>>>>>> The HP simply asks for a H that "H(D)==1 iff D() halts".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which requires H to report on something that it cannot possibly see.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On the contrary, what the HP proves is very useful.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am not talking about the halting problem, I have always
>>>>>>>>>>>>>> been talking about the conventional halting problem proof.
>>>>>>>>>>>>>> THIS PROOF IS WRONG
>>>>>>>>>>>>>
>>>>>>>>>>>>> When talking about proof, we say it is valid or not. By doing so, we have
>>>>>>>>>>>>> to unambiguously pose the problem and the derivation to the conclusion.
>>>>>>>>>>>>> The HP proof just did that.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It may seem that way if you pay less than 100%
>>>>>>>>>>>> complete attention.
>>>>>>>>>>>>
>>>>>>>>>>>> The HP proof depends on an *INPUT* that does
>>>>>>>>>>>> the opposite of whatever value that H returns
>>>>>>>>>>>> and no such *INPUT* can possibly exist.
>>>>>>>>>>>
>>>>>>>>>>> That is absolutely correct. No such *INPUT* (i.e. D) can possible exit is because
>>>>>>>>>>> the H inside D does not exist at all.
>>>>>>>>>>> So, if the H is assumed to exist, then D will exist to make H undecidable.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There is no *input* to any termination analyzer
>>>>>>>>>> that can do the opposite of whatever value that
>>>>>>>>>> this termination analyzer returns
>>>>>>>>>
>>>>>>>>> Your reinterpretation of of HP case is wrong.
>>>>>>>>> Your D or H is not the case mention in the HP proof.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There cannot possibly exist any D mine or
>>>>>>>> anyone else's that is encoded to do the opposite
>>>>>>>> of whatever value that H returns.
>>>>>>>
>>>>>>> Why not? D and H are supposed to be TM (or C function).
>>>>>>> If the D cannot do the opposite of whatever value that H returns, then
>>>>>>> that D is not powerful enough to be a TM, not an interesting case.
>>>>>>>
>>>>>>
>>>>>> Can you be your biological mother's biological father?
>>>>>
>>>>> What is the same reason? What's the relationship of 1+1=2 relates to HP?
>>>>>
>>>>>> It is for this same reason that the function's caller
>>>>>> cannot simultaneously be its input.
>>>>>
>>>>> D and H belong to the same set of TM equivalent stuff.
>>>>
>>>> Yes and we have the exact same issue with TM's it
>>>> is merely more difficult to see.
>>>>
>>>> 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.
>>>
>>> The problem is that you don't know TM and C as 1-year CS student does.
>>> All the people here have problem to get the answer fits your level of understanding.
>>>
>>>>> D has to be able to perform exactly H's function (if D is a TM and if H exists).
>>>>> Otherwise, that D is not the counter-example mentioned in the HP proof.
>>>>>
>>>> I have to covered too. Unless you understand that
>>>> D cannot be both an input to H and its caller there
>>>> is no sense going there.
>>>
>>> If it (D) cannot be both an input to H and its caller, that D is no resemble of
>>> the counter-example mentioned in the HP proof. You made a crippled D.
>>>
>>>
>>
>> No D that anyone in the universe can define
>> can simultaneously be the caller of a function
>> and the input to the same function.
> 
> Then, what does your example mean?
> 
> void D() {
>    H(D);
> }
> 
> D cannot simultaneously be the caller of a function
> and the input to the same function?
> Are you refuting what you said?
> 

If you don't understand the difference between object
instances of OOP classes and the classes themselves
then you might not understand.

int main()
{
   D(); // calls H(D) and the parameter to this H(D)
}      // is not the caller of this instance of H(D)


========== REMAINDER OF ARTICLE TRUNCATED ==========