Deutsch   English   Français   Italiano  
<utff3t$1lqsm$5@dont-email.me>

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

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: immibis <news@immibis.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: Proof that H(D,D) meets its abort criteria --induction criteria--
Date: Wed, 20 Mar 2024 20:57:49 +0100
Organization: A noiseless patient Spider
Lines: 160
Message-ID: <utff3t$1lqsm$5@dont-email.me>
References: <ut1sgk$2buev$2@dont-email.me> <ut8cju$27bqa$8@i2pn2.org>
 <ut8e9k$8nr$1@dont-email.me> <ut8gic$27bqb$9@i2pn2.org>
 <ut8go9$l2l$2@dont-email.me> <ut8ide$27bqb$10@i2pn2.org>
 <ut8j23$t3b$3@dont-email.me> <ut8lhu$27bqa$10@i2pn2.org>
 <ut9k08$7i77$1@dont-email.me> <ut9li5$7pdg$1@dont-email.me>
 <ut9ufd$9qc8$2@dont-email.me> <uta5j7$b8d6$1@dont-email.me>
 <uta7n9$c11s$1@dont-email.me> <uta88f$c3ln$1@dont-email.me>
 <uta8rr$c91o$1@dont-email.me> <utaam1$ckrm$1@dont-email.me>
 <utab3j$cn6l$2@dont-email.me> <utac8g$csl0$1@dont-email.me>
 <utacqt$d328$1@dont-email.me> <utau6c$2b09e$10@i2pn2.org>
 <utb28m$ksn2$1@dont-email.me> <utb40e$2be23$1@i2pn2.org>
 <utb4pf$lati$1@dont-email.me> <utciqf$uvmo$1@dont-email.me>
 <utcklk$v0lj$7@dont-email.me> <utf1so$2gfo0$1@i2pn2.org>
 <utf2sl$1j44f$1@dont-email.me> <utf907$2gfnv$3@i2pn2.org>
 <utfa95$1l0lp$1@dont-email.me> <utfcci$1li0p$2@dont-email.me>
 <utfcq0$1le3h$2@dont-email.me> <utfdmn$1lqsm$2@dont-email.me>
 <utfe9t$1lpkq$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 20 Mar 2024 19:57:49 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="da785b61b8e9246896df1af5aa1fe2de";
	logging-data="1764246"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19g6ogU6B2o2B2OcTiqM8Xf"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:K5CIBbmJctT1SPSYH8ZutSKP44c=
Content-Language: en-US
In-Reply-To: <utfe9t$1lpkq$3@dont-email.me>
Bytes: 8353

