Deutsch   English   Français   Italiano  
<vvrmcf$s0mk$2@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: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sun, 11 May 2025 22:28:31 -0400
Organization: A noiseless patient Spider
Lines: 135
Message-ID: <vvrmcf$s0mk$2@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me>
 <87msbmeo3b.fsf@nosuchdomain.example.com> <vvjcge$27753$2@dont-email.me>
 <vvjeqf$28555$1@dont-email.me> <vvjffg$28g5i$1@dont-email.me>
 <875xiaejzg.fsf@nosuchdomain.example.com> <vvjgt1$28g5i$5@dont-email.me>
 <87jz6qczja.fsf@nosuchdomain.example.com> <vvjotc$28g5i$12@dont-email.me>
 <vvnh9u$3hd96$1@raubtier-asyl.eternal-september.org>
 <vvno4e$3in62$2@dont-email.me> <vvo71c$rlt$1@news.muc.de>
 <PlNTP.270466$lZjd.128570@fx05.ams4> <vvochv$15td$2@news.muc.de>
 <vvodn5$3na6l$3@dont-email.me>
 <1276edeb9893085c59b02bbbd59fe2c64011736b@i2pn2.org>
 <vvqk4s$gldn$12@dont-email.me> <vvqln4$g8ck$5@dont-email.me>
 <vvrftj$ndkg$1@dont-email.me> <vvrggs$n9a9$3@dont-email.me>
 <aa56821a00afb05081a2f4684d4ad8fefc9b2376@i2pn2.org>
 <vvrkg9$o2ab$3@dont-email.me> <vvrkm9$mv2a$7@dont-email.me>
 <vvrli3$s6gd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 May 2025 04:28:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d587ba6f088c47ed8fd2ad250ebfd646";
	logging-data="918228"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+FXChHRuEG/CH49R3dFnPj"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:xGX3Rmuvkz62vv7aNCX55gNWHZI=
Content-Language: en-US
In-Reply-To: <vvrli3$s6gd$1@dont-email.me>

On 5/11/2025 10:14 PM, olcott wrote:
> On 5/11/2025 8:59 PM, dbush wrote:
>> On 5/11/2025 9:56 PM, olcott wrote:
>>> On 5/11/2025 8:27 PM, Richard Damon wrote:
>>>> On 5/11/25 8:48 PM, olcott wrote:
>>>>> On 5/11/2025 7:38 PM, Mike Terry wrote:
>>>>>> On 11/05/2025 18:11, Richard Heathfield wrote:
>>>>>>> On 11/05/2025 17:44, olcott wrote:
>>>>>>>> Any yes/no question where both yes and no are the
>>>>>>>> wrong answer is an incorrect polar question.
>>>>>>>
>>>>>>> Either DD stops or it doesn't (once it's been hacked around to 
>>>>>>> get it to compile and after we've leeched out all the dodgy 
>>>>>>> programming).
>>>>>>
>>>>>> Done that.  It still stops.
>>>>>>
>>>>>>>
>>>>>>> If the computer cannot correctly decide whether or not DD halts, 
>>>>>>
>>>>>> The decider says it doesn't stop..
>>>>>>
>>>>>>> we have an undecidable computation, 
>>>>>>
>>>>>> No no, that doesn't make sense.  DD stops, and there are lots of 
>>>>>> partial halt deciders that will decide that particular input 
>>>>>> correctly.  PO's DD isn't "undecidable".
>>>>>>
>>>>>> No single computation can be undecidable, considered on its own! 
>>>>>> There are only two possibilities: it halts or it doesn't.  In 
>>>>>> either case there is a decider which decides that /one specific 
>>>>>> input/ correctly. By extension, any finite number of computations 
>>>>>> is decidable - we just have a giant switch statement followed by 
>>>>>> returning halts/neverhalts as appropriate.  If the input domain 
>>>>>> has just n inputs, there are 2^n trivial deciders that together 
>>>>>> cater for every combination of each input halting or never 
>>>>>> halting.  One of those deciders is a correct decider for that 
>>>>>> (finite domain) problem.
>>>>>>
>>>>>> The HP is asking for a TM (or equiv.) that correctly decides EVERY 
>>>>>> (P,I) in its one finite algorithm.  That is what is proven 
>>>>>> impossible.  The trick of having a big switch statement no longer 
>>>>>> works because there are infinitely many possible inputs.
>>>>>>
>>>>>> Decidability for just one single input is trivial and not intersting.
>>>>>>
>>>>>>> and therefore some computations are undecidable, so Turing's 
>>>>>>> conclusion was right. Who knew? (Apart from practically everybody 
>>>>>>> else, I mean.)
>>>>>>
>>>>>>
>>>>>> Mike.
>>>>>
>>>>> DDD emulated by HHH according to the rules of
>>>>> the computational language that DD is encoded
>>>>> within already proves that the HP "impossible"
>>>>> input specifies a non-halting sequence of
>>>>> configurations.
>>>>
>>>> No it doesn't.
>>>>
>>>
>>> _DDD()
>>> [00002172] 55         push ebp      ; housekeeping
>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping
>>> [00002175] 6872210000 push 00002172 ; push DDD
>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>> [0000217f] 83c404     add  esp,+04
>>> [00002182] 5d         pop  ebp
>>> [00002183] c3         ret
>>> Size in bytes:(0018) [00002183]
>>>
>>> Show all the steps of DDD emulated by simulating
>>> termination analyzer HHH according to the rules
>>> of the x86 language
>>
>> Which it doesn't do as you have admitted on the record:
>>
> 
> I am daring you to show what they should be.
> You know you can't because you know you are a liar.
> 

