Deutsch   English   Français   Italiano  
<100k1h4$2o767$1@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: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: Mike Terry Proves --- How the requirements that Professor Sipser agreed to are exactly met
Date: Wed, 21 May 2025 11:05:56 +0300
Organization: -
Lines: 106
Message-ID: <100k1h4$2o767$1@dont-email.me>
References: <1005jsk$3akrk$1@dont-email.me> <bc6f0f045212bdfb7f7d883426873a09e37789ea@i2pn2.org> <1005u6v$3cpt2$1@dont-email.me> <1006oi9$3l93f$1@dont-email.me> <1007kan$3qb7l$8@dont-email.me> <1009n2d$b9ol$1@dont-email.me> <100ag73$g1r8$1@dont-email.me> <100c83u$tspg$1@dont-email.me> <100ctuc$121rs$1@dont-email.me> <100d5b7$13m1e$1@dont-email.me> <ddbd48b20851b2362f0841506e0ffe32430323d9@i2pn2.org> <100dbpt$14tvf$2@dont-email.me> <100f06a$1ije7$1@dont-email.me> <100gvce$22oen$1@dont-email.me> <100h9a5$24gpu$1@dont-email.me> <100i37l$292ko$1@dont-email.me> <100ifg1$2bf5g$2@dont-email.me> <FT3XP.1290848$4AM6.642835@fx17.ams4>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 21 May 2025 10:05:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7c4ab65116ae26c95115ab40bfd13df1";
	logging-data="2890951"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/nAXtfPdp/cmxImqVLU98w"
User-Agent: Unison/2.2
Cancel-Lock: sha1:VPE65jUcpFpY28DSYoHzo5u5IE8=

On 2025-05-20 18:31:01 +0000, Mr Flibble said:

> On Tue, 20 May 2025 19:51:59 +0200, Fred. Zwarts wrote:
> 
>> Op 20.mei.2025 om 16:22 schreef olcott:
>>> On 5/20/2025 2:00 AM, Mikko wrote:
>>>> On 2025-05-20 04:10:54 +0000, olcott said:
>>>> 
>>>>> On 5/19/2025 5:12 AM, Mikko wrote:
>>>>>> On 2025-05-18 19:18:21 +0000, olcott said:
>>>>>> 
>>>>>>> On 5/18/2025 2:08 PM, joes wrote:
>>>>>>>> Am Sun, 18 May 2025 12:28:05 -0500 schrieb olcott:
>>>>>>>>> On 5/18/2025 10:21 AM, Mike Terry wrote:
>>>>>>>>>> On 18/05/2025 10:09, Mikko wrote:
>>>>>>>>>>> On 2025-05-17 17:15:14 +0000, olcott said:
>>>>>>>> 
>>>>>>>>>>>> HHH(DDD) does not base its decision on the actual behavior of
>>>>>>>>>>>> DDD after it has aborted its simulation of DDD, instead it
>>>>>>>>>>>> bases its decision on a different HHH/DDD pair that never
>>>>>>>>>>>> aborts.
>>>>>>>>>>> 
>>>>>>>>>>> This is why HHH does not satisfy "H correctly determines that
>>>>>>>>>>> its simulated D would never stop running unless aborted". If
>>>>>>>>>>> HHH bases its decision on anything else than what its actual
>>>>>>>>>>> input actually specifies it does not decide correctly.
>>>>>>>>>>> 
>>>>>>>>>> Right.  It seems to be a recent innovation in PO's wording that
>>>>>>>>>> he has started using the phrase "..bases its decision on a
>>>>>>>>>> different *HHH/DDD pair* ..".
>>>>>>>>>> 
>>>>>>>>> Thus SHD must report on a different SHD/Infinite_Loop pair where
>>>>>>>>> this hypothetical instance of itself never aborts.
>>>>>>>> This, the simulator. The input still calls the same real aborting
>>>>>>>> HHH.
>>>>>>>> 
>>>>>>>>> If H always reports on the behavior of its simulated input after
>>>>>>>>> it aborts then every input including infinite_loop would be
>>>>>>>>> determined to be halting.
>>>>>>>> Yes, that is why H is wrong.
>>>>>>>> 
>>>>>>>>> Instead H must report on the hypothetical H/D input pair where
>>>>>>>>> the very same H has been made to not abort its input.
>>>>>>>> Just no.
>>>>>>>> 
>>>>>>>>> *H correctly determines that its simulated D*
>>>>>>>>> *would never stop running unless aborted*
>>>>>>>>> by a hypothetical instance of itself that never aborts.
>>>>>>>> H does stop running when simulated without aborting, because it
>>>>>>>> aborts.
>>>>>>>> 
>>>>>>>> 
>>>>>>> H is required to report on the behavior of D in the case where a
>>>>>>> hypothetical instance of itself never aborts its simulated D.
>>>>>>> 
>>>>>>> When the hypothetical H never aborts its simulated D then:
>>>>>>> (a) Simulated D  NEVER HALTS (b) Executed D() NEVER HALTS (c)
>>>>>>> Executed H() NEVER HALTS (d) Everything that H calls NEVER HALTS
>>>>>> 
>>>>>> You forgot (e) H does not report
>>>>> 
>>>>> HHH is required to report, that is why it must always report on the
>>>>> behavior of the hypothetical H/D pair and not the actual behavior of
>>>>> the actual H/D pair for every non-terminating input.
>>>> 
>>>> Every decider is required to report. But your (c) above prevents the
>>>> hypothetical H from reporting. Therefore the hypothetical H is not a
>>>> decider.
>>>> 
>>>> 
>>> I wish that people would pay attention.
>>> People only glance at a couple of words that I say then artificially
>>> contrive a fake rebuttal.
>>> 
>>> *We are ONLY measuring HHH/DDD against this criteria*
>>> <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
>>> 
>>> 
>> We use the same criteria. We see that there is no correct simulation and
>> that H does not correctly determine that its simulated D would never
>> stop running. In fact the input specified to H contains code to abort,
>> so a simulation of this input without abort would lead to a natural
>> halt.
>> 
>> So, because the criteria are not met, we see that Sipser agreed to a
>> vacuous statement.
>> 
>> But you do not pay attention to what is said, because you stay in
>> rebuttal mode and, after seeing just a few words, keep repeating
>> statements that are proven to be irrelevant, without even touching the
>> fact that you are proven to be irrelevant.
> 
> The halting problem is defined in terms of UTMs with infinite tape so

It usually isn't. There are many variants of the problem but if you
have an oracle for one of the you can solve them all. Usually an UTM
is not mentioned in the problem statement. The tape is potentially
infinite but one execution of a decider never uses more than a finite
segment of the tape.

-- 
Mikko