Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Reactor error - core dumped!


computers / comp.theory / Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ]

Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ]

<CdNmK.39995$ssF.37533@fx14.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx14.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Subject: Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <LsGdnUOwGbn0FQf_nZ2dnUU7_8zNnZ2d@giganews.com> <20220604003502.00007f80@reddwarf.jmc.corp> <wsOdnSKt5-09Agf_nZ2dnUU7_8zNnZ2d@giganews.com> <EzxmK.13576$Rvub.12604@fx35.iad> <zLydnZEPn48xSwf_nZ2dnUU7_8zNnZ2d@giganews.com> <c4f56b94-c829-43de-bca0-f7a423dcdf85n@googlegroups.com> <gJidndqNZoOC6wb_nZ2dnUU7_83NnZ2d@giganews.com> <30LmK.66279$wIO9.25255@fx12.iad> <uOadnd7a6uXn4gb_nZ2dnUU7_83NnZ2d@giganews.com> <5vLmK.162920$zgr9.85977@fx13.iad> <ec2dneyshJbnGgb_nZ2dnUU7_8zNnZ2d@giganews.com> <sqMmK.35834$kaDc.28104@fx46.iad> <XaSdndmV2cyACAb_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <XaSdndmV2cyACAb_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 227
Message-ID: <CdNmK.39995$ssF.37533@fx14.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 4 Jun 2022 14:09:36 -0400
X-Received-Bytes: 11283
 by: Richard Damon - Sat, 4 Jun 2022 18:09 UTC

On 6/4/22 1:23 PM, olcott wrote:
> On 6/4/2022 12:15 PM, Richard Damon wrote:
>> On 6/4/22 12:25 PM, olcott wrote:
>>> On 6/4/2022 11:11 AM, Richard Damon wrote:
>>>>
>>>> On 6/4/22 11:51 AM, olcott wrote:
>>>>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>>>>> On 6/4/22 11:11 AM, olcott wrote:
>>>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This post assumes that you already know my work, otherwise
>>>>>>>>>>>>> please
>>>>>>>>>>>>> read the linked paper provided below. This work is based on
>>>>>>>>>>>>> the
>>>>>>>>>>>>> x86utm operating system that was created so that every
>>>>>>>>>>>>> detail of the
>>>>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would never
>>>>>>>>>>>>> halt
>>>>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>>>>> instruction).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Equally obvious is the fact that a partial x86 emulation of
>>>>>>>>>>>>> this
>>>>>>>>>>>>> input conclusively proves that its complete x86 emulation
>>>>>>>>>>>>> would never
>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>> Stored at:212343
>>>>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>>>>>>
>>>>>>>>>>>>> The exact same reasoning applies to the correctly emulated
>>>>>>>>>>>>> input to
>>>>>>>>>>>>> H(P,P):
>>>>>>>>>>>>>
>>>>>>>>>>>>> _P()
>>>>>>>>>>>>> [00001352](01)  55              push ebp
>>>>>>>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>>>>>>>> [0000136c](01)  c3              ret
>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>> emulates its
>>>>>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because the seventh instruction repeats this process we can
>>>>>>>>>>>>> know with
>>>>>>>>>>>>> complete certainty that the emulated P never reaches its
>>>>>>>>>>>>> final “ret”
>>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>>>>> whether or not
>>>>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>>>>> recursion (call
>>>>>>>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>>>>>>>> attempting
>>>>>>>>>>>> to refute.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>>>>
>>>>>>>>>> But you can not assume that an actual simulating Halt Decider
>>>>>>>>>> actually
>>>>>>>>>> exists.
>>>>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>>>>
>>>>>>>> You've got nested simulations.
>>>>>>>> If H detects them as infinitely nested, and aborts, they are no
>>>>>>>> longer infinitely
>>>>>>>> nested, so it gets the wrong answer (as happens here).
>>>>>>>
>>>>>>> I can't understand how you can be so wrong about this. It is like
>>>>>>> you make sure to never read anything that I say before spouting
>>>>>>> off a canned rebuttal.
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>>    HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>> }
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [00001342](01)  55              push ebp
>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>> [00001348](01)  c3              ret
>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>
>>>>>>> In the same way that H0 detects that the complete x86 emulation
>>>>>>> of _Infinite_Loop() would never reach its final "ret" instruction
>>>>>>> H(P,P) on the basis of a partial simulation H(P,P) detects that
>>>>>>> the complete x86 emulation of its input would never reach its
>>>>>>> final "ret" instruction.
>>>>>>>
>>>>>>> Did you notice that I said this 500 times already?
>>>>>>> Did you notice that I said this 500 times already?
>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>
>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>
>>>>>> Right, and for the simulation of H(P,P), that is all that happen
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>
>>>>>>
>>>>>> And the input to H(P,P) does TERMINATE NORMALLY when correct
>>>>>> simulated.
>>>>>>
>>>>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>>>>
>>>>> _P()
>>>>> [00001352](01)  55              push ebp
>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001358](01)  50              push eax      // push P
>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000135c](01)  51              push ecx      // push P
>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>> [00001362](03)  83c408          add esp,+08
>>>>> [00001365](02)  85c0            test eax,eax
>>>>> [00001367](02)  7402            jz 0000136b
>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>> [0000136b](01)  5d              pop ebp
>>>>> [0000136c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>> input that it must emulate the first seven instructions of P.
>>>>> Because the seventh instruction repeats this process we can know
>>>>> with complete certainty that the emulated P never reaches its final
>>>>> “ret” instruction, thus never halts.
>>>>>
>>>>>
>>>>
>>>> Right, it emulates the first seven instructions,
>>>
>>> BRAIN DEAD MORONS DON'T GET THIS:
>>> Because we verified that H(P,P) emulates the first seven instructions
>>> of P we know that it will keep doing this every time that H(P,P) is
>>> invoked as long as the simulation continues.
>>
>> Nope, different invocations of H's so not part of the same trace.
> That is what a brain dead moron (or a despicable liar) would say.
>
> The whole point is whether or not the correct x86 emulation of the
> original input would ever reach its final "ret" instruction.
>

Right, the correct x86 emulation of the ORIGINAL input. The second layer
of simulation is NOT part of that as an actual execution, only the act
of simulating it is.

You clearly don't actually understand what it means to correctly emulate
something.

> If the answer is "no" because a big red dragon incinerates this input
> with its breath of fire then the answer is still "no".
>

Nope, since it is impossible for a big red dragon to actually incinerate
this input.

You can't include impossible cases, that is false logic.

SubjectRepliesAuthor
o Refuting the HP proofs (adapted for software engineers)

By: olcott on Fri, 3 Jun 2022

164olcott
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor