Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Depends on how you define "always". :-) -- Larry Wall in <199710211647.JAA17957@wall.org>


computers / comp.ai.philosophy / Re: Concise refutation of halting problem proofs V42 [computer scientist]

Re: Concise refutation of halting problem proofs V42 [computer scientist]

<2P-dnaG0FJN8fFL8nZ2dnUU7-avNnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=7721&group=comp.ai.philosophy#7721

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 31 Dec 2021 23:08:49 -0600
Date: Fri, 31 Dec 2021 23:08:47 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.4.1
Subject: Re: Concise refutation of halting problem proofs V42 [computer
scientist]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <rvGdnaE3EuksDFH8nZ2dnUU7-UvNnZ2d@giganews.com>
<sql4qd$dre$1@dont-email.me> <W8OdnXzQIutMhlP8nZ2dnUU7-Q3NnZ2d@giganews.com>
<sql6he$khm$1@dont-email.me> <Y_mdnZp_XMbuvFP8nZ2dnUU7-dPNnZ2d@giganews.com>
<sqnutn$lbd$1@dont-email.me> <s_2dnY4DMJt2FlL8nZ2dnUU7-eednZ2d@giganews.com>
<sqo3vg$lun$1@dont-email.me> <FeydnXVBhLMqB1L8nZ2dnUU7-cvNnZ2d@giganews.com>
<sqo9o5$hh6$1@dont-email.me> <coadnR-r2Yc4NlL8nZ2dnUU7-S2dnZ2d@giganews.com>
<sqob91$nom$1@dont-email.me> <vfCdndIh1NrILlL8nZ2dnUU7-RudnZ2d@giganews.com>
<69PzJ.214781$3q9.35099@fx47.iad>
<FJ6dnZA9pawUXFL8nZ2dnUU7-bHNnZ2d@giganews.com>
<zCPzJ.214782$3q9.38321@fx47.iad>
<DoSdnYuLArBBUVL8nZ2dnUU7-WfNnZ2d@giganews.com>
<5cQzJ.254762$IW4.19763@fx48.iad>
<MOednVnaAIyMTFL8nZ2dnUU7-IHNnZ2d@giganews.com>
<mnQzJ.181779$6a3.8310@fx41.iad>
<Irqdnbiiy4TbS1L8nZ2dnUU7-Q_NnZ2d@giganews.com>
<FMQzJ.121927$IB7.65216@fx02.iad>
<raWdnZqY8Lu9QFL8nZ2dnUU7-QPNnZ2d@giganews.com>
<H7RzJ.135613$QB1.48735@fx42.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <H7RzJ.135613$QB1.48735@fx42.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <2P-dnaG0FJN8fFL8nZ2dnUU7-avNnZ2d@giganews.com>
Lines: 190
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-NwiDWxc2HZI1apGoGBmGgkaoTR/2JjDDuk3rfblqQHD1Ps+J5b0FQ6ynRwKqij9OeH7voLton7cfQHL!YcTXK8+SQcfboFqqb6IOJiV8PRHD0nSM1LILgSMsIIognILl1bT/AtCD/Vie1D4Sgx8R5W/3gtuY!Rg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 9455
 by: olcott - Sat, 1 Jan 2022 05:08 UTC

On 12/31/2021 10:54 PM, Richard Damon wrote:
>
> On 12/31/21 11:48 PM, olcott wrote:
>> On 12/31/2021 10:29 PM, Richard Damon wrote:
>>> On 12/31/21 11:19 PM, olcott wrote:
>>>> On 12/31/2021 10:02 PM, Richard Damon wrote:
>>>>> On 12/31/21 10:57 PM, olcott wrote:
>>>>>> On 12/31/2021 9:50 PM, Richard Damon wrote:
>>>>>>> On 12/31/21 10:39 PM, olcott wrote:
>>>>>>>> On 12/31/2021 9:10 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 12/31/21 9:50 PM, olcott wrote:
>>>>>>>>>> On 12/31/2021 8:39 PM, Richard Damon wrote:
>>>>>>>>>>> On 12/31/21 8:50 PM, olcott wrote:
>>>>>>>>>>>> On 12/31/2021 7:37 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-12-31 18:17, olcott wrote:
>>>>>>>>>>>>>> On 12/31/2021 7:11 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2021-12-31 17:05, olcott wrote:
>>>>>>>>>>>>>>>> On 12/31/2021 5:33 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2021-12-31 16:02, olcott wrote:
>>>>>>>>>>>>>>>>>> On 12/31/2021 4:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> An actual computer scientist will understand that
>>>>>>>>>>>>>>>>>> embedded_H does compute the mapping from these inputs
>>>>>>>>>>>>>>>>>> finite strings ⟨Ĥ⟩ ⟨Ĥ⟩ to this final state Ĥ.qn on the
>>>>>>>>>>>>>>>>>> basis that the actual input would never halt.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You're not really in a position to state what an actual
>>>>>>>>>>>>>>>>> computer scientist would understand. Only an actual
>>>>>>>>>>>>>>>>> computer scientist can do that.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is a self-evident truth that:
>>>>>>>>>>>>>>>> (a) The pure simulation of the Turing machine
>>>>>>>>>>>>>>>> description of a machine is computationally equivalent
>>>>>>>>>>>>>>>> to the direct execution of this machine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (b) The pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>> never halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (c) If the pure simulation of the input to a halt
>>>>>>>>>>>>>>>> decider would never halt then the halt decider correctly
>>>>>>>>>>>>>>>> decides that this input does not halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A computer scientist would understand these things.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It would appear that you ignored (and cut) all the actual
>>>>>>>>>>>>>>> points in my post.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why don't we simplify things a bit. When Ĥ ⟨Ĥ⟩ is called,
>>>>>>>>>>>>>>> how does Ĥ determine that its input describes itself? You
>>>>>>>>>>>>>>> claim this is done by string comparisons, but which
>>>>>>>>>>>>>>> strings are being compared? The only string Ĥ has access
>>>>>>>>>>>>>>> to its input string. What does it compare this string with?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So far I have not gotten to any point of closure on
>>>>>>>>>>>>>> anything that I have said. I must insist on points of
>>>>>>>>>>>>>> closure for continued dialogue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you agree that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by
>>>>>>>>>>>>>> embedded_H would never halt?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Of course I don't, since that claim is simply false.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now why don't you actually answer the question I asked?
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We must stay on this point until we have mutual agreement.
>>>>>>>>>>>> Why do you say it is false?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> BIG QUESTION.
>>>>>>>>>>>
>>>>>>>>>>> Is it even a proper question?
>>>>>>>>>>>
>>>>>>>>>>> Is it a fact that embedded_H just does a pure simulation?
>>>>>>>>>>>
>>>>>>>>>>> Or. is there an abort condition?
>>>>>>>>>>>
>>>>>>>>>>> Remember, any time you change any of the properties of the H
>>>>>>>>>>> that you built H^ from, any analysis from previous H^s need
>>>>>>>>>>> to be thrown out, or at least reconfirmed with the new H.
>>>>>>>>>>
>>>>>>>>>> It is the case that when embedded_H simulates 0 to ∞ steps of
>>>>>>>>>> its input that its input never halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, but then it doesn't answer and fails.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is the case that when embedded_H simulates 0 to ∞ steps of
>>>>>>>> its input that its input never halts
>>>>>>>>
>>>>>>>> CONCLUSIVELY PROVING THAT THIS INPUT NEVER HALTS EVEN IF IT IS
>>>>>>>> ABORTED
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Yes, But H can't do that aborting, because you just said that
>>>>>>> embedded_H didn't abort it.
>>>>>>>
>>>>>>
>>>>>> Do you think that it is possible to tell that an infinite loop
>>>>>> will never stop running without actually having to wait forever?
>>>>>>
>>>>>> void Infinite_Loop(int N)
>>>>>> {
>>>>>>    HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> _Infinite_Loop()
>>>>>> [00000cb5](01)  55              push ebp
>>>>>> [00000cb6](02)  8bec            mov ebp,esp
>>>>>> [00000cb8](02)  ebfe            jmp 00000cb8
>>>>>> [00000cba](01)  5d              pop ebp
>>>>>> [00000cbb](01)  c3              ret
>>>>>> Size in bytes:(0007) [00000cbb]
>>>>>>
>>>>>>
>>>>>
>>>>> In some cases, yes.
>>>>>
>>>>> You seem to like your Herring Red.
>>>>>
>>>>> The question is not is it possible to answer some other halting
>>>>> questions, but if H can answer a particular one.
>>>>
>>>> If it is the case that embedded_H does correctly determine its input
>>>> would never halt if it simulates 0 to ∞ steps of this input
>>>>
>>>> and it makes this determination in a finite number of steps
>>>> and it aborts the simulation of this input
>>>>
>>>
>>> Which it can't as proven at:
>>>
>>> Mesage ID  <FOnzJ.162569$np6.119786@fx46.iad>
>>> Date: 2021-12-30 19:31:49 GMT
>>> Subject: Re: Concise refutation of halting problem proofs V42
>>> [compute the mapping]
>>>
>>> FAIL.
>>
>> That is irrelevant at this point in the dialogue.
>
>
> WHY?
>
> The fact that you just claim, with NO proof to have the Unicorn Halt
> Decider to do your bidding.
>
> You logic is UNSOUND, as are you.
>>
>>>
>>>
>>>> this does not cause the input to halt because an input must reach
>>>> its final state to halt
>>>
>>> i.e that ACTUAL Machine must not reach a halting state, not an
>>> aborted simulation, but H& does reach that state.
>>>
>>
>> Your words are incoherent.
>>
>> When we hypothesize that embedded_H can determine that input to
>> embedded_H never reaches its final state in 0 to ∞ steps of simulation
>> and it can do this in a finite number of steps
>
> You Hypothesize the impossible.

This is the only point that I am willing to discuss with anyone until
mutual agreement is achieved.

If embedded_H does correctly determine that its input cannot possibly
reach the final state of this input then it is correct for embedded_H to
aborts its simulation of this input and transition to Ĥ.qn.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

SubjectRepliesAuthor
o Concise refutation of halting problem proofs V42 [where people get

By: olcott on Wed, 29 Dec 2021

7olcott
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor