Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
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 22:29:18 -0500
Organization: A noiseless patient Spider
Lines: 166
Message-ID: <v5g1ue$1v8bm$2@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 26 Jun 2024 05:29:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="863b71206377856c10e8f571e9178830";
	logging-data="2072950"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19wGNqUfmigkCSm0/q8uSeM"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ME2bN3AxzEDwprmIA0VGPwudP78=
Content-Language: en-US
In-Reply-To: <v5fvvk$14bcn$4@i2pn2.org>
Bytes: 8373

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.

> just that *YOU* 
> can't understand it.
> 
> That is YOUR problem, not the problem of the definition.
> 
> 
> 

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer