Deutsch   English   Français   Italiano  
<86986f5b07dfc95decf50e25ba47921eb348496e@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Simulation vs. Execution in the Halting Problem
Date: Wed, 11 Jun 2025 21:31:08 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <86986f5b07dfc95decf50e25ba47921eb348496e@i2pn2.org>
References: <yU0_P.1529838$4AM6.776697@fx17.ams4>
 <102c5nb$21qj7$2@dont-email.me>
 <602d915e3a80042ddac7f05fb389837ce3cefc12.camel@gmail.com>
 <102c7dj$226jq$1@dont-email.me>
 <0373fc8c6462341f655385edf6d4a0664a35981d.camel@gmail.com>
 <102ca1c$22pmt$1@dont-email.me>
 <85f876c4db96fb776dabc80c4208feed6aabc76d.camel@gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 12 Jun 2025 01:38:35 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="129875"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <102d082$28067$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US

On 6/11/25 6:33 PM, 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?
> It is for this same reason that the function's caller
> cannot simultaneously be its input.
> 

Not a valid comparison. After all, programs REGULARLY include code from 
their "parent" programs.

I guess you are just admitting that you don't understand the meaning of 
"all".

Sorry, you are just proving you are just a pathological liar.