Category error.  Algorithm HHH does one thing and one thing only.  There 
is no "what it should be" because it *is* only one thing.

Algorithm HHH *does not* perform a correct simulation of algorithm DDD 
due to the abort, as you have admitted on the record:


>> On 5/5/2025 8:24 AM, dbush wrote:
>>  > On 5/4/2025 11:03 PM, dbush wrote:
>>  >> On 5/4/2025 10:05 PM, olcott wrote:
>>  >>> On 5/4/2025 7:23 PM, Richard Damon wrote:
>>  >>>> But HHH doesn't correct emulated DD by those rules, as those rules
>>  >>>> do not allow HHH to stop its emulation,
>>  >>>
>>  >>> Sure they do you freaking moron...
>>  >>
>>  >> Then show where in the Intel instruction manual that the execution of
>>  >> any instruction other than a HLT is allowed to stop instead of
>>  >> executing the next instruction.
>>  >>
>>  >> Failure to do so in your next reply, or within one hour of your next
>>  >> post on this newsgroup, will be taken as you official on-the-record
>>  >> admission that there is no such allowance and that HHH does NOT
>>  >> correctly simulate DD.
>>  >
>>  > Let the record show that Peter Olcott made the following post in this
>>  > newsgroup after the above message:
>>  >
>>  > On 5/4/2025 11:04 PM, olcott wrote:
>>  >  > D *WOULD NEVER STOP RUNNING UNLESS*
>>  >  > indicates that professor Sipser was agreeing
>>  >  > to hypotheticals AS *NOT CHANGING THE INPUT*
>>  >  >
>>  >  > You are taking
>>  >  > *WOULD NEVER STOP RUNNING UNLESS*
>>  >  > to mean *NEVER STOPS RUNNING* that is incorrect.
>>  >
>>  > And has made no attempt after over 9 hours to show where in the Intel
>>  > instruction manual that execution is allowed to stop after any
>>  > instruction other than HLT.
>>  >
>>  > Therefore, as per the above criteria:
>>  >
>>  > LET THE RECORD SHOW
>>  >
>>  > That Peter Olcott
>>  >
>>  > Has *officially* admitted
>>  >
>>  > That DD is NOT correctly simulated by HHH