Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Per buck you get more computing action with the small computer. -- R. W. Hamming


computers / comp.ai.philosophy / Re: Halting Problem proof refutation is a tautology thus irrefutable [ liar or incompetent ]

Re: Halting Problem proof refutation is a tautology thus irrefutable [ liar or incompetent ]

<8FMrK.1097$Ae2.365@fx35.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.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.10.0
Subject: Re: Halting Problem proof refutation is a tautology thus irrefutable
[ liar or incompetent ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <d8-dnTlDr8xgoTL_nZ2dnUU7_83NnZ2d@giganews.com>
<20220619162307.000041b2@reddwarf.jmc>
<--edndX8966r3jL_nZ2dnUU7_83NnZ2d@giganews.com>
<20220619170111.00002570@reddwarf.jmc>
<JfadnQoBhqnh0DL_nZ2dnUU7_8xh4p2d@giganews.com>
<20220619180139.000016fd@reddwarf.jmc>
<1aGdnUFFEoFIxDL_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220619184006.00002392@reddwarf.jmc>
<lpudnfhnnOCe-zL_nZ2dnUU7_8xh4p2d@giganews.com>
<CNJrK.175022$JVi.9534@fx17.iad>
<CqOdnWr5A4-j9jL_nZ2dnUU7_83NnZ2d@giganews.com>
<y7KrK.139604$X_i.4832@fx18.iad>
<GPednbS5wMDL6zL_nZ2dnUU7_83NnZ2d@giganews.com>
<20220619205952.00005846@reddwarf.jmc>
<5YudnR0PwMnqHDL_nZ2dnUU7_83NnZ2d@giganews.com>
<20220619210812.00003001@reddwarf.jmc>
<6N6dnYHnFNCYGTL_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220619213137.00004b36@reddwarf.jmc>
<LJydne9Uae7JFzL_nZ2dnUU7_83NnZ2d@giganews.com> <s7MrK.305$Eh2.78@fx41.iad>
<K4adnWJPQ6H9DzL_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220619222001.00006585@reddwarf.jmc>
<aeqdnfOXoMVYDjL_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <aeqdnfOXoMVYDjL_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 372
Message-ID: <8FMrK.1097$Ae2.365@fx35.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: Sun, 19 Jun 2022 17:36:03 -0400
X-Received-Bytes: 19813
 by: Richard Damon - Sun, 19 Jun 2022 21:36 UTC

On 6/19/22 5:23 PM, olcott wrote:
> On 6/19/2022 4:20 PM, Mr Flibble wrote:
>> On Sun, 19 Jun 2022 16:17:20 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/19/2022 4:00 PM, Richard Damon wrote:
>>>> On 6/19/22 4:43 PM, olcott wrote:
>>>>> On 6/19/2022 3:31 PM, Mr Flibble wrote:
>>>>>> On Sun, 19 Jun 2022 15:16:05 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/19/2022 3:08 PM, Mr Flibble wrote:
>>>>>>>> On Sun, 19 Jun 2022 15:05:11 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 6/19/2022 2:59 PM, Mr Flibble wrote:
>>>>>>>>>> On Sun, 19 Jun 2022 14:17:42 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 6/19/2022 1:43 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/19/22 2:30 PM, olcott wrote:
>>>>>>>>>>>>> On 6/19/2022 1:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/19/22 2:08 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/19/2022 12:40 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Sun, 19 Jun 2022 12:16:05 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>> On 6/19/2022 12:01 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sun, 19 Jun 2022 11:23:24 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>> On 6/19/2022 11:01 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Sun, 19 Jun 2022 10:39:34 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/19/2022 10:23 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sun, 19 Jun 2022 10:13:00 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will
>>>>>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state.
>>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its
>>>>>>>>>>>>>>>>>>>>>>> inputs to an accept or reject state on the basis
>>>>>>>>>>>>>>>>>>>>>>> of the actual behavior of these actual inputs.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When a simulating halt decider rejects all
>>>>>>>>>>>>>>>>>>>>>>> inputs as non-halting whenever it correctly
>>>>>>>>>>>>>>>>>>>>>>> detects [in a finite number of steps] that its
>>>>>>>>>>>>>>>>>>>>>>> correct and complete simulation of its input
>>>>>>>>>>>>>>>>>>>>>>> would never reach [a] final state of this input
>>>>>>>>>>>>>>>>>>>>>>> then all [these] inputs (including pathological
>>>>>>>>>>>>>>>>>>>>>>> inputs) are decided correctly.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>            H(x, x);
>>>>>>>>>>>>>>>>>>>>>>            return;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>            Output("Input_Halts = ", H((u32)Px,
>>>>>>>>>>>>>>>>>>>>>> (u32)Px)); }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408
>>>>>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013eb][00102353][00000000] 50
>>>>>>>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427]
>>>>>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
>>>>>>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff
>>>>>>>>>>>>>>>>>>>>>> call 00000476 Input_Halts = 0
>>>>>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408
>>>>>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013f9][00102357][00000000]
>>>>>>>>>>>>>>>>>>>>>> 33c0 xor eax,eax
>>>>>>>>>>>>>>>>>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>> ...[000013fc][0010235f][00000004] c3 ret Number
>>>>>>>>>>>>>>>>>>>>>> of Instructions Executed(16120)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been
>>>>>>>>>>>>>>>>>>>>>> decided correctly. QED.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>>>> [000010fa](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>> [000010fb](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>> [000010fd](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>> [00001100](01)  50              push eax       //
>>>>>>>>>>>>>>>>>>>>> push P [00001101](03)  8b4d08          mov
>>>>>>>>>>>>>>>>>>>>> ecx,[ebp+08] [00001104](01)  51              push
>>>>>>>>>>>>>>>>>>>>> ecx       // push P [00001105](05)  e800feffff
>>>>>>>>>>>>>>>>>>>>>   call 00000f0a  // call H [0000110a](03)  83c408
>>>>>>>>>>>>>>>>>>>>>         add esp,+08 [0000110d](02)  85c0
>>>>>>>>>>>>>>>>>>>>> test eax,eax [0000110f](02)  7402            jz
>>>>>>>>>>>>>>>>>>>>> 00001113 [00001111](02)  ebfe            jmp
>>>>>>>>>>>>>>>>>>>>> 00001111 [00001113](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>> [00001114](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [00001114]
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Begin Simulation   Execution Trace Stored at:211ee2
>>>>>>>>>>>>>>>>>>>>> ...[000010da][00211ece][00211ed2] 55         push
>>>>>>>>>>>>>>>>>>>>> ebp ...[000010db][00211ece][00211ed2] 8bec
>>>>>>>>>>>>>>>>>>>>> mov ebp,esp ...[000010dd][00211ece][00211ed2]
>>>>>>>>>>>>>>>>>>>>> 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>>>> ...[000010e0][00211eca][000010da] 50 push eax
>>>>>>>>>>>>>>>>>>>>> // push P ...[000010e1][00211eca][000010da] 8b4d08
>>>>>>>>>>>>>>>>>>>>>      mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>>>> ...[000010e4][00211ec6][000010da] 51 push ecx //
>>>>>>>>>>>>>>>>>>>>> push P ...[000010e5][00211ec2][000010ea]
>>>>>>>>>>>>>>>>>>>>> e820feffff call 00000f0a // call H Infinitely
>>>>>>>>>>>>>>>>>>>>> Recursive Simulation Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *All technically competent software engineers*
>>>>>>>>>>>>>>>>>>>>> will see that when H bases its halt status
>>>>>>>>>>>>>>>>>>>>> decision on whether or not its complete and
>>>>>>>>>>>>>>>>>>>>> correct x86 emulation of its input would ever
>>>>>>>>>>>>>>>>>>>>> reach the "ret" instruction of this input that H
>>>>>>>>>>>>>>>>>>>>> is correct to reject this input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>           H(x, x);
>>>>>>>>>>>>>>>>>>>>           return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>           Output("Input_Halts = ", H((u32)Px,
>>>>>>>>>>>>>>>>>>>> (u32)Px)); }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408
>>>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013eb][00102353][00000000] 50
>>>>>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427]
>>>>>>>>>>>>>>>>>>>> 6827040000 push 00000427
>>>>>>>>>>>>>>>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call
>>>>>>>>>>>>>>>>>>>> 00000476 Input_Halts = 0
>>>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408
>>>>>>>>>>>>>>>>>>>> add esp,+08 ...[000013f9][00102357][00000000] 33c0
>>>>>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
>>>>>>>>>>>>>>>>>>>> pop ebp ...[000013fc][0010235f][00000004] c3 ret
>>>>>>>>>>>>>>>>>>>> Number of Instructions Executed(16120)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been
>>>>>>>>>>>>>>>>>>>> decided correctly. QED.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *All technically competent software engineers*
>>>>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>          H(x, x);
>>>>>>>>>>>>>>>>>>          return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>          Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408          add
>>>>>>>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
>>>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] 6827040000
>>>>>>>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427]
>>>>>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0
>>>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408          add
>>>>>>>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
>>>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
>>>>>>>>>>>>>>>>>>      pop ebp ...[000013fc][0010235f][00000004] c3
>>>>>>>>>>>>>>>>>> ret Number of Instructions Executed(16120)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been
>>>>>>>>>>>>>>>>>> decided correctly. QED.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because it is an easily verified fact that the correct
>>>>>>>>>>>>>>>>> and complete x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>> would never reach the "ret" instruction of P and this
>>>>>>>>>>>>>>>>> is the criterion measure for H to reject its input how
>>>>>>>>>>>>>>>>> do you figure that H gets the wrong answer?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What I am saying is a logical tautology the same as
>>>>>>>>>>>>>>>>> when we know that X is a black cat then we know that X
>>>>>>>>>>>>>>>>> is a cat.
>>>>>>>>>>>>>>>> We are talking about Px, not P. We are talking about
>>>>>>>>>>>>>>>> your H not analysing what its input actually does and
>>>>>>>>>>>>>>>> instead assuming that an input that calls H is always
>>>>>>>>>>>>>>>> pathological.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Px(u32 x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>         H(x, x);
>>>>>>>>>>>>>>>>         return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>         Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ...[000013e8][00102357][00000000] 83c408          add
>>>>>>>>>>>>>>>> esp,+08 ...[000013eb][00102353][00000000] 50
>>>>>>>>>>>>>>>> push eax ...[000013ec][0010234f][00000427] 6827040000
>>>>>>>>>>>>>>>> push 00000427 ---[000013f1][0010234f][00000427]
>>>>>>>>>>>>>>>> e880f0ffff call 00000476 Input_Halts = 0
>>>>>>>>>>>>>>>> ...[000013f6][00102357][00000000] 83c408          add
>>>>>>>>>>>>>>>> esp,+08 ...[000013f9][00102357][00000000] 33c0
>>>>>>>>>>>>>>>> xor eax,eax ...[000013fb][0010235b][00100000] 5d
>>>>>>>>>>>>>>>>     pop ebp ...[000013fc][0010235f][00000004] c3
>>>>>>>>>>>>>>>> ret Number of Instructions Executed(16120)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It gets the answer wrong, i.e. input has not been
>>>>>>>>>>>>>>>> decided correctly. QED.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> DO YOU AGREE WITH THIS?
>>>>>>>>>>>>>>> H(Px,Px) does correctly determine that the complete and
>>>>>>>>>>>>>>> correct x86 emulation of its input would never reach the
>>>>>>>>>>>>>>> "ret" instruction of Px.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is only true if H never returns ANY answer (and thus
>>>>>>>>>>>>>> fails to be a decider).
>>>>>>>>>>>>> Competent software engineers will understand that when the
>>>>>>>>>>>>> behavior of Px matches this pattern that correct and
>>>>>>>>>>>>> complete x86 emulation of the input to H(Px,Px) by H would
>>>>>>>>>>>>> never reach the "ret" instruction of Px:
>>>>>>>>>>>>>
>>>>>>>>>>>>> H knows its own machine address and on this basis:
>>>>>>>>>>>>> (a) H recognizes that Px is calling H with the same
>>>>>>>>>>>>> arguments that H was called with.
>>>>>>>>>>>>> (b) There are no instructions in Px that could possibly
>>>>>>>>>>>>> escape this infinitely recursive emulation.
>>>>>>>>>>>>> (c) H aborts its emulation of Px before Px its call to H is
>>>>>>>>>>>>> invoked.
>>>>>>>>>>>>
>>>>>>>>>>>> Only if H never aborts. If H does abort, then Px(Px), whose
>>>>>>>>>>>> behavior exactly matches the CORRECT emulation of the input
>>>>>>>>>>>> to H(Px,Px) BY DEFINITION shows this.
>>>>>>>>>>>
>>>>>>>>>>> The question is: Would (future tense) the complete and
>>>>>>>>>>> correct x86 emulation of the input to H(Px,Px) by H ever
>>>>>>>>>>> reach the "ret" instruction of Px.
>>>>>>>>>>>
>>>>>>>>>>> You always change this question to a different question:
>>>>>>>>>>>
>>>>>>>>>>> Does (present tense) the complete and correct x86 emulation
>>>>>>>>>>> of the input to H(Px,Px) by H ever reach the "ret"
>>>>>>>>>>> instruction of Px.
>>>>>>>>>>
>>>>>>>>>> The complete and correct x86 emulation of the input to H(Px,
>>>>>>>>>> Px) should be to allow Px to halt, which is what Px is
>>>>>>>>>> defined to do:
>>>>>>>>>
>>>>>>>>> You are doing the same thing Richard is doing, getting at
>>>>>>>>> least one word of what I am saying incorrectly and then
>>>>>>>>> rebutting the incorrect paraphrase. This is the strawman error.
>>>>>>>>>
>>>>>>>>> The complete and correct x86 emulation of the input to H(Px,
>>>>>>>>> Px) BY H
>>>>>>>>> BY H
>>>>>>>>> BY H
>>>>>>>>> BY H
>>>>>>>>> BY H
>>>>>>>>>
>>>>>>>>> cannot possibly contradict the easily verified fact that Px
>>>>>>>>> would never reach its "ret" instruction. This seems to be
>>>>>>>>> beyond your ordinary software engineering technical
>>>>>>>>> competence.
>>>>>>>> Px is defined to always halt; your H gets the answer wrong
>>>>>>>> saying Px doesn't halt. QED.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Every technically competent software engineer can easily confirm
>>>>>>> that the correct and complete x86 emulation of the input to
>>>>>>> H(Px,Px) by H would never reach the "ret" instruction of Px.
>>>>>>>
>>>>>>> That you can not understand this proves that you are not a
>>>>>>> sufficiently technically competent software engineer on this
>>>>>>> point. Very good COBOL programmers might never be able to
>>>>>>> understand this.
>>>>>>>
>>>>>>> To anyone that writes or maintains operating systems what I am
>>>>>>> claiming would be as easy to verify as first grade arithmetic.
>>>>>> void Px(u32 x)
>>>>>> {
>>>>>>      H(x, x);
>>>>>>      return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>      Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>> }
>>>>>>
>>>>>> ...[000013e8][00102357][00000000] 83c408          add esp,+08
>>>>>> ...[000013eb][00102353][00000000] 50              push eax
>>>>>> ...[000013ec][0010234f][00000427] 6827040000      push 00000427
>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
>>>>>> Input_Halts = 0
>>>>>> ...[000013f6][00102357][00000000] 83c408          add esp,+08
>>>>>> ...[000013f9][00102357][00000000] 33c0            xor eax,eax
>>>>>> ...[000013fb][0010235b][00100000] 5d              pop ebp
>>>>>> ...[000013fc][0010235f][00000004] c3              ret
>>>>>> Number of Instructions Executed(16120)
>>>>>>
>>>>>> It gets the answer wrong, i.e. input has not been decided
>>>>>> correctly. QED.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> Get an operating system programmer to explain to you that the
>>>>> correct and complete x86 emulation of the input to H(Px,Px) by H
>>>>> would never reach the "ret" instruction of Px. *This is totally
>>>>> over your head*
>>>>>
>>>>> It is like I am saying that we know that black carts are cats and
>>>>> you disagree saying the a black cat might be some kind of dog.
>>>>>
>>>>> My whole system is now wrapped in 131K zip file as a Visual Studio
>>>>> project on a downloadable link.
>>>>
>>>> No, maybe you need an actual programmer to look at your logic.
>>>>
>>>> First, by definition correct emulation of a program will match the
>>>> behavior of the program.
>>>
>>> When you disagree with this precisely stated verified fact you are
>>> either a liar or incompetent:
>>>
>>> the correct and complete x86 emulation of the input to H(Px,Px) by H
>>> would never reach the "ret" instruction
>>>
>>> When you disagree the the above precisely stated verified fact by
>>> changing its words and showing that the changed words are not true
>>> then between liar and incompetent you prove to be a liar.
>> void Px(u32 x)
>> {
>>     H(x, x);
>>     return;
>> }
>>
>> int main()
>> {
>>     Output("Input_Halts = ", H((u32)Px, (u32)Px));
>> }
>>
>> ...[000013e8][00102357][00000000] 83c408          add esp,+08
>> ...[000013eb][00102353][00000000] 50              push eax
>> ...[000013ec][0010234f][00000427] 6827040000      push 00000427
>> ---[000013f1][0010234f][00000427] e880f0ffff      call 00000476
>> Input_Halts = 0
>> ...[000013f6][00102357][00000000] 83c408          add esp,+08
>> ...[000013f9][00102357][00000000] 33c0            xor eax,eax
>> ...[000013fb][0010235b][00100000] 5d              pop ebp
>> ...[000013fc][0010235f][00000004] c3              ret
>> Number of Instructions Executed(16120)
>>
>> It gets the answer wrong, i.e. input has not been decided correctly.
>> QED.
>>
>> /Flibble
>
>
> DOES THAT MEAN THAT YOU ARE SAYING THAT THIS IS FALSE?
> the correct and complete x86 emulation of the input to H(Px,Px) by H
> would never reach the "ret" instruction
>

What he is pointing out is that your statement is nonsense, as if H
returns 0 it didn't do a correct and complete x86 emulation.

You can't have H do BOTH a correct and complete x86 emulation and return
0 at the same "time". One H can't do both unless you know how to do
infinite work in finite time.

SubjectRepliesAuthor
o Halting Problem proof refutation is a tautology thus irrefutable

By: olcott on Sun, 19 Jun 2022

76olcott
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor