Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: DDD correctly emulated by H0 -- Ben agrees that Sipser approved
 criteria is met
Date: Tue, 25 Jun 2024 23:35:26 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v5g29u$14bcm$11@i2pn2.org>
References: <v45tec$4q15$1@dont-email.me> <v4sd35$1eb2f$5@dont-email.me>
 <v4u3jl$1se49$1@dont-email.me> <v4umvh$1vpm0$7@dont-email.me>
 <v50d8k$2e51s$1@dont-email.me> <v50dtp$2e5ij$1@dont-email.me>
 <v51f4t$2k8ar$1@dont-email.me> <v51ge4$2kbbe$2@dont-email.me>
 <v539bk$329sv$1@dont-email.me> <v53upb$35vak$6@dont-email.me>
 <v575pl$3sg5p$1@dont-email.me> <v5767s$3soh6$1@dont-email.me>
 <v5e28t$11urb$5@i2pn2.org> <v5eg03$1ikpr$2@dont-email.me>
 <v5eho7$24l4$1@news.muc.de> <87jzidm83f.fsf@bsb.me.uk>
 <v5el8c$24l4$4@news.muc.de> <v5evoi$1lgoi$1@dont-email.me>
 <v5frvn$14bcm$6@i2pn2.org> <v5ft1p$1uc3o$2@dont-email.me>
 <v5fu24$14bcn$2@i2pn2.org> <v5fuf7$1up2o$1@dont-email.me>
 <v5fvvk$14bcn$4@i2pn2.org> <v5g1ue$1v8bm$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Jun 2024 03:35:26 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1191318"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v5g1ue$1v8bm$2@dont-email.me>
Bytes: 8907
Lines: 177

