Re: Why Peter Olcott is both right and wrong

Op 16.mei.2025 om 17:30 schreef olcott:

On 5/16/2025 1:52 AM, Mikko wrote:

On 2025-05-15 15:13:50 +0000, olcott said:
>

On 5/15/2025 1:27 AM, Mr Flibble wrote:

Peter is right to say that the halting problem as defined is flawed: he
agrees with me that there is category error at the heart of the problem
definition whereby the decider is conflated with the program being
analysed in an ill-formed self-referential dependency that manifests in
his simulating halt decider as "aborted" infinite recursion.
>
Peter however is wrong to say that aborting his infinite recursion is
equivalant to a halting state of non-halting: the truth is pathlogical
input is undecidable: that part Turing et al got right.
>
/Flibble

>
Introduction to the Theory of Computation 3rd Edition
by Michael Sipser (Author)
4.4 out of 5 stars    568 ratings
>
https://www.amazon.com/Introduction-Theory-Computation-Michael- Sipser/ dp/113318779X

>
Nothing on that page supports any of your claims in any way.
>

 *It establishes Professor Sipser as a qualified authority*
(an appeal to a qualified authority is not an inductive error)
 

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then
>
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

>
Nothing above supports any of your claims.
>

 Mike explains all of the details of how the
above quote does derive a correct Simulating Halt Decider.
 On 5/14/2025 7:36 PM, Mike Terry wrote:
 > There is a natural (and correct) statement that Sipser
 > is far more likely (I'd say) to have agreed to.
 >
 > First you should understand the basic idea behind a
 > "Simulating Halt Decider" (*SHD*) that /partially/
 > simulates its input, while observing each simulation
 > step looking for certain halting/non-halting patterns
 > in the simulation. A simple (working) example here
 > is an input which goes into a tight loop.
(Mike says much more about this)
 *Click here to get the whole article*
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
 Message-ID: <1003cu5$2p3g1$1@dont-email.me>
 

HHH does correctly reject DDD and DD according
to the exact meaning of the above words. It also
seems to me that those words are a truism.

>
HHH does indeed reject DDD and DD but the use of the word "correctly"
is not justified. HHH does not correctly determine that its
simulated D would never stop running unless aborted.
>

 It easier to see this with DDD;
 void DDD()
{
   HHH(DDD);
   return;
}
 HHH simulates DDD
The simulated DDD calls HHH(DDD)
The simulated HHH simulates DDD
The simulated DDD calls HHH(DDD)
The simulated HHH simulates DDD
The simulated DDD calls HHH(DDD)
The simulated HHH simulates DDD
The simulated DDD calls HHH(DDD)

Counterfactual. The HHH you published aborts after one cycle.
If this input is not changed, the end of the simulation would be reached after two cycles.
But you confused yourself, by changing the input when you change your HHH. Changing the input is not allowed.

 How many recursive simulations are needed
before you get the idea that DDD correctly
simulated by HHH
 *would never stop running unless aborted*
 

It is aborted, so it does stop.