On 20/03/24 20:43, olcott wrote:
> On 3/20/2024 2:33 PM, immibis wrote:
>> On 20/03/24 20:18, olcott wrote:
>>> On 3/20/2024 2:11 PM, Fred. Zwarts wrote:
>>>> Op 20.mrt.2024 om 19:35 schreef olcott:
>>>>> On 3/20/2024 1:13 PM, Richard Damon wrote:
>>>>>> On 3/20/24 12:29 PM, olcott wrote:
>>>>>>> On 3/20/2024 11:12 AM, Richard Damon wrote:
>>>>>>>> On 3/19/24 2:14 PM, olcott wrote:
>>>>>>>>> On 3/19/2024 12:42 PM, immibis wrote:
>>>>>>>>>> On 19/03/24 05:37, olcott wrote:
>>>>>>>>>>> You are just getting nutty now. You are tossing out the 
>>>>>>>>>>> sequence, selection, iteration model of computation.
>>>>>>>>>>
>>>>>>>>>> aren't you tossing out the turing machine model of computation?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am only tossing out the halting problem specification.
>>>>>>>>> I am not saying (like Richard is saying) that sequential
>>>>>>>>> code can be executed out-of-sequence.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Just more of your lies.
>>>>>>>>
>>>>>>>> Where did I say "Sequential Code" can run out-of-sequence.
>>>>>>>>
>>>>>>>>
>>>>>>>> THe codes that I talk about not being in the sequence you think 
>>>>>>>> are two INDEPENDENT copies of the machines.
>>>>>>>>
>>>>>>>
>>>>>>> The one that is called first is executed first.
>>>>>>
>>>>>> And I never denied that.
>>>>>>
>>>>>> But H(D,D) doesn't "Call" D(D), it simulates it.
>>>>>>
>>>>>
>>>>> Thus the steps of D(D) simulated by H come after H(D,D)
>>>>> is executed, they do not occur in parallel at the same time.
>>>>>
>>>>>> The D(D) that it simulates is a machine that has already been 
>>>>>> "run", since Turing Machines are FULL computation devices that run 
>>>>>> their procesisng as soon as they are created.
>>>>>>
>>>>>
>>>>> In some strawman deception argument the steps of D(D) come
>>>>> before H(D,D) is executed.
>>>>>
>>>>>> This seems something you don't understand, because you seem to 
>>>>>> think that D(D) doesn't actually "run" until it is simulated.
>>>>>>
>>>>>
>>>>> The steps of the simulated D(D) are never run, they are only 
>>>>> simulated.
>>>>> In a strawman deception argument the steps of D(D) are executed before
>>>>> the steps of H(D,D).
>>>>>
>>>>>>>
>>>>>>>> The H that is deciding the D(D) does not enforce that the ACTUAL 
>>>>>>>> D(D) it is simulating has not been run yet, and in fact, since 
>>>>>>>> we can consider Turing Machines to "auto-start" once created, it 
>>>>>>>> is IMPOSSIBLE to give to H a description of a D(D) that has not 
>>>>>>>> already run itself.
>>>>>>>>
>>>>>>> The one that is called first is executed first.
>>>>>>
>>>>>> So?
>>>>>>
>>>>>
>>>>> You tried to get away with saying otherwise.
>>>>>
>>>>>> Where does H call D(D)? It SIMULATES it.
>>>>>>
>>>>>> You seem to think that simulation is the exact same thing as 
>>>>>> EXECUTION.
>>>>>>
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not 
>>>>>>> halt
>>>>>>>
>>>>>>> Ĥ ⟨Ĥ⟩ is executed before Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ thus the executed Ĥ ⟨Ĥ⟩ is
>>>>>>> run before the simulated one. When Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ simulates its input
>>>>>>> it can see that it must abort this simulation.
>>>>>>
>>>>>> Yes H^ (H^) is executed before H^.H (H^) (H^) but the instance of 
>>>>>> the machine represented by that input was executed when it was 
>>>>>> created, so has already run.
>>>>>>
>>>>> Unless you are trying to get away with rejecting the sequence of
>>>>> sequence, selection, iteration you already know that Ĥ ⟨Ĥ⟩ is always
>>>>> executed before Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>>> Again, you are confusing the simulation that H, or H^.H does, with 
>>>>>> the axtual execution of them.
>>>>>>
>>>>>> You could even look at the simulation of H^.H as telling H part of 
>>>>>> what this H^ (H^) has alteady done.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> We, as finite humans may not know what it did, but the 
>>>>>>>> mathematical world of truth does.
>>>>>>>>
>>>>>>>
>>>>>>> Mathematical induction proves that after N steps of correct 
>>>>>>> simulation
>>>>>>> H correctly determines that ∞ steps of correct simulation would 
>>>>>>> never
>>>>>>> halt. *These are verified facts that you perpetually deny*
>>>>>>
>>>>>> NOPE.
>>>>>>
>>>>>> STATE YOUR INDUCTION CRITERIA and their proof
>>>>>>
>>>>>
>>>>> As soon as H(D,D) sees that D calls itself with its same inputs
>>>>> and there are no conditional branch instructions from the
>>>>> beginning of D to its call to H(D,D) then H knows that its
>>>>> simulated D(D) cannot possibly reach its own final instruction
>>>>> (at line 06) in any finite number of steps of correct simulation.
>>>>
>>>> An infinite recursion could be detected if a program comes back at 
>>>> the same place in the same state. In this case the beginning of D 
>>>> and the call to H are not the same place within the program. What 
>>>> Olcott means, but does not say, is that the call from D to H causes 
>>>> the program to arrive at a similar place in a similar state as when 
>>>> H (not D) started. But now we see that there are conditional branch 
>>>> instructions between these two places, namely within H, which may 
>>>> cause an end of the recursion. In fact, it is known that the 
>>>> recursion is not infinite, but does end, because H aborts and returns.
>>>
>>> There are no conditional branch instructions that allow
>>> the simulated D(D) to reach its own final state and halt.
>>
>> There is a conditional branch instruction which causes the simulated 
>> H(D,D) to reach its final state and return 0. However, 
> 
>> the simulation of H(D,D) is aborted before the simulated H(D,D) 
>> reaches this instruction.
>>
> 
> That proves a lack of sufficient software engineering skills.
> What are your programming skills?
> 
> I have been a professional developer since 1984 and a professional
> C++ software engineer since 2000.

Ad hominem deception rejected.

> 
>>>
>>> In fact neither the simulated D(D) nor the executed H(D,D) can
>>> possibly stop running unless the executed H(D,D) aborts its
>>> simulation without waiting for any simulated H(D,D) to do this.
>>>
>>
>