On 6/25/24 11:29 PM, olcott wrote:
> On 6/25/2024 9:55 PM, Richard Damon wrote:
>> On 6/25/24 10:29 PM, olcott wrote:
>>> On 6/25/2024 9:23 PM, Richard Damon wrote:
>>>> On 6/25/24 10:05 PM, olcott wrote:
>>>>> On 6/25/2024 8:47 PM, Richard Damon wrote:
>>>>>> On 6/25/24 1:45 PM, olcott wrote:
>>>>>>> On 6/25/2024 9:46 AM, Alan Mackenzie wrote:
>>>>>>>> Hi, Ben.
>>>>>>>>
>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> wrote:
>>>>>>>>> Alan Mackenzie <acm@muc.de> writes:
>>>>>>>>
>>>>>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> On 6/25/2024 4:22 AM, joes wrote:
>>>>>>>>>>>> Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:
>>>>>>>>>>>>> On 6/22/2024 1:39 PM, Fred. Zwarts wrote:
>>>>>>>>>>>>>> Op 21.jun.2024 om 15:21 schreef olcott:
>>>>>>>>
>>>>>>>>>>>>> When we stipulate that the only measure of a correct 
>>>>>>>>>>>>> emulation is the
>>>>>>>>>>>>> semantics of the x86 programming language then we see that 
>>>>>>>>>>>>> when DDD is
>>>>>>>>>>>>> correctly emulated by H0 that its call to H0(DDD) cannot 
>>>>>>>>>>>>> possibly
>>>>>>>>>>>>> return.
>>>>>>>>>>>> Yes. Which is wrong, because H0 should terminate.
>>>>>>>>
>>>>>>>>>> [ .... ]
>>>>>>>>
>>>>>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated
>>>>>>>>>>> by H0 cannot possibly return.
>>>>>>>>
>>>>>>>>>>> Until you acknowledge this is true, this is the
>>>>>>>>>>> only thing that I am willing to talk to you about.
>>>>>>>>
>>>>>>>>>> I think you are talking at cross purposes.  Joes's point is 
>>>>>>>>>> that H0
>>>>>>>>>> should terminate because it's a decider.  You're saying that 
>>>>>>>>>> when H0 is
>>>>>>>>>> "correctly" emulating, it won't terminate.  I don't recall 
>>>>>>>>>> seeing anybody
>>>>>>>>>> arguing against that.
>>>>>>>>
>>>>>>>>>> So you're saying, in effect, H0 is not a decider.  I don't 
>>>>>>>>>> think anybody
>>>>>>>>>> else would argue against that, either.
>>>>>>>>
>>>>>>>>> He's been making exactly the same nonsense argument for years.  It
>>>>>>>>> became crystal clear a little over three years ago when he made 
>>>>>>>>> the
>>>>>>>>> mistake of posting the pseudo-code for H -- a step by step 
>>>>>>>>> simulator
>>>>>>>>> that stopped simulating (famously on line 15) when some pattern 
>>>>>>>>> was
>>>>>>>>> detected.  He declared false (not halting) to be the correct 
>>>>>>>>> result for
>>>>>>>>> the halting computation H(H_Hat(), H_Hat()) because of what 
>>>>>>>>> H(H_Hat(),
>>>>>>>>> H_Hat()) would do "if line 15 were commented out"!
>>>>>>>>
>>>>>>>>> PO does occasionally make it clear what the shell game is.
>>>>>>>>
>>>>>>>> I think it's important for (relative) newcomers to the newsgroup to
>>>>>>>> become aware of this.  Each one of them is trying to help PO 
>>>>>>>> improve his
>>>>>>>> level of learning.  They will eventually give up, as you and I have
>>>>>>>> done, recognising (as Mike Terry, in particular, has done) that
>>>>>>>> enriching PO's intellect is a quite impossible task.
>>>>>>>>
>>>>>>>> What's the betting he'll respond to this post with his usual short
>>>>>>>> sequence of x86 assembly code together with a demand to recognise
>>>>>>>> something or other as non-terminating?
>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Ben.
>>>>>>>>
>>>>>>>
>>>>>>> <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>
>>>>>>>
>>>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>>>>>  > I don't think that is the shell game. PO really /has/ an H
>>>>>>>  > (it's trivial to do for this one case) that correctly determines
>>>>>>>  > that P(P) *would* never stop running *unless* aborted.
>>>>>>>  >
>>>>>>>  > He knows and accepts that P(P) actually does stop. The
>>>>>>>  > wrong answer is justified by what would happen if H
>>>>>>>  > (and hence a different P) where not what they actually are.
>>>>>>>  >
>>>>>>>
>>>>>>> Ben thinks that I tricked professor Sipser into agreeing
>>>>>>> with something that he did not fully understand.
>>>>>>>
>>>>>>> *The real issue is that no one here sufficiently understands*
>>>>>>> *the highlighted portion of the following definition*
>>>>>>>
>>>>>>> Computable functions are the formalized analogue of the
>>>>>>> intuitive notion of algorithms, in the sense that a
>>>>>>> function is computable if there exists an algorithm
>>>>>>> that can do the job of the function, i.e.
>>>>>>>
>>>>>>> *given an input of the function domain*
>>>>>>> *it can return the corresponding output*
>>>>>>>
>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> But only if the function is, in fact, computable.
>>>>>>
>>>>>> Since Halting isn't, you can't use that fact.
>>>>>
>>>>> If I ask you: What time is it?
>>>>> and you do not tell me the answer to the question hidden
>>>>> in my mind "What did you have for dinner?" We cannot say
>>>>> that you provided the wrong answer when you tell me what
>>>>> time it is.
>>>>
>>>> Because I answered the actual question.
>>>>
>>>> Just like the "Halt Decider" needs to answer the "Halt Decider 
>>>> Question" and not answer about POOP.
>>>>
>>>>>
>>>>> When we ask H to tell us whether its actual input halts
>>>>> H can only answer that P correctly simulated by H will not halt.
>>>>> H cannot answer the question hidden in your mind.
>>>>>
>>>>
>>>> Then you are just admitting that it can't be a Halt Decider.
>>>>
>>>> If it isn't what the definition requires, it just isn't one.
>>>>
>>>
>>> Yes and everyone knows that computer scientists are much
>>> more infallible than God thus cannot possibly ever make
>>> a definition that is incoherent in ways that these 100%
>>> infallible computer scientists never noticed.
>>>
>>
>> Except you can't show that the definition IS incoherent, 
> 
> In a way that your limited understanding can comprehend.
> You are so sure that I must be wrong that you cannot possibly
> pay close enough attention to the exact words that I say.
> 
> My point is entirely proven by how a set of finite string
> transformations map one finite string to another.

Nope. You ASSUME the answer to try to prove it.

The problem seems to be that you don't understand what it means for the 
decider to try to compute the results of a "mapping".

That mapping is defined, not by a set of finite transformations, but by 
a set of definition. That it isn't computable is perfectly fine, and in 
fact, MOST mappings that could be defined will turn out uncomputable as 
========== REMAINDER OF ARTICLE TRUNCATED ==========