Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Almost nothing in Perl serves a single purpose. -- Larry Wall in <199712040054.QAA13811@wall.org>


computers / comp.theory / Re: Category error [ HEAD GAMES ] (smart honest people would agree)[ Are my reviewers incompetent or dishonest? ]

Re: Category error [ HEAD GAMES ] (smart honest people would agree)[ Are my reviewers incompetent or dishonest? ]

<29-dndh0aZ2U9Rf_nZ2dnUU7_8xh4p2d@giganews.com>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=32887&group=comp.theory#32887

  copy link   Newsgroups: 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 May 2022 11:42:49 -0500
Date: Sun, 22 May 2022 11:42:48 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Category error [ HEAD GAMES ] (smart honest people would agree)[
Are my reviewers incompetent or dishonest? ]
Content-Language: en-US
Newsgroups: comp.theory
References: <20220514170555.00004550@reddwarf.jmc>
<YuSdnW-aUL3WXxr_nZ2dnUU7_83NnZ2d@giganews.com> <87wneg2m2h.fsf@bsb.me.uk>
<jPednedJMZKJWhr_nZ2dnUU7_81g4p2d@giganews.com> <87o7zr3od4.fsf@bsb.me.uk>
<SfWdnTcajIIjkxX_nZ2dnUU7_8zNnZ2d@giganews.com> <87bkvr3kqn.fsf@bsb.me.uk>
<vNmdncQOi5o3ohT_nZ2dnUU7_83NnZ2d@giganews.com>
<r%fiK.28447$J0r9.3351@fx11.iad>
<I6idnSDl8NcUDRT_nZ2dnUU7_83NnZ2d@giganews.com> <s5hiK.45$cq8.28@fx03.iad>
<NtGdndBRE5xLAhT_nZ2dnUU7_83NnZ2d@giganews.com>
<MlhiK.9438$kaDc.6185@fx46.iad>
<h6OdnUIaNIYVORT_nZ2dnUU7_81g4p2d@giganews.com>
<K4iiK.20028$zgr9.11815@fx13.iad>
<RrSdna_nM600MhT_nZ2dnUU7_8xh4p2d@giganews.com>
<HtiiK.3779$45E8.1989@fx47.iad>
<RtudndMn4p2gKBT_nZ2dnUU7_8xh4p2d@giganews.com>
<DEiiK.9440$kaDc.4559@fx46.iad>
<xoKdnSPcs6RjXhT_nZ2dnUU7_8zNnZ2d@giganews.com>
<xOoiK.1639$gjlb.707@fx44.iad>
<5oKdnSRTHInY0hf_nZ2dnUU7_8zNnZ2d@giganews.com>
<BqtiK.4006$45E8.3623@fx47.iad>
<37ednZeMJLXL-Bf_nZ2dnUU7_83NnZ2d@giganews.com>
<jItiK.2805$vAW9.1754@fx10.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <jItiK.2805$vAW9.1754@fx10.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <29-dndh0aZ2U9Rf_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 154
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-yIOA4+KyDsSSD9aUZS9rgpQwPTQi+gjPZqs4f1FRpJMNZKWUct8/VLkD7D7tbu5/QltIY6vopwt1BPg!LKAAwacYFw4p7X+qiPEHOrSeD3qfgctLMt8GXycIZvKoy0jQZ8Gc5EgbHE3ex7gh0gjWp/m26/4=
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: 9003
 by: olcott - Sun, 22 May 2022 16:42 UTC

On 5/22/2022 11:40 AM, Richard Damon wrote:
> On 5/22/22 12:31 PM, olcott wrote:
>> On 5/22/2022 11:21 AM, Richard Damon wrote:
>>> On 5/22/22 10:57 AM, olcott wrote:
>>>> On 5/22/2022 6:06 AM, Richard Damon wrote:
>>>>> On 5/22/22 1:02 AM, olcott wrote:
>>>>>> On 5/21/2022 11:05 PM, Richard Damon wrote:
>>>>>>> On 5/21/22 11:59 PM, olcott wrote:
>>>>>>>> On 5/21/2022 10:54 PM, Richard Damon wrote:
>>>>>>>>> On 5/21/22 11:36 PM, olcott wrote:
>>>>>>>>>> On 5/21/2022 10:27 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/21/22 10:48 PM, olcott wrote:
>>>>>>>>>>>> On 5/21/2022 9:37 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/21/22 10:28 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/21/2022 9:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/21/22 9:23 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/21/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/20/2022 5:25 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You have known that the input to H(P,P) is simulated
>>>>>>>>>>>>>>>>>>>> correctly proving
>>>>>>>>>>>>>>>>>>>> that H(P,P)==0 is correct for the whole six months
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If H is intended to be a halt decider (even if only
>>>>>>>>>>>>>>>>>>> for the one case you
>>>>>>>>>>>>>>>>>>> claim to care about) then H(P,P) == 0 is wrong,
>>>>>>>>>>>>>>>>>>> because P(P) halts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When we correctly reverse-engineer what the execution
>>>>>>>>>>>>>>>>>> trace of the input to H(P,P) would be for one
>>>>>>>>>>>>>>>>>> emulation and one nested emulation we can see that the
>>>>>>>>>>>>>>>>>> correctly emulated input to H(P,P) would never reach
>>>>>>>>>>>>>>>>>> its final state at machine address [0000136c].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A nonsense trace, as it is mixing the execution path of
>>>>>>>>>>>>>>>>> two independent execution units.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In other words you acknowledge that you are technically
>>>>>>>>>>>>>>>> incompetent to provide the execution trace of one
>>>>>>>>>>>>>>>> simulation and one nested simulation of the input to
>>>>>>>>>>>>>>>> H(P,P).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, I am saying that you are asking for the equivalent of
>>>>>>>>>>>>>>> a of a square circle.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So an execution trace of the input to H(P,P) is easy to
>>>>>>>>>>>>>> show when H simulates its input, yet another execution
>>>>>>>>>>>>>> trace of the input to H(P,P) that was invoked by P is
>>>>>>>>>>>>>> "like a square circle" can't possibly exist?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem is that your second trace is NOT a piece of the
>>>>>>>>>>>>> first.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact you don't understand that says you just don't know
>>>>>>>>>>>>> how computers or programs actually work.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> When a UTM simulates a TM description that calls a UTM that
>>>>>>>>>>>> simulates a
>>>>>>>>>>>> TM description all of this is simply data on the first UTM's
>>>>>>>>>>>> tape and the only actual executable is the first UTM.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, and a trace made by that outer UTM will show the states
>>>>>>>>>>> that the second UTM is going through, but NOT the states that
>>>>>>>>>>> second UTM simulates in its own processing.
>>>>>>>>>>>
>>>>>>>>>>> That second UTM might produce its OWN trace of the states
>>>>>>>>>>> that it has simulated, but that is a SEPERATE trace, and NOT
>>>>>>>>>>> part of the trace from the OUTER UTM.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And this trace is written to the outer UTM's tape as a part of
>>>>>>>>>> its own data.
>>>>>>>>>
>>>>>>>>> Yes, the DATA is there, ENCODED on the tape, but it isn't part
>>>>>>>>> of the trace generated by that UTM.
>>>>>>>>
>>>>>>>> The only actual executable is the outer UTM everything else is a
>>>>>>>> part of the same nested process.
>>>>>>>
>>>>>>> So the only actual valid trace is what that outer simulator
>>>>>>> actual simulated.
>>>>>>>
>>>>>>
>>>>>> There is a valid trace of every line of code that is emulated.
>>>>>> Operating system code has its trace tuned off. This only leaves
>>>>>> the user code such as P() and main(). Then we see the 14 lines
>>>>>> execution trace of the two level simulation of the input to H(P,P)
>>>>>
>>>>> No, because the second level emulation is NOT emulated by the top
>>>>> level emulator, its emulator is.
>>>>>
>>>>> Unless you are lying about what H does, you are just lying that the
>>>>> second level code is emulated by the same emulation process that
>>>>> the first is. (That may well be true, but it means you logic is
>>>>> still built on a lie).
>>>>>
>>>>
>>>> If you are too stupid to understand that H(P,P) derives the same
>>>> execution trace of its input every time it is called you are far too
>>>> stupid to evaluate my work.
>>>
>>> Ok, then why does the H(P,P) that P calls get stuck in an infinite
>>> recursion wneh the top level doesn't?
>>
>> It is a verified fact that the correct simulation of the input to
>> H(P,P) never reaches its final instruction thus conclusively proving
>> that it never halts.
>>
>
> The only machine that you have shown that does a correct simulation is
> the version that never aborts. That version fails to answer the
> question, so fails to be a halt decider.
>
> Any version of H that aborts, and returns a not-halting answer changes P
> into a Halting Compuation.
>
> The "pathological" use of H by P lets it change as you change H, so if H
> aborts, it is wrong because THAT P halts, if it doesn't, then it is
> wrong for not answering.
>
> You seem to miss this fact because you just don't understand the basics
> of how computations work. Part of your problem is you keep on trying to
> define H by rules that aren't an actual algorithm, so can't actually be
> written.
>

It is an easily verifiable fact that the C function H does correctly
determine that the C function named P would never reach its last
instruction when correctly emulated by H.

Everyone disagreeing with verified facts is incorrect on the basis of
lack of technical competency or lack of honesty.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

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

SubjectRepliesAuthor
o Category error

By: Mr Flibble on Sat, 14 May 2022

280Mr Flibble
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor