Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Those who can't write, write manuals.


devel / comp.theory / Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

SubjectAuthor
* Picking up where Mike Terry left off: Does H(P,P) correctly simulateolcott
+* Picking up where Mike Terry left off: Does H(P,P) correctlyolcott
|`* Picking up where Mike Terry left off: Does H(P,P) correctlyRichard Damon
| `* Picking up where Mike Terry left off: Does H(P,P) correctlyolcott
|  `* Picking up where Mike Terry left off: Does H(P,P) correctlyRichard Damon
|   `* Picking up where Mike Terry left off: Does H(P,P) correctlyolcott
|    `* Picking up where Mike Terry left off: Does H(P,P) correctlyRichard Damon
|     `* Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?olcott
|      +* Picking up where Mike Terry left off: Does H(P,P) correctlyMike Terry
|      |+* Picking up where Mike Terry left off: Does H(P,P) correctlyolcott
|      ||+* Picking up where Mike Terry left off: Does H(P,P) correctlyMike Terry
|      |||`* Picking up where Mike Terry left off: Does H(P,P) correctlyolcott
|      ||| `- Picking up where Mike Terry left off: Does H(P,P) correctlyRichard Damon
|      ||`- Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?Mikko
|      |`- Picking up where Mike Terry left off: Does H(P,P) correctlyJeff Barnett
|      `- Picking up where Mike Terry left off: Does H(P,P) correctlyRichard Damon
`- Picking up where Mike Terry left off: Does H(P,P) correctlywij

1
Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.lang.c comp.lang.c++
Followup: comp.lang.c,comp.lang.c++
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: Sat, 16 Jul 2022 22:11:58 -0500
Date: Sat, 16 Jul 2022 22:11:58 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Newsgroups: comp.theory,comp.lang.c,comp.lang.c++
Content-Language: en-US
From: NoO...@NoWhere.com (olcott)
Subject: Picking up where Mike Terry left off: Does H(P,P) correctly simulate
its input ?
Followup-To: comp.lang.c,comp.lang.c++
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 146
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-biR1Hs69naz8Tbe+14Rr+wihMqISNv5QXUbNvrMF/EjKIEngIRNPBcSo6wtobPTB6KYfemW7+aBjYkj!yU/ZkX6uDbQc3EfeL12dLDQjLdsOQUwZfqbErOAxsXN6EkV+7jIxRPHw161gXfLbGvGerDQ9o5+n!Dw==
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: 7127
 by: olcott - Sun, 17 Jul 2022 03:11 UTC

On 7/16/2022 10:54 AM, Mike Terry wrote:
> On 16/07/2022 12:23, Paul N wrote:
> PO's simulation is correct at the individual instruction level.
> His H steps the simulation forward a number of steps, and each
> of those steps exactly matches the P(P) calculation steps.

We can see from the x86 execution trace of the simulated P that the
behavior of this simulated P exactly matches its x86 source-code,
line-by-line.

What we can also see from this same execution trace is that when H calls
H(P,P) the simulated P remains stuck calling H(P,P) to simulate itself
again thus forever preventing this simulated P from ever terminating
normally by reaching its C:"return" or x86:"ret" instruction.

*H(P,P) correctly determines that its input never halts*

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H(P, P));
}

_P()
[000013c6](01) 55 push ebp // Save Base Pointer
register onto the stack
[000013c7](02) 8bec mov ebp,esp // Load Base Pointer
with Stack Pointer
[000013c9](01) 51 push ecx // Save the value of
ecx on the stack
[000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax with
argument to P
[000013cd](01) 50 push eax // push 2nd argument
to H onto the stack
[000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx with with
argument to P
[000013d1](01) 51 push ecx // push 1st argument
to H onto the stack
[000013d2](05) e82ffdffff call 00001106 // push return address
on the stack; call simulated H
[000013d7](03) 83c408 add esp,+08 // remove call
arguments from stack
[000013da](03) 8945fc mov [ebp-04],eax // load Halt_Status
with return value from H
[000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare Halt_Status
to 0
[000013e1](02) 7402 jz 000013e5 // if Halt_Status == 0
goto 000013e5
[000013e3](02) ebfe jmp 000013e3 // goto 13e3
[000013e5](02) 8be5 mov esp,ebp // Load Stack Pointer
with Base Pointer
[000013e7](01) 5d pop ebp // Restore Base
Pointer value from stack
[000013e8](01) c3 ret // return to caller
Size in bytes:(0035) [000013e8]

_main()
[000013f6](01) 55 push ebp // Save Base Pointer register
onto the stack
[000013f7](02) 8bec mov ebp,esp // Load Base Pointer with Stack
Pointer
[000013f9](05) 68c6130000 push 000013c6 // Push P (2nd argument to H)
onto the stack
[000013fe](05) 68c6130000 push 000013c6 // Push P (1nd argument to H)
onto the stack
[00001403](05) e8fefcffff call 00001106 // push return address onto the
stack and call executed H
[00001408](03) 83c408 add esp,+08 // remove call arguments from
stack frame
[0000140b](01) 50 push eax // Push return value from H
onto the stack
[0000140c](05) 6837050000 push 00000537 // Push address of "Input_Halts
= " onto the stack
[00001411](05) e870f1ffff call 00000586 // call Output with its pushed
arguments.
[00001416](03) 83c408 add esp,+08 // remove call arguments from
stack frame
[00001419](02) 33c0 xor eax,eax // set eax to 0
[0000141b](01) 5d pop ebp // Restore Base Pointer
register from stack
[0000141c](01) c3 ret // return to 0 operating system
Size in bytes:(0039) [0000141c]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000013f6][0010235f][00000000] 55 push ebp
[000013f7][0010235f][00000000] 8bec mov ebp,esp
[000013f9][0010235b][000013c6] 68c6130000 push 000013c6 // Push P (2nd
argument to H) onto the stack
[000013fe][00102357][000013c6] 68c6130000 push 000013c6 // Push P (1nd
argument to H) onto the stack
[00001403][00102353][00001408] e8fefcffff call 00001106 // push return
address; call executed H

H: Begin Simulation Execution Trace Stored at:11240b
Address_of_H:1106
[000013c6][001123f7][001123fb] 55 push ebp
[000013c7][001123f7][001123fb] 8bec mov ebp,esp
[000013c9][001123f3][001023c7] 51 push ecx // Save the
value of ecx on the stack
[000013ca][001123f3][001023c7] 8b4508 mov eax,[ebp+08] // Load eax
with argument to P
[000013cd][001123ef][000013c6] 50 push eax // push 2nd
argument to H onto the stack
[000013ce][001123ef][000013c6] 8b4d08 mov ecx,[ebp+08] // Load ecx
with with argument to P
[000013d1][001123eb][000013c6] 51 push ecx // push 1st
argument to H onto the stack
[000013d2][001123e7][000013d7] e82ffdffff call 00001106 // push
return address; call simulated H
H: Infinitely Recursive Simulation Detected Simulation Stopped

[00001408][0010235f][00000000] 83c408 add esp,+08
[0000140b][0010235b][00000000] 50 push eax // Push return
value from H onto the stack
[0000140c][00102357][00000537] 6837050000 push 00000537 // Push address
of "Input_Halts = " onto stack
[00001411][00102357][00000537] e870f1ffff call 00000586 // call Output
with its pushed arguments
Input_Halts = 0
[00001416][0010235f][00000000] 83c408 add esp,+08
[00001419][0010235f][00000000] 33c0 xor eax,eax // set eax to 0
[0000141b][00102363][00000018] 5d pop ebp
[0000141c][00102367][00000000] c3 ret // return to 0
operating system
Number of Instructions Executed(987) == 15 Pages

--
Copyright 2022 Pete Olcott

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

Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 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, 17 Jul 2022 19:56:34 -0500
Date: Sun, 17 Jul 2022 19:56:33 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <jV_AK.484595$70j.462777@fx16.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 176
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-m59XDfuzhCpTpVGj30LqNatiZtFVVFL49wMyn2a9kEw5zPWijQKHq1+H78KCO4hayDp64l76/2PDkww!MLf2pUVC85Igi9Yqe/artj+Tl3VJyhTMpjFfRObLNRs0VSoe/Gb6nYD2zdEJVnuXKIapcd0kESpH!qg==
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: 9532
 by: olcott - Mon, 18 Jul 2022 00:56 UTC

On 7/17/2022 4:10 PM, Richard Damon wrote:
> On 7/17/22 3:42 PM, olcott wrote:
>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>> On 7/17/22 2:15 PM, olcott wrote:
>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>  > PO's simulation is correct at the individual instruction
>>>>>>>>>> level.
>>>>>>>>>>  > His H steps the simulation forward a number of steps, and each
>>>>>>>>>>  > of those steps exactly matches the P(P) calculation steps.
>>>>>>>>>>
>>>>>>>>>> We can see from the x86 execution trace of the simulated P
>>>>>>>>>> that the behavior of this simulated P exactly matches its x86
>>>>>>>>>> source-code, line-by-line.
>>>>>>>>>>
>>>>>>>>>> What we can also see from this same execution trace is that
>>>>>>>>>> when H calls H(P,P) the simulated P remains stuck calling
>>>>>>>>>> H(P,P) to simulate itself again thus forever preventing this
>>>>>>>>>> simulated P from ever terminating normally by reaching its
>>>>>>>>>> C:"return" or x86:"ret" instruction.
>>>>>>>>>
>>>>>>>>> Except it doesn't because H is KNOWN to abort its simulation
>>>>>>>>> when it sees that the simulation will reach the first call to H
>>>>>>>>> in the simulation.
>>>>>>>>>
>>>>>>>>> You logic is based on the assumption that H actually won't stop
>>>>>>>>> simulating its input, when in actual fact it will. Thus you
>>>>>>>>> have a false premise in your logic, so H never actually proved
>>>>>>>>> its fact considering the H that it is.
>>>>>>>>>
>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a P
>>>>>>>>> that never halts. But since this is NOT the definition of H,
>>>>>>>>> that doesn't say anything about what the machine where H does
>>>>>>>>> abort its simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Halting means terminated normally when the correctly simulated P
>>>>>>>> reaches its last instruction. Even though I have corrected you
>>>>>>>> on this many hundreds of times you still fail to understand that
>>>>>>>> an aborted simulation does not mean that the simulated input
>>>>>>>> halted. You are moronically stupid on this point.
>>>>>>>
>>>>>>> And YOU are the moron for thinking that just because a simulation
>>>>>>> was aborted the CORRECT simulation of that input can't continue
>>>>>>> to reach the final state.
>>>>>>
>>>>>> Your replies are moronically stupid because they always make sure
>>>>>> to maimtain the same false assumptions (utterly impervious to all
>>>>>> reason) even when these false assumptions corrected hundreds of
>>>>>> times.
>>>>>
>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>
>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>  >
>>>>  > I don't believe PO thinks that, irrespective of how badly he
>>>> explains
>>>>  > things.  I think he believes that the simulation would never halt
>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>  > consequence of aborting.  E.g. he seems to understand that a
>>>> simulator
>>>>  > that steps 10 steps then stops regardless, does not imply that the
>>>>  > simulated computation does not halt.
>>>>
>>>>
>>>
>>> SO, whats wrong with my statement.
>>>
>>> An incomplete simulation not reaching a halting state does NOT prove
>>> that the input is non-halting.
>>>
>> *Yes it does, this is simply over your head*
>> Once a non-halting behavior pattern is correctly matched the
>> simulation can be aborted and the input rejected as non-halting.
>>
>
> No, you are totally wrong on that. If you say I am mistaken, which of
> these statements, which PROVE my point, is in error? If none are, then
> my statement is PROVEN. Note, these are based on the well established
> definition of Computation Theory and statement YOU have made about your
> program.
>
> Just claiming you have proven the opposite is NOT enough, as all that
> does is show that your logic system is inconsistent, because you have
> added inconsistent rules to your system (likely rules that just aren't
> true).
>
> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be
> returning 0.
>
> 2) P calls H(P,P)
>

P is aborted before the call is ever made.
This seems to be the key to overcome referential transparency.

> 3) P, as the impossible program, is defined to as H about the behavior
> or itself with its input
>
> 4) This means the call to H(P,P) is defined to be asking H about the
> behavor of P(P)
>
> 5) The ACTUAL program P(P) when run, will return (aka Halt) if H(P,P)
> returns 0.  You have admited this and even posted traces of this.
>

So again you reject that a UTM is a coherent concept.
The correct simulation of a machine <is> computationally equivalent to
the underlying computation.

> 6) The definition of a correct simulation is a simulation that matches
> the behavior of the thing it is simulationg.
>
> 7) Therefore, since the input to H(P,P) refers to P(P) (by 4), and P(P)
> is proved to halt if H(P,P) returns 0 (by 5), by the definition of
> correct simulation, the correct simulation of the input to H(P,P) must
> halt.
>
> 8) Thus, by either the REAL definition that H needs to answer based on
> the behavior of the actual machine, or by the alternate acceptable
> definition that looks at a correct and complete simulation of the input,
> the input to H(P,P) Halts, and thus the CORRECT answer is
> Accept/Halitng/1 not the 0 it provided.

>
> Your problem is that you say "Once" the non-halting pattern is correctly
> detected, which implies that there IS a finite non-halting pattern in
> the simulation of P(P) that can be detected.
>
> It has be PROVEN that ANY pattern ih the simulation of P(P) by H that is
> added to H as a claimed non-halting pattern, then that make the behavior
> of that P(P) (and the correct simulation of the input to H(P,P)) to be
> Halting, as when H detects that pattern in its simulation of P(P), and
> returns to P, P will return (aka halt) and then when we look at the
> CORRECT AND COMPLETE simulation of the input, we see that shortly after
> H INCORRECTLY gave up convinced that the input was non-halting, that the
> simulation then sees (as it simulates H) the simulated H making that
> decision, and returning to the P that called that simulated H, and that
> P then returning (aka Halting).
>
> Thus, there does not exist a finite pattern that H can reach in finite
> time to detect.
>
> Thus, H either simulates forever and fails to be a decider, or uses an
> invalid pattern and incorrectly determines non-halting and gives the
> wrong anwwer.
>
> You are presuming the existance of something not known to exist (and in
> fact proven to not exist).

That you simply don't have the technical skills to understand what I am
saying is no rebuttal at all.


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<2G2BK.47678$vd2.20719@fx39.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx39.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.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 231
Message-ID: <2G2BK.47678$vd2.20719@fx39.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, 17 Jul 2022 21:27:20 -0400
X-Received-Bytes: 11478
 by: Richard Damon - Mon, 18 Jul 2022 01:27 UTC

On 7/17/22 8:56 PM, olcott wrote:
> On 7/17/2022 4:10 PM, Richard Damon wrote:
>> On 7/17/22 3:42 PM, olcott wrote:
>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>  > PO's simulation is correct at the individual instruction
>>>>>>>>>>> level.
>>>>>>>>>>>  > His H steps the simulation forward a number of steps, and
>>>>>>>>>>> each
>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation steps.
>>>>>>>>>>>
>>>>>>>>>>> We can see from the x86 execution trace of the simulated P
>>>>>>>>>>> that the behavior of this simulated P exactly matches its x86
>>>>>>>>>>> source-code, line-by-line.
>>>>>>>>>>>
>>>>>>>>>>> What we can also see from this same execution trace is that
>>>>>>>>>>> when H calls H(P,P) the simulated P remains stuck calling
>>>>>>>>>>> H(P,P) to simulate itself again thus forever preventing this
>>>>>>>>>>> simulated P from ever terminating normally by reaching its
>>>>>>>>>>> C:"return" or x86:"ret" instruction.
>>>>>>>>>>
>>>>>>>>>> Except it doesn't because H is KNOWN to abort its simulation
>>>>>>>>>> when it sees that the simulation will reach the first call to
>>>>>>>>>> H in the simulation.
>>>>>>>>>>
>>>>>>>>>> You logic is based on the assumption that H actually won't
>>>>>>>>>> stop simulating its input, when in actual fact it will. Thus
>>>>>>>>>> you have a false premise in your logic, so H never actually
>>>>>>>>>> proved its fact considering the H that it is.
>>>>>>>>>>
>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a P
>>>>>>>>>> that never halts. But since this is NOT the definition of H,
>>>>>>>>>> that doesn't say anything about what the machine where H does
>>>>>>>>>> abort its simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Halting means terminated normally when the correctly simulated
>>>>>>>>> P reaches its last instruction. Even though I have corrected
>>>>>>>>> you on this many hundreds of times you still fail to understand
>>>>>>>>> that an aborted simulation does not mean that the simulated
>>>>>>>>> input halted. You are moronically stupid on this point.
>>>>>>>>
>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>> simulation was aborted the CORRECT simulation of that input
>>>>>>>> can't continue to reach the final state.
>>>>>>>
>>>>>>> Your replies are moronically stupid because they always make sure
>>>>>>> to maimtain the same false assumptions (utterly impervious to all
>>>>>>> reason) even when these false assumptions corrected hundreds of
>>>>>>> times.
>>>>>>
>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>
>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>  >
>>>>>  > I don't believe PO thinks that, irrespective of how badly he
>>>>> explains
>>>>>  > things.  I think he believes that the simulation would never halt
>>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>>  > consequence of aborting.  E.g. he seems to understand that a
>>>>> simulator
>>>>>  > that steps 10 steps then stops regardless, does not imply that the
>>>>>  > simulated computation does not halt.
>>>>>
>>>>>
>>>>
>>>> SO, whats wrong with my statement.
>>>>
>>>> An incomplete simulation not reaching a halting state does NOT prove
>>>> that the input is non-halting.
>>>>
>>> *Yes it does, this is simply over your head*
>>> Once a non-halting behavior pattern is correctly matched the
>>> simulation can be aborted and the input rejected as non-halting.
>>>
>>
>> No, you are totally wrong on that. If you say I am mistaken, which of
>> these statements, which PROVE my point, is in error? If none are, then
>> my statement is PROVEN. Note, these are based on the well established
>> definition of Computation Theory and statement YOU have made about
>> your program.
>>
>> Just claiming you have proven the opposite is NOT enough, as all that
>> does is show that your logic system is inconsistent, because you have
>> added inconsistent rules to your system (likely rules that just aren't
>> true).
>>
>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be
>> returning 0.
>>
>> 2) P calls H(P,P)
>>
>
> P is aborted before the call is ever made.
> This seems to be the key to overcome referential transparency.

Just you proving your an idiot, and not reading?

That was saying that the SOURCE CODE of P calls H(P,P)

There IS no "Aborts" at the source code level.

And then in 5, we are talking about the direct execution of P(P)
(perhaps by a call to it in main) and H can't abort THAT invocation of P
without ending up not answering when main calls H(P,P), unless your H
fails to be a Pure Function.

Your mind just isn't thinking but throwing out rote responses that just
don't make sense.

WHO is acting ROTELY. Not us "Learned by Rote" people who understand
what we are talking about.

>
>> 3) P, as the impossible program, is defined to as H about the behavior
>> or itself with its input
>>
>> 4) This means the call to H(P,P) is defined to be asking H about the
>> behavor of P(P)
>>
>> 5) The ACTUAL program P(P) when run, will return (aka Halt) if H(P,P)
>> returns 0.  You have admited this and even posted traces of this.
>>
>
> So again you reject that a UTM is a coherent concept.
> The correct simulation of a machine <is> computationally equivalent to
> the underlying computation.

Not at all, but a UTM is only defined in terms of it matching the actual
behavior of the actual machine.

or, is the problem that in your world we don't actually have any actual
machhines, but only simuations of them?

Are you disagreeing that you actually posted a trace of the running of
main calling P(P), and that P(P) calling H(P,P) and then that H
returning the value 0 to that P that called it and it returning?

THAT TRACE shows the actual behavior of P (within the errors that you
don't actually trace what happens in H, but summarize it).

BY DEFINITION, UTM(P,P) must generate the same results as P(P), or it
isn't a UTM. You seem to have a problem with that definition.

>
>> 6) The definition of a correct simulation is a simulation that matches
>> the behavior of the thing it is simulationg.
>>
>> 7) Therefore, since the input to H(P,P) refers to P(P) (by 4), and
>> P(P) is proved to halt if H(P,P) returns 0 (by 5), by the definition
>> of correct simulation, the correct simulation of the input to H(P,P)
>> must halt.
>>
>> 8) Thus, by either the REAL definition that H needs to answer based on
>> the behavior of the actual machine, or by the alternate acceptable
>> definition that looks at a correct and complete simulation of the
>> input, the input to H(P,P) Halts, and thus the CORRECT answer is
>> Accept/Halitng/1 not the 0 it provided.
>
>
>
>>
>> Your problem is that you say "Once" the non-halting pattern is
>> correctly detected, which implies that there IS a finite non-halting
>> pattern in the simulation of P(P) that can be detected.
>>
>> It has be PROVEN that ANY pattern ih the simulation of P(P) by H that
>> is added to H as a claimed non-halting pattern, then that make the
>> behavior of that P(P) (and the correct simulation of the input to
>> H(P,P)) to be Halting, as when H detects that pattern in its
>> simulation of P(P), and returns to P, P will return (aka halt) and
>> then when we look at the CORRECT AND COMPLETE simulation of the input,
>> we see that shortly after H INCORRECTLY gave up convinced that the
>> input was non-halting, that the simulation then sees (as it simulates
>> H) the simulated H making that decision, and returning to the P that
>> called that simulated H, and that P then returning (aka Halting).
>>
>> Thus, there does not exist a finite pattern that H can reach in finite
>> time to detect.
>>
>> Thus, H either simulates forever and fails to be a decider, or uses an
>> invalid pattern and incorrectly determines non-halting and gives the
>> wrong anwwer.
>>
>> You are presuming the existance of something not known to exist (and
>> in fact proven to not exist).
>
> That you simply don't have the technical skills to understand what I am
> saying is no rebuttal at all.


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 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, 17 Jul 2022 20:48:44 -0500
Date: Sun, 17 Jul 2022 20:48:44 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <2G2BK.47678$vd2.20719@fx39.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 123
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-fNsuAnudDJXOsdYoM+ykZqlYPGO82OROzIA9qXKECs+mBs2NvyUytEKWMmRbAOtyx/J9ik7yneUpGl5!T8JnBwEAYkbju0QQ7EKoj2G/3B4erNCAuggesv5pvOFacKC8SCDKrJU2AlXuwNsO7iCBsbieTkHh!9Q==
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: 7265
 by: olcott - Mon, 18 Jul 2022 01:48 UTC

On 7/17/2022 8:27 PM, Richard Damon wrote:
>
> On 7/17/22 8:56 PM, olcott wrote:
>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>> On 7/17/22 3:42 PM, olcott wrote:
>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>  > PO's simulation is correct at the individual instruction
>>>>>>>>>>>> level.
>>>>>>>>>>>>  > His H steps the simulation forward a number of steps, and
>>>>>>>>>>>> each
>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation steps.
>>>>>>>>>>>>
>>>>>>>>>>>> We can see from the x86 execution trace of the simulated P
>>>>>>>>>>>> that the behavior of this simulated P exactly matches its
>>>>>>>>>>>> x86 source-code, line-by-line.
>>>>>>>>>>>>
>>>>>>>>>>>> What we can also see from this same execution trace is that
>>>>>>>>>>>> when H calls H(P,P) the simulated P remains stuck calling
>>>>>>>>>>>> H(P,P) to simulate itself again thus forever preventing this
>>>>>>>>>>>> simulated P from ever terminating normally by reaching its
>>>>>>>>>>>> C:"return" or x86:"ret" instruction.
>>>>>>>>>>>
>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its simulation
>>>>>>>>>>> when it sees that the simulation will reach the first call to
>>>>>>>>>>> H in the simulation.
>>>>>>>>>>>
>>>>>>>>>>> You logic is based on the assumption that H actually won't
>>>>>>>>>>> stop simulating its input, when in actual fact it will. Thus
>>>>>>>>>>> you have a false premise in your logic, so H never actually
>>>>>>>>>>> proved its fact considering the H that it is.
>>>>>>>>>>>
>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a P
>>>>>>>>>>> that never halts. But since this is NOT the definition of H,
>>>>>>>>>>> that doesn't say anything about what the machine where H does
>>>>>>>>>>> abort its simulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Halting means terminated normally when the correctly simulated
>>>>>>>>>> P reaches its last instruction. Even though I have corrected
>>>>>>>>>> you on this many hundreds of times you still fail to
>>>>>>>>>> understand that an aborted simulation does not mean that the
>>>>>>>>>> simulated input halted. You are moronically stupid on this point.
>>>>>>>>>
>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>> simulation was aborted the CORRECT simulation of that input
>>>>>>>>> can't continue to reach the final state.
>>>>>>>>
>>>>>>>> Your replies are moronically stupid because they always make
>>>>>>>> sure to maimtain the same false assumptions (utterly impervious
>>>>>>>> to all reason) even when these false assumptions corrected
>>>>>>>> hundreds of times.
>>>>>>>
>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>
>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>  >
>>>>>>  > I don't believe PO thinks that, irrespective of how badly he
>>>>>> explains
>>>>>>  > things.  I think he believes that the simulation would never halt
>>>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>>>  > consequence of aborting.  E.g. he seems to understand that a
>>>>>> simulator
>>>>>>  > that steps 10 steps then stops regardless, does not imply that the
>>>>>>  > simulated computation does not halt.
>>>>>>
>>>>>>
>>>>>
>>>>> SO, whats wrong with my statement.
>>>>>
>>>>> An incomplete simulation not reaching a halting state does NOT
>>>>> prove that the input is non-halting.
>>>>>
>>>> *Yes it does, this is simply over your head*
>>>> Once a non-halting behavior pattern is correctly matched the
>>>> simulation can be aborted and the input rejected as non-halting.
>>>>
>>>
>>> No, you are totally wrong on that. If you say I am mistaken, which of
>>> these statements, which PROVE my point, is in error? If none are,
>>> then my statement is PROVEN. Note, these are based on the well
>>> established definition of Computation Theory and statement YOU have
>>> made about your program.
>>>
>>> Just claiming you have proven the opposite is NOT enough, as all that
>>> does is show that your logic system is inconsistent, because you have
>>> added inconsistent rules to your system (likely rules that just
>>> aren't true).
>>>
>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be
>>> returning 0.
>>>
>>> 2) P calls H(P,P)
>>>
>>
>> P is aborted before the call is ever made.
>> This seems to be the key to overcome referential transparency.
>
> Just you proving your an idiot, and not reading?
>
> That was saying that the SOURCE CODE of P calls H(P,P)
>
> There IS no "Aborts" at the source code level.
We have been talking about this for many months and you haven't noticed
that H operates at the machine language level?

--
Copyright 2022 Pete Olcott

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

Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<cX3BK.486740$J0r9.190196@fx11.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.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.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 156
Message-ID: <cX3BK.486740$J0r9.190196@fx11.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, 17 Jul 2022 22:53:59 -0400
X-Received-Bytes: 8652
 by: Richard Damon - Mon, 18 Jul 2022 02:53 UTC

On 7/17/22 9:48 PM, olcott wrote:
> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>
>> On 7/17/22 8:56 PM, olcott wrote:
>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>  > PO's simulation is correct at the individual instruction
>>>>>>>>>>>>> level.
>>>>>>>>>>>>>  > His H steps the simulation forward a number of steps,
>>>>>>>>>>>>> and each
>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can see from the x86 execution trace of the simulated P
>>>>>>>>>>>>> that the behavior of this simulated P exactly matches its
>>>>>>>>>>>>> x86 source-code, line-by-line.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What we can also see from this same execution trace is that
>>>>>>>>>>>>> when H calls H(P,P) the simulated P remains stuck calling
>>>>>>>>>>>>> H(P,P) to simulate itself again thus forever preventing
>>>>>>>>>>>>> this simulated P from ever terminating normally by reaching
>>>>>>>>>>>>> its C:"return" or x86:"ret" instruction.
>>>>>>>>>>>>
>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its simulation
>>>>>>>>>>>> when it sees that the simulation will reach the first call
>>>>>>>>>>>> to H in the simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> You logic is based on the assumption that H actually won't
>>>>>>>>>>>> stop simulating its input, when in actual fact it will. Thus
>>>>>>>>>>>> you have a false premise in your logic, so H never actually
>>>>>>>>>>>> proved its fact considering the H that it is.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a P
>>>>>>>>>>>> that never halts. But since this is NOT the definition of H,
>>>>>>>>>>>> that doesn't say anything about what the machine where H
>>>>>>>>>>>> does abort its simulation.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>> simulated P reaches its last instruction. Even though I have
>>>>>>>>>>> corrected you on this many hundreds of times you still fail
>>>>>>>>>>> to understand that an aborted simulation does not mean that
>>>>>>>>>>> the simulated input halted. You are moronically stupid on
>>>>>>>>>>> this point.
>>>>>>>>>>
>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>> simulation was aborted the CORRECT simulation of that input
>>>>>>>>>> can't continue to reach the final state.
>>>>>>>>>
>>>>>>>>> Your replies are moronically stupid because they always make
>>>>>>>>> sure to maimtain the same false assumptions (utterly impervious
>>>>>>>>> to all reason) even when these false assumptions corrected
>>>>>>>>> hundreds of times.
>>>>>>>>
>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>
>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>  >
>>>>>>>  > I don't believe PO thinks that, irrespective of how badly he
>>>>>>> explains
>>>>>>>  > things.  I think he believes that the simulation would never halt
>>>>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>>>>  > consequence of aborting.  E.g. he seems to understand that a
>>>>>>> simulator
>>>>>>>  > that steps 10 steps then stops regardless, does not imply that
>>>>>>> the
>>>>>>>  > simulated computation does not halt.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> SO, whats wrong with my statement.
>>>>>>
>>>>>> An incomplete simulation not reaching a halting state does NOT
>>>>>> prove that the input is non-halting.
>>>>>>
>>>>> *Yes it does, this is simply over your head*
>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>> simulation can be aborted and the input rejected as non-halting.
>>>>>
>>>>
>>>> No, you are totally wrong on that. If you say I am mistaken, which
>>>> of these statements, which PROVE my point, is in error? If none are,
>>>> then my statement is PROVEN. Note, these are based on the well
>>>> established definition of Computation Theory and statement YOU have
>>>> made about your program.
>>>>
>>>> Just claiming you have proven the opposite is NOT enough, as all
>>>> that does is show that your logic system is inconsistent, because
>>>> you have added inconsistent rules to your system (likely rules that
>>>> just aren't true).
>>>>
>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be
>>>> returning 0.
>>>>
>>>> 2) P calls H(P,P)
>>>>
>>>
>>> P is aborted before the call is ever made.
>>> This seems to be the key to overcome referential transparency.
>>
>> Just you proving your an idiot, and not reading?
>>
>> That was saying that the SOURCE CODE of P calls H(P,P)
>>
>> There IS no "Aborts" at the source code level.
> We have been talking about this for many months and you haven't noticed
> that H operates at the machine language level?
>

But the code for P was still specified at a source code level.

You keep on trying to say that the behavior of the input to H(P,P)
doesn't match the behavior of P(P), but the point you miss is that then
your code for P is wrong.

Read your definition of what P does, P asks H about what it does with
its input, and you coded that as H(P,P).

That means, that if the input to H(P,P) doesn't actually represent P(P),
you need to fix your definitoin of P to actually ask H about P(P).

If you can't ask H about P(P), then it can't be giving the correct
halting problem answer for that machine, can it.

Remember, the Halting Problem is DEFINED based on H answering about A
MACHINE and its INPUT, based on being given a representation of that
machine and input.

If there is a machine you can't give it, it just fails to be the needed
decider for that machine, and thus CAN'T be the decider that decides for
ALL MACHINES AND INPUTS.


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 17 Jul 2022 22:45:29 -0500
Date: Sun, 17 Jul 2022 22:45:29 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <cX3BK.486740$J0r9.190196@fx11.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 141
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-tDuZ0FM34zJHfBRMzjT6wdIM4X44ip6bOkVM3j8pG2G8Rbs2qG/ZLydjif39C9t+mznnhyam5UbXZBH!CkFr+JGLZD7LvnCkBrgSAVvVf9T0z9qUUqEupcetRjkGE0TKy8ghAGAsEI4FCUfefrdg5Avh40ih!tg==
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: 8233
X-Received-Bytes: 8355
 by: olcott - Mon, 18 Jul 2022 03:45 UTC

On 7/17/2022 9:53 PM, Richard Damon wrote:
> On 7/17/22 9:48 PM, olcott wrote:
>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>
>>> On 7/17/22 8:56 PM, olcott wrote:
>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>  > His H steps the simulation forward a number of steps,
>>>>>>>>>>>>>> and each
>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation steps.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We can see from the x86 execution trace of the simulated P
>>>>>>>>>>>>>> that the behavior of this simulated P exactly matches its
>>>>>>>>>>>>>> x86 source-code, line-by-line.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What we can also see from this same execution trace is
>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck
>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever
>>>>>>>>>>>>>> preventing this simulated P from ever terminating normally
>>>>>>>>>>>>>> by reaching its C:"return" or x86:"ret" instruction.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>> simulation when it sees that the simulation will reach the
>>>>>>>>>>>>> first call to H in the simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You logic is based on the assumption that H actually won't
>>>>>>>>>>>>> stop simulating its input, when in actual fact it will.
>>>>>>>>>>>>> Thus you have a false premise in your logic, so H never
>>>>>>>>>>>>> actually proved its fact considering the H that it is.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a
>>>>>>>>>>>>> P that never halts. But since this is NOT the definition of
>>>>>>>>>>>>> H, that doesn't say anything about what the machine where H
>>>>>>>>>>>>> does abort its simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>> simulated P reaches its last instruction. Even though I have
>>>>>>>>>>>> corrected you on this many hundreds of times you still fail
>>>>>>>>>>>> to understand that an aborted simulation does not mean that
>>>>>>>>>>>> the simulated input halted. You are moronically stupid on
>>>>>>>>>>>> this point.
>>>>>>>>>>>
>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>> simulation was aborted the CORRECT simulation of that input
>>>>>>>>>>> can't continue to reach the final state.
>>>>>>>>>>
>>>>>>>>>> Your replies are moronically stupid because they always make
>>>>>>>>>> sure to maimtain the same false assumptions (utterly
>>>>>>>>>> impervious to all reason) even when these false assumptions
>>>>>>>>>> corrected hundreds of times.
>>>>>>>>>
>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>
>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>  >
>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly he
>>>>>>>> explains
>>>>>>>>  > things.  I think he believes that the simulation would never
>>>>>>>> halt
>>>>>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>>>>>  > consequence of aborting.  E.g. he seems to understand that a
>>>>>>>> simulator
>>>>>>>>  > that steps 10 steps then stops regardless, does not imply
>>>>>>>> that the
>>>>>>>>  > simulated computation does not halt.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> SO, whats wrong with my statement.
>>>>>>>
>>>>>>> An incomplete simulation not reaching a halting state does NOT
>>>>>>> prove that the input is non-halting.
>>>>>>>
>>>>>> *Yes it does, this is simply over your head*
>>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>>> simulation can be aborted and the input rejected as non-halting.
>>>>>>
>>>>>
>>>>> No, you are totally wrong on that. If you say I am mistaken, which
>>>>> of these statements, which PROVE my point, is in error? If none
>>>>> are, then my statement is PROVEN. Note, these are based on the well
>>>>> established definition of Computation Theory and statement YOU have
>>>>> made about your program.
>>>>>
>>>>> Just claiming you have proven the opposite is NOT enough, as all
>>>>> that does is show that your logic system is inconsistent, because
>>>>> you have added inconsistent rules to your system (likely rules that
>>>>> just aren't true).
>>>>>
>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be
>>>>> returning 0.
>>>>>
>>>>> 2) P calls H(P,P)
>>>>>
>>>>
>>>> P is aborted before the call is ever made.
>>>> This seems to be the key to overcome referential transparency.
>>>
>>> Just you proving your an idiot, and not reading?
>>>
>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>
>>> There IS no "Aborts" at the source code level.
>> We have been talking about this for many months and you haven't
>> noticed that H operates at the machine language level?
>>
>
> But the code for P was still specified at a source code level.
>
> You keep on trying to say that the behavior of the input to H(P,P)
> doesn't match the behavior of P(P), but the point you miss is that then
> your code for P is wrong.

You are simply too stupid to verify that facts to prove that it is correct.

*Halting problem proofs refuted on the basis of software engineering*

https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<2be41d2b-f8b9-4a1e-84c3-11634657e87cn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:1cc9:b0:473:2f6:22f8 with SMTP id g9-20020a0562141cc900b0047302f622f8mr19899388qvd.22.1658120455968;
Sun, 17 Jul 2022 22:00:55 -0700 (PDT)
X-Received: by 2002:a25:4051:0:b0:66e:a2c9:3dfd with SMTP id
n78-20020a254051000000b0066ea2c93dfdmr24886540yba.99.1658120455780; Sun, 17
Jul 2022 22:00:55 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Sun, 17 Jul 2022 22:00:55 -0700 (PDT)
In-Reply-To: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=A1PyIwoAAACCahK0CVYFlDZG8JWzz_Go
NNTP-Posting-Host: 124.218.76.41
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2be41d2b-f8b9-4a1e-84c3-11634657e87cn@googlegroups.com>
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 18 Jul 2022 05:00:55 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 44
 by: wij - Mon, 18 Jul 2022 05:00 UTC

On Sunday, 17 July 2022 at 11:12:06 UTC+8, olcott wrote:
> On 7/16/2022 10:54 AM, Mike Terry wrote:
> > On 16/07/2022 12:23, Paul N wrote:
> > PO's simulation is correct at the individual instruction level.
> > His H steps the simulation forward a number of steps, and each
> > of those steps exactly matches the P(P) calculation steps.
>
> We can see from the x86 execution trace of the simulated P that the
> behavior of this simulated P exactly matches its x86 source-code,
> line-by-line.
>
> What we can also see from this same execution trace is that when H calls
> H(P,P) the simulated P remains stuck calling H(P,P) to simulate itself
> again thus forever preventing this simulated P from ever terminating
> normally by reaching its C:"return" or x86:"ret" instruction.
>
> *H(P,P) correctly determines that its input never halts*
>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>

Quote from a CS talented expert:

|As can be seen above Olcott's H decides that Px does not halt but it is
|obvious that Px should always halt if H is a valid halt decider that
|always returns a decision to its caller (Px). Olcott's H does not
|return a decision to its caller (Px) and is thus invalid.
| |/Flibble

Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<S%aBK.57712$sZ1.46897@fx07.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.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.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 150
Message-ID: <S%aBK.57712$sZ1.46897@fx07.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: Mon, 18 Jul 2022 06:56:49 -0400
X-Received-Bytes: 8399
 by: Richard Damon - Mon, 18 Jul 2022 10:56 UTC

On 7/17/22 11:45 PM, olcott wrote:
> On 7/17/2022 9:53 PM, Richard Damon wrote:
>> On 7/17/22 9:48 PM, olcott wrote:
>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>
>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of steps,
>>>>>>>>>>>>>>> and each
>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation
>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can see from the x86 execution trace of the simulated
>>>>>>>>>>>>>>> P that the behavior of this simulated P exactly matches
>>>>>>>>>>>>>>> its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What we can also see from this same execution trace is
>>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck
>>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever
>>>>>>>>>>>>>>> preventing this simulated P from ever terminating
>>>>>>>>>>>>>>> normally by reaching its C:"return" or x86:"ret"
>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>>> simulation when it sees that the simulation will reach the
>>>>>>>>>>>>>> first call to H in the simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You logic is based on the assumption that H actually won't
>>>>>>>>>>>>>> stop simulating its input, when in actual fact it will.
>>>>>>>>>>>>>> Thus you have a false premise in your logic, so H never
>>>>>>>>>>>>>> actually proved its fact considering the H that it is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a
>>>>>>>>>>>>>> P that never halts. But since this is NOT the definition
>>>>>>>>>>>>>> of H, that doesn't say anything about what the machine
>>>>>>>>>>>>>> where H does abort its simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>>> simulated P reaches its last instruction. Even though I
>>>>>>>>>>>>> have corrected you on this many hundreds of times you still
>>>>>>>>>>>>> fail to understand that an aborted simulation does not mean
>>>>>>>>>>>>> that the simulated input halted. You are moronically stupid
>>>>>>>>>>>>> on this point.
>>>>>>>>>>>>
>>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that input
>>>>>>>>>>>> can't continue to reach the final state.
>>>>>>>>>>>
>>>>>>>>>>> Your replies are moronically stupid because they always make
>>>>>>>>>>> sure to maimtain the same false assumptions (utterly
>>>>>>>>>>> impervious to all reason) even when these false assumptions
>>>>>>>>>>> corrected hundreds of times.
>>>>>>>>>>
>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>
>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>>  >
>>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly he
>>>>>>>>> explains
>>>>>>>>>  > things.  I think he believes that the simulation would never
>>>>>>>>> halt
>>>>>>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand that a
>>>>>>>>> simulator
>>>>>>>>>  > that steps 10 steps then stops regardless, does not imply
>>>>>>>>> that the
>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>
>>>>>>>> An incomplete simulation not reaching a halting state does NOT
>>>>>>>> prove that the input is non-halting.
>>>>>>>>
>>>>>>> *Yes it does, this is simply over your head*
>>>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>>>> simulation can be aborted and the input rejected as non-halting.
>>>>>>>
>>>>>>
>>>>>> No, you are totally wrong on that. If you say I am mistaken, which
>>>>>> of these statements, which PROVE my point, is in error? If none
>>>>>> are, then my statement is PROVEN. Note, these are based on the
>>>>>> well established definition of Computation Theory and statement
>>>>>> YOU have made about your program.
>>>>>>
>>>>>> Just claiming you have proven the opposite is NOT enough, as all
>>>>>> that does is show that your logic system is inconsistent, because
>>>>>> you have added inconsistent rules to your system (likely rules
>>>>>> that just aren't true).
>>>>>>
>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually
>>>>>> be returning 0.
>>>>>>
>>>>>> 2) P calls H(P,P)
>>>>>>
>>>>>
>>>>> P is aborted before the call is ever made.
>>>>> This seems to be the key to overcome referential transparency.
>>>>
>>>> Just you proving your an idiot, and not reading?
>>>>
>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>
>>>> There IS no "Aborts" at the source code level.
>>> We have been talking about this for many months and you haven't
>>> noticed that H operates at the machine language level?
>>>
>>
>> But the code for P was still specified at a source code level.
>>
>> You keep on trying to say that the behavior of the input to H(P,P)
>> doesn't match the behavior of P(P), but the point you miss is that
>> then your code for P is wrong.
>
> You are simply too stupid to verify that facts to prove that it is correct.
>
> *Halting problem proofs refuted on the basis of software engineering*
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 18 Jul 2022 08:03:17 -0500
Date: Mon, 18 Jul 2022 08:03:17 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com> <mwSAK.484483$J0r9.388519@fx11.iad> <2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com> <jZWAK.577488$JVi.507916@fx17.iad> <GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com> <R9XAK.57708$sZ1.6803@fx07.iad> <LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com> <aiZAK.577919$JVi.241046@fx17.iad> <NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com> <jV_AK.484595$70j.462777@fx16.iad> <jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com> <2G2BK.47678$vd2.20719@fx39.iad> <7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com> <cX3BK.486740$J0r9.190196@fx11.iad> <a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com> <S%aBK.57712$sZ1.46897@fx07.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <S%aBK.57712$sZ1.46897@fx07.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 173
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-80NBJ0+GuFu8wUTYolxkmNqVQeffmeVEZ9RfJUslDYVj+eS6EtzWFCV3MGhLEvLDzciHZ1+5RiVUyRo!lVy7fG1BzSet6etDJ8gY/MYW+1n4O0od6QGP1i+jsSVhZNeXf5LxGDoB+cXo65+sbqnBWz5+CgZ6!eg==
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: 9729
X-Received-Bytes: 9869
 by: olcott - Mon, 18 Jul 2022 13:03 UTC

On 7/18/2022 5:56 AM, Richard Damon wrote:
> On 7/17/22 11:45 PM, olcott wrote:
>> On 7/17/2022 9:53 PM, Richard Damon wrote:
>>> On 7/17/22 9:48 PM, olcott wrote:
>>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>>
>>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of steps,
>>>>>>>>>>>>>>>> and each
>>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation
>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We can see from the x86 execution trace of the simulated
>>>>>>>>>>>>>>>> P that the behavior of this simulated P exactly matches
>>>>>>>>>>>>>>>> its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What we can also see from this same execution trace is
>>>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck
>>>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever
>>>>>>>>>>>>>>>> preventing this simulated P from ever terminating
>>>>>>>>>>>>>>>> normally by reaching its C:"return" or x86:"ret"
>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>>>> simulation when it sees that the simulation will reach
>>>>>>>>>>>>>>> the first call to H in the simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You logic is based on the assumption that H actually
>>>>>>>>>>>>>>> won't stop simulating its input, when in actual fact it
>>>>>>>>>>>>>>> will. Thus you have a false premise in your logic, so H
>>>>>>>>>>>>>>> never actually proved its fact considering the H that it is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes
>>>>>>>>>>>>>>> a P that never halts. But since this is NOT the
>>>>>>>>>>>>>>> definition of H, that doesn't say anything about what the
>>>>>>>>>>>>>>> machine where H does abort its simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>>>> simulated P reaches its last instruction. Even though I
>>>>>>>>>>>>>> have corrected you on this many hundreds of times you
>>>>>>>>>>>>>> still fail to understand that an aborted simulation does
>>>>>>>>>>>>>> not mean that the simulated input halted. You are
>>>>>>>>>>>>>> moronically stupid on this point.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that input
>>>>>>>>>>>>> can't continue to reach the final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Your replies are moronically stupid because they always make
>>>>>>>>>>>> sure to maimtain the same false assumptions (utterly
>>>>>>>>>>>> impervious to all reason) even when these false assumptions
>>>>>>>>>>>> corrected hundreds of times.
>>>>>>>>>>>
>>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>>
>>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>>>  >
>>>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly
>>>>>>>>>> he explains
>>>>>>>>>>  > things.  I think he believes that the simulation would
>>>>>>>>>> never halt
>>>>>>>>>>  > *because his never-halting-abort test matched*, NOT simply
>>>>>>>>>> as a
>>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand that
>>>>>>>>>> a simulator
>>>>>>>>>>  > that steps 10 steps then stops regardless, does not imply
>>>>>>>>>> that the
>>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>>
>>>>>>>>> An incomplete simulation not reaching a halting state does NOT
>>>>>>>>> prove that the input is non-halting.
>>>>>>>>>
>>>>>>>> *Yes it does, this is simply over your head*
>>>>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>>>>> simulation can be aborted and the input rejected as non-halting.
>>>>>>>>
>>>>>>>
>>>>>>> No, you are totally wrong on that. If you say I am mistaken,
>>>>>>> which of these statements, which PROVE my point, is in error? If
>>>>>>> none are, then my statement is PROVEN. Note, these are based on
>>>>>>> the well established definition of Computation Theory and
>>>>>>> statement YOU have made about your program.
>>>>>>>
>>>>>>> Just claiming you have proven the opposite is NOT enough, as all
>>>>>>> that does is show that your logic system is inconsistent, because
>>>>>>> you have added inconsistent rules to your system (likely rules
>>>>>>> that just aren't true).
>>>>>>>
>>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually
>>>>>>> be returning 0.
>>>>>>>
>>>>>>> 2) P calls H(P,P)
>>>>>>>
>>>>>>
>>>>>> P is aborted before the call is ever made.
>>>>>> This seems to be the key to overcome referential transparency.
>>>>>
>>>>> Just you proving your an idiot, and not reading?
>>>>>
>>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>>
>>>>> There IS no "Aborts" at the source code level.
>>>> We have been talking about this for many months and you haven't
>>>> noticed that H operates at the machine language level?
>>>>
>>>
>>> But the code for P was still specified at a source code level.
>>>
>>> You keep on trying to say that the behavior of the input to H(P,P)
>>> doesn't match the behavior of P(P), but the point you miss is that
>>> then your code for P is wrong.
>>
>> You are simply too stupid to verify that facts to prove that it is
>> correct.
>>
>> *Halting problem proofs refuted on the basis of software engineering*
>>
>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>
>>
>
> So, you are admitting that there is no error in my claim and it IS a
> fact that H does not correctly determine to Halting of P(P)?
>
> Then who is the one too stupid to verify facts?
>
> Note, if my proof is correct, and your proof is corret, all this proves
> is that the extra rules you added to your logic make your logic system
> inconsistent, by the basic definition of inconsistency.
>
>


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<tb3nvv$1hdj$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Followup: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!NtE99RoDZ17S1XGlcLQp/Q.user.46.165.242.75.POSTED!not-for-mail
From: news.dea...@darjeeling.plus.com (Mike Terry)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Followup-To: comp.theory
Date: Mon, 18 Jul 2022 14:42:16 +0100
Organization: Aioe.org NNTP Server
Message-ID: <tb3nvv$1hdj$1@gioia.aioe.org>
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
<S%aBK.57712$sZ1.46897@fx07.iad>
<BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="50611"; posting-host="NtE99RoDZ17S1XGlcLQp/Q.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.8
X-Notice: Filtered by postfilter v. 0.9.2
 by: Mike Terry - Mon, 18 Jul 2022 13:42 UTC

On 18/07/2022 14:03, olcott wrote:
> On 7/18/2022 5:56 AM, Richard Damon wrote:
>> On 7/17/22 11:45 PM, olcott wrote:
>>> On 7/17/2022 9:53 PM, Richard Damon wrote:
>>>> On 7/17/22 9:48 PM, olcott wrote:
>>>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual instruction level.
>>>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of steps, and each
>>>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We can see from the x86 execution trace of the simulated P that the behavior of
>>>>>>>>>>>>>>>>> this simulated P exactly matches its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What we can also see from this same execution trace is that when H calls H(P,P) the
>>>>>>>>>>>>>>>>> simulated P remains stuck calling H(P,P) to simulate itself again thus forever
>>>>>>>>>>>>>>>>> preventing this simulated P from ever terminating normally by reaching its
>>>>>>>>>>>>>>>>> C:"return" or x86:"ret" instruction.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its simulation when it sees that the
>>>>>>>>>>>>>>>> simulation will reach the first call to H in the simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You logic is based on the assumption that H actually won't stop simulating its
>>>>>>>>>>>>>>>> input, when in actual fact it will. Thus you have a false premise in your logic, so
>>>>>>>>>>>>>>>> H never actually proved its fact considering the H that it is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a P that never halts. But
>>>>>>>>>>>>>>>> since this is NOT the definition of H, that doesn't say anything about what the
>>>>>>>>>>>>>>>> machine where H does abort its simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Halting means terminated normally when the correctly simulated P reaches its last
>>>>>>>>>>>>>>> instruction. Even though I have corrected you on this many hundreds of times you
>>>>>>>>>>>>>>> still fail to understand that an aborted simulation does not mean that the simulated
>>>>>>>>>>>>>>> input halted. You are moronically stupid on this point.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And YOU are the moron for thinking that just because a simulation was aborted the
>>>>>>>>>>>>>> CORRECT simulation of that input can't continue to reach the final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your replies are moronically stupid because they always make sure to maimtain the same
>>>>>>>>>>>>> false assumptions (utterly impervious to all reason) even when these false assumptions
>>>>>>>>>>>>> corrected hundreds of times.
>>>>>>>>>>>>
>>>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>>>
>>>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>>>>  >
>>>>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly he explains
>>>>>>>>>>>  > things.  I think he believes that the simulation would never halt
>>>>>>>>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand that a simulator
>>>>>>>>>>>  > that steps 10 steps then stops regardless, does not imply that the
>>>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>>>
>>>>>>>>>> An incomplete simulation not reaching a halting state does NOT prove that the input is
>>>>>>>>>> non-halting.
>>>>>>>>>>
>>>>>>>>> *Yes it does, this is simply over your head*
>>>>>>>>> Once a non-halting behavior pattern is correctly matched the simulation can be aborted and
>>>>>>>>> the input rejected as non-halting.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, you are totally wrong on that. If you say I am mistaken, which of these statements,
>>>>>>>> which PROVE my point, is in error? If none are, then my statement is PROVEN. Note, these are
>>>>>>>> based on the well established definition of Computation Theory and statement YOU have made
>>>>>>>> about your program.
>>>>>>>>
>>>>>>>> Just claiming you have proven the opposite is NOT enough, as all that does is show that your
>>>>>>>> logic system is inconsistent, because you have added inconsistent rules to your system
>>>>>>>> (likely rules that just aren't true).
>>>>>>>>
>>>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be returning 0.
>>>>>>>>
>>>>>>>> 2) P calls H(P,P)
>>>>>>>>
>>>>>>>
>>>>>>> P is aborted before the call is ever made.
>>>>>>> This seems to be the key to overcome referential transparency.
>>>>>>
>>>>>> Just you proving your an idiot, and not reading?
>>>>>>
>>>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>>>
>>>>>> There IS no "Aborts" at the source code level.
>>>>> We have been talking about this for many months and you haven't noticed that H operates at the
>>>>> machine language level?
>>>>>
>>>>
>>>> But the code for P was still specified at a source code level.
>>>>
>>>> You keep on trying to say that the behavior of the input to H(P,P) doesn't match the behavior of
>>>> P(P), but the point you miss is that then your code for P is wrong.
>>>
>>> You are simply too stupid to verify that facts to prove that it is correct.
>>>
>>> *Halting problem proofs refuted on the basis of software engineering*
>>>
>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>
>>>
>>
>> So, you are admitting that there is no error in my claim and it IS a fact that H does not
>> correctly determine to Halting of P(P)?
>>
>> Then who is the one too stupid to verify facts?
>>
>> Note, if my proof is correct, and your proof is corret, all this proves is that the extra rules
>> you added to your logic make your logic system inconsistent, by the basic definition of
>> inconsistency.
>>
>>
>
> I have told you a thousands times that halting is terminating normally by reaching the last
> instruction (final state) and you still have it stuck in your head that halting is stopping for any
> reason.
>
> Mike still says that I get this wrong when I have proven that I get it correctly hundreds of times:
>
> *computation that halts* … the Turing machine will halt whenever it enters a final state.
> (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath
> and Company.
>


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<TM6dnaEGr5aM-Uj_nZ2dnUU7_8xg4p2d@giganews.com>

 copy mid

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

 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: Mon, 18 Jul 2022 08:45:52 -0500
Date: Mon, 18 Jul 2022 08:45:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
<S%aBK.57712$sZ1.46897@fx07.iad>
<BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
<tb3nvv$1hdj$1@gioia.aioe.org>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <tb3nvv$1hdj$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <TM6dnaEGr5aM-Uj_nZ2dnUU7_8xg4p2d@giganews.com>
Lines: 193
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-4PDPp+Yk+Ks7+YRuZyfaNsdX3bRMeBMBTLVKzWIvnrqOhDgwa3kKTMJDVQ8cJSXr6QaAc0E5FxfBJVB!ufaq7QmKM2qczwsW2eoI6tiV8k8X9F3aEnQcSyDl8YVBZmm33PGbfp1Mjt2Ai4jfD0SElpVS6ylo!Dg==
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: 10823
 by: olcott - Mon, 18 Jul 2022 13:45 UTC

On 7/18/2022 8:42 AM, Mike Terry wrote:
> On 18/07/2022 14:03, olcott wrote:
>> On 7/18/2022 5:56 AM, Richard Damon wrote:
>>> On 7/17/22 11:45 PM, olcott wrote:
>>>> On 7/17/2022 9:53 PM, Richard Damon wrote:
>>>>> On 7/17/22 9:48 PM, olcott wrote:
>>>>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of
>>>>>>>>>>>>>>>>>> steps, and each
>>>>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation
>>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We can see from the x86 execution trace of the
>>>>>>>>>>>>>>>>>> simulated P that the behavior of this simulated P
>>>>>>>>>>>>>>>>>> exactly matches its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What we can also see from this same execution trace is
>>>>>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck
>>>>>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever
>>>>>>>>>>>>>>>>>> preventing this simulated P from ever terminating
>>>>>>>>>>>>>>>>>> normally by reaching its C:"return" or x86:"ret"
>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>>>>>> simulation when it sees that the simulation will reach
>>>>>>>>>>>>>>>>> the first call to H in the simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You logic is based on the assumption that H actually
>>>>>>>>>>>>>>>>> won't stop simulating its input, when in actual fact it
>>>>>>>>>>>>>>>>> will. Thus you have a false premise in your logic, so H
>>>>>>>>>>>>>>>>> never actually proved its fact considering the H that
>>>>>>>>>>>>>>>>> it is.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this
>>>>>>>>>>>>>>>>> makes a P that never halts. But since this is NOT the
>>>>>>>>>>>>>>>>> definition of H, that doesn't say anything about what
>>>>>>>>>>>>>>>>> the machine where H does abort its simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>>>>>> simulated P reaches its last instruction. Even though I
>>>>>>>>>>>>>>>> have corrected you on this many hundreds of times you
>>>>>>>>>>>>>>>> still fail to understand that an aborted simulation does
>>>>>>>>>>>>>>>> not mean that the simulated input halted. You are
>>>>>>>>>>>>>>>> moronically stupid on this point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that
>>>>>>>>>>>>>>> input can't continue to reach the final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your replies are moronically stupid because they always
>>>>>>>>>>>>>> make sure to maimtain the same false assumptions (utterly
>>>>>>>>>>>>>> impervious to all reason) even when these false
>>>>>>>>>>>>>> assumptions corrected hundreds of times.
>>>>>>>>>>>>>
>>>>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>>>>
>>>>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that
>>>>>>>>>>>> the
>>>>>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>>>>>  >
>>>>>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly
>>>>>>>>>>>> he explains
>>>>>>>>>>>>  > things.  I think he believes that the simulation would
>>>>>>>>>>>> never halt
>>>>>>>>>>>>  > *because his never-halting-abort test matched*, NOT
>>>>>>>>>>>> simply as a
>>>>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand
>>>>>>>>>>>> that a simulator
>>>>>>>>>>>>  > that steps 10 steps then stops regardless, does not imply
>>>>>>>>>>>> that the
>>>>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>>>>
>>>>>>>>>>> An incomplete simulation not reaching a halting state does
>>>>>>>>>>> NOT prove that the input is non-halting.
>>>>>>>>>>>
>>>>>>>>>> *Yes it does, this is simply over your head*
>>>>>>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>>>>>>> simulation can be aborted and the input rejected as non-halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, you are totally wrong on that. If you say I am mistaken,
>>>>>>>>> which of these statements, which PROVE my point, is in error?
>>>>>>>>> If none are, then my statement is PROVEN. Note, these are based
>>>>>>>>> on the well established definition of Computation Theory and
>>>>>>>>> statement YOU have made about your program.
>>>>>>>>>
>>>>>>>>> Just claiming you have proven the opposite is NOT enough, as
>>>>>>>>> all that does is show that your logic system is inconsistent,
>>>>>>>>> because you have added inconsistent rules to your system
>>>>>>>>> (likely rules that just aren't true).
>>>>>>>>>
>>>>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must
>>>>>>>>> actually be returning 0.
>>>>>>>>>
>>>>>>>>> 2) P calls H(P,P)
>>>>>>>>>
>>>>>>>>
>>>>>>>> P is aborted before the call is ever made.
>>>>>>>> This seems to be the key to overcome referential transparency.
>>>>>>>
>>>>>>> Just you proving your an idiot, and not reading?
>>>>>>>
>>>>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>>>>
>>>>>>> There IS no "Aborts" at the source code level.
>>>>>> We have been talking about this for many months and you haven't
>>>>>> noticed that H operates at the machine language level?
>>>>>>
>>>>>
>>>>> But the code for P was still specified at a source code level.
>>>>>
>>>>> You keep on trying to say that the behavior of the input to H(P,P)
>>>>> doesn't match the behavior of P(P), but the point you miss is that
>>>>> then your code for P is wrong.
>>>>
>>>> You are simply too stupid to verify that facts to prove that it is
>>>> correct.
>>>>
>>>> *Halting problem proofs refuted on the basis of software engineering*
>>>>
>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>
>>>>
>>>
>>> So, you are admitting that there is no error in my claim and it IS a
>>> fact that H does not correctly determine to Halting of P(P)?
>>>
>>> Then who is the one too stupid to verify facts?
>>>
>>> Note, if my proof is correct, and your proof is corret, all this
>>> proves is that the extra rules you added to your logic make your
>>> logic system inconsistent, by the basic definition of inconsistency.
>>>
>>>
>>
>> I have told you a thousands times that halting is terminating normally
>> by reaching the last instruction (final state) and you still have it
>> stuck in your head that halting is stopping for any reason.
>>
>> Mike still says that I get this wrong when I have proven that I get it
>> correctly hundreds of times:
>>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company.
>>
>
> Look, you've been told many times that you lack the necessary intellect
> to understand what other people think and believe about what you say.
> You're always quoting other people and misunderstanding their position,
> and there's a simple solution that - JUST DON'T QUOTE OTHER PEOPLE IN
> YOUR POSTS!
>
> Make your points in your own words.
>
> Mike.


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<tb3onv$1tvh$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!NtE99RoDZ17S1XGlcLQp/Q.user.46.165.242.75.POSTED!not-for-mail
From: news.dea...@darjeeling.plus.com (Mike Terry)
Newsgroups: comp.theory
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Date: Mon, 18 Jul 2022 14:55:12 +0100
Organization: Aioe.org NNTP Server
Message-ID: <tb3onv$1tvh$1@gioia.aioe.org>
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
<S%aBK.57712$sZ1.46897@fx07.iad>
<BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
<tb3nvv$1hdj$1@gioia.aioe.org>
<TM6dnaEGr5aM-Uj_nZ2dnUU7_8xg4p2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="63473"; posting-host="NtE99RoDZ17S1XGlcLQp/Q.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.8
X-Notice: Filtered by postfilter v. 0.9.2
 by: Mike Terry - Mon, 18 Jul 2022 13:55 UTC

On 18/07/2022 14:45, olcott wrote:
> On 7/18/2022 8:42 AM, Mike Terry wrote:
>> On 18/07/2022 14:03, olcott wrote:
>>> On 7/18/2022 5:56 AM, Richard Damon wrote:
>>>> On 7/17/22 11:45 PM, olcott wrote:
>>>>> On 7/17/2022 9:53 PM, Richard Damon wrote:
>>>>>> On 7/17/22 9:48 PM, olcott wrote:
>>>>>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual instruction level.
>>>>>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of steps, and each
>>>>>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation steps.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We can see from the x86 execution trace of the simulated P that the behavior of
>>>>>>>>>>>>>>>>>>> this simulated P exactly matches its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What we can also see from this same execution trace is that when H calls H(P,P)
>>>>>>>>>>>>>>>>>>> the simulated P remains stuck calling H(P,P) to simulate itself again thus
>>>>>>>>>>>>>>>>>>> forever preventing this simulated P from ever terminating normally by reaching
>>>>>>>>>>>>>>>>>>> its C:"return" or x86:"ret" instruction.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its simulation when it sees that the
>>>>>>>>>>>>>>>>>> simulation will reach the first call to H in the simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You logic is based on the assumption that H actually won't stop simulating its
>>>>>>>>>>>>>>>>>> input, when in actual fact it will. Thus you have a false premise in your logic,
>>>>>>>>>>>>>>>>>> so H never actually proved its fact considering the H that it is.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a P that never halts. But
>>>>>>>>>>>>>>>>>> since this is NOT the definition of H, that doesn't say anything about what the
>>>>>>>>>>>>>>>>>> machine where H does abort its simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Halting means terminated normally when the correctly simulated P reaches its last
>>>>>>>>>>>>>>>>> instruction. Even though I have corrected you on this many hundreds of times you
>>>>>>>>>>>>>>>>> still fail to understand that an aborted simulation does not mean that the
>>>>>>>>>>>>>>>>> simulated input halted. You are moronically stupid on this point.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And YOU are the moron for thinking that just because a simulation was aborted the
>>>>>>>>>>>>>>>> CORRECT simulation of that input can't continue to reach the final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your replies are moronically stupid because they always make sure to maimtain the
>>>>>>>>>>>>>>> same false assumptions (utterly impervious to all reason) even when these false
>>>>>>>>>>>>>>> assumptions corrected hundreds of times.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly he explains
>>>>>>>>>>>>>  > things.  I think he believes that the simulation would never halt
>>>>>>>>>>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand that a simulator
>>>>>>>>>>>>>  > that steps 10 steps then stops regardless, does not imply that the
>>>>>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>>>>>
>>>>>>>>>>>> An incomplete simulation not reaching a halting state does NOT prove that the input is
>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>
>>>>>>>>>>> *Yes it does, this is simply over your head*
>>>>>>>>>>> Once a non-halting behavior pattern is correctly matched the simulation can be aborted
>>>>>>>>>>> and the input rejected as non-halting.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, you are totally wrong on that. If you say I am mistaken, which of these statements,
>>>>>>>>>> which PROVE my point, is in error? If none are, then my statement is PROVEN. Note, these
>>>>>>>>>> are based on the well established definition of Computation Theory and statement YOU have
>>>>>>>>>> made about your program.
>>>>>>>>>>
>>>>>>>>>> Just claiming you have proven the opposite is NOT enough, as all that does is show that
>>>>>>>>>> your logic system is inconsistent, because you have added inconsistent rules to your
>>>>>>>>>> system (likely rules that just aren't true).
>>>>>>>>>>
>>>>>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be returning 0.
>>>>>>>>>>
>>>>>>>>>> 2) P calls H(P,P)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> P is aborted before the call is ever made.
>>>>>>>>> This seems to be the key to overcome referential transparency.
>>>>>>>>
>>>>>>>> Just you proving your an idiot, and not reading?
>>>>>>>>
>>>>>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>>>>>
>>>>>>>> There IS no "Aborts" at the source code level.
>>>>>>> We have been talking about this for many months and you haven't noticed that H operates at
>>>>>>> the machine language level?
>>>>>>>
>>>>>>
>>>>>> But the code for P was still specified at a source code level.
>>>>>>
>>>>>> You keep on trying to say that the behavior of the input to H(P,P) doesn't match the behavior
>>>>>> of P(P), but the point you miss is that then your code for P is wrong.
>>>>>
>>>>> You are simply too stupid to verify that facts to prove that it is correct.
>>>>>
>>>>> *Halting problem proofs refuted on the basis of software engineering*
>>>>>
>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>
>>>>>
>>>>
>>>> So, you are admitting that there is no error in my claim and it IS a fact that H does not
>>>> correctly determine to Halting of P(P)?
>>>>
>>>> Then who is the one too stupid to verify facts?
>>>>
>>>> Note, if my proof is correct, and your proof is corret, all this proves is that the extra rules
>>>> you added to your logic make your logic system inconsistent, by the basic definition of
>>>> inconsistency.
>>>>
>>>>
>>>
>>> I have told you a thousands times that halting is terminating normally by reaching the last
>>> instruction (final state) and you still have it stuck in your head that halting is stopping for
>>> any reason.
>>>
>>> Mike still says that I get this wrong when I have proven that I get it correctly hundreds of times:
>>>
>>> *computation that halts* … the Turing machine will halt whenever it enters a final state.
>>> (Linz:1990:234)
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C.
>>> Heath and Company.
>>>
>>
>> Look, you've been told many times that you lack the necessary intellect to understand what other
>> people think and believe about what you say. You're always quoting other people and
>> misunderstanding their position, and there's a simple solution that - JUST DON'T QUOTE OTHER
>> PEOPLE IN YOUR POSTS!
>>
>> Make your points in your own words.
>>
>> Mike.
>
> You completely dodged the question about the definition of halting.
> It seems to me that I am simply correct about this (anchored in Linz)
> and when you say that I am incorrect, you already know that I am correct.
>


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<bfSdnfSEloG6-kj_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 18 Jul 2022 08:59:03 -0500
Date: Mon, 18 Jul 2022 08:59:02 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
<S%aBK.57712$sZ1.46897@fx07.iad>
<BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
<tb3nvv$1hdj$1@gioia.aioe.org>
<TM6dnaEGr5aM-Uj_nZ2dnUU7_8xg4p2d@giganews.com>
<tb3onv$1tvh$1@gioia.aioe.org>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <tb3onv$1tvh$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <bfSdnfSEloG6-kj_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 209
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-rTc71/BMfn/nfmz4P9iV4zXTVXmxPI+SALZa9bqt3VeD/APbFMOb2eoBwXuYNH/oElLwuD9iwIWNgJD!qH3JumtDdB89iB7+uc8h4a3VVoYsXEptn2d/jaioF7EzByfUyELMq5WTWDkpoRWiqaiKqOcgOV7E!Uw==
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: 11792
X-Received-Bytes: 11885
 by: olcott - Mon, 18 Jul 2022 13:59 UTC

On 7/18/2022 8:55 AM, Mike Terry wrote:
> On 18/07/2022 14:45, olcott wrote:
>> On 7/18/2022 8:42 AM, Mike Terry wrote:
>>> On 18/07/2022 14:03, olcott wrote:
>>>> On 7/18/2022 5:56 AM, Richard Damon wrote:
>>>>> On 7/17/22 11:45 PM, olcott wrote:
>>>>>> On 7/17/2022 9:53 PM, Richard Damon wrote:
>>>>>>> On 7/17/22 9:48 PM, olcott wrote:
>>>>>>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>>>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of
>>>>>>>>>>>>>>>>>>>> steps, and each
>>>>>>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P)
>>>>>>>>>>>>>>>>>>>> calculation steps.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We can see from the x86 execution trace of the
>>>>>>>>>>>>>>>>>>>> simulated P that the behavior of this simulated P
>>>>>>>>>>>>>>>>>>>> exactly matches its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What we can also see from this same execution trace
>>>>>>>>>>>>>>>>>>>> is that when H calls H(P,P) the simulated P remains
>>>>>>>>>>>>>>>>>>>> stuck calling H(P,P) to simulate itself again thus
>>>>>>>>>>>>>>>>>>>> forever preventing this simulated P from ever
>>>>>>>>>>>>>>>>>>>> terminating normally by reaching its C:"return" or
>>>>>>>>>>>>>>>>>>>> x86:"ret" instruction.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>>>>>>>> simulation when it sees that the simulation will
>>>>>>>>>>>>>>>>>>> reach the first call to H in the simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You logic is based on the assumption that H actually
>>>>>>>>>>>>>>>>>>> won't stop simulating its input, when in actual fact
>>>>>>>>>>>>>>>>>>> it will. Thus you have a false premise in your logic,
>>>>>>>>>>>>>>>>>>> so H never actually proved its fact considering the H
>>>>>>>>>>>>>>>>>>> that it is.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this
>>>>>>>>>>>>>>>>>>> makes a P that never halts. But since this is NOT the
>>>>>>>>>>>>>>>>>>> definition of H, that doesn't say anything about what
>>>>>>>>>>>>>>>>>>> the machine where H does abort its simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>>>>>>>> simulated P reaches its last instruction. Even though
>>>>>>>>>>>>>>>>>> I have corrected you on this many hundreds of times
>>>>>>>>>>>>>>>>>> you still fail to understand that an aborted
>>>>>>>>>>>>>>>>>> simulation does not mean that the simulated input
>>>>>>>>>>>>>>>>>> halted. You are moronically stupid on this point.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that
>>>>>>>>>>>>>>>>> input can't continue to reach the final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your replies are moronically stupid because they always
>>>>>>>>>>>>>>>> make sure to maimtain the same false assumptions
>>>>>>>>>>>>>>>> (utterly impervious to all reason) even when these false
>>>>>>>>>>>>>>>> assumptions corrected hundreds of times.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes
>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>  >> simulation not reaching the final state PROVES
>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>  >
>>>>>>>>>>>>>>  > I don't believe PO thinks that, irrespective of how
>>>>>>>>>>>>>> badly he explains
>>>>>>>>>>>>>>  > things.  I think he believes that the simulation would
>>>>>>>>>>>>>> never halt
>>>>>>>>>>>>>>  > *because his never-halting-abort test matched*, NOT
>>>>>>>>>>>>>> simply as a
>>>>>>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand
>>>>>>>>>>>>>> that a simulator
>>>>>>>>>>>>>>  > that steps 10 steps then stops regardless, does not
>>>>>>>>>>>>>> imply that the
>>>>>>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>>>>>>
>>>>>>>>>>>>> An incomplete simulation not reaching a halting state does
>>>>>>>>>>>>> NOT prove that the input is non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>> *Yes it does, this is simply over your head*
>>>>>>>>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>>>>>>>>> simulation can be aborted and the input rejected as
>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, you are totally wrong on that. If you say I am mistaken,
>>>>>>>>>>> which of these statements, which PROVE my point, is in error?
>>>>>>>>>>> If none are, then my statement is PROVEN. Note, these are
>>>>>>>>>>> based on the well established definition of Computation
>>>>>>>>>>> Theory and statement YOU have made about your program.
>>>>>>>>>>>
>>>>>>>>>>> Just claiming you have proven the opposite is NOT enough, as
>>>>>>>>>>> all that does is show that your logic system is inconsistent,
>>>>>>>>>>> because you have added inconsistent rules to your system
>>>>>>>>>>> (likely rules that just aren't true).
>>>>>>>>>>>
>>>>>>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must
>>>>>>>>>>> actually be returning 0.
>>>>>>>>>>>
>>>>>>>>>>> 2) P calls H(P,P)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> P is aborted before the call is ever made.
>>>>>>>>>> This seems to be the key to overcome referential transparency.
>>>>>>>>>
>>>>>>>>> Just you proving your an idiot, and not reading?
>>>>>>>>>
>>>>>>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>>>>>>
>>>>>>>>> There IS no "Aborts" at the source code level.
>>>>>>>> We have been talking about this for many months and you haven't
>>>>>>>> noticed that H operates at the machine language level?
>>>>>>>>
>>>>>>>
>>>>>>> But the code for P was still specified at a source code level.
>>>>>>>
>>>>>>> You keep on trying to say that the behavior of the input to
>>>>>>> H(P,P) doesn't match the behavior of P(P), but the point you miss
>>>>>>> is that then your code for P is wrong.
>>>>>>
>>>>>> You are simply too stupid to verify that facts to prove that it is
>>>>>> correct.
>>>>>>
>>>>>> *Halting problem proofs refuted on the basis of software engineering*
>>>>>>
>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>
>>>>>>
>>>>>
>>>>> So, you are admitting that there is no error in my claim and it IS
>>>>> a fact that H does not correctly determine to Halting of P(P)?
>>>>>
>>>>> Then who is the one too stupid to verify facts?
>>>>>
>>>>> Note, if my proof is correct, and your proof is corret, all this
>>>>> proves is that the extra rules you added to your logic make your
>>>>> logic system inconsistent, by the basic definition of inconsistency.
>>>>>
>>>>>
>>>>
>>>> I have told you a thousands times that halting is terminating
>>>> normally by reaching the last instruction (final state) and you
>>>> still have it stuck in your head that halting is stopping for any
>>>> reason.
>>>>
>>>> Mike still says that I get this wrong when I have proven that I get
>>>> it correctly hundreds of times:
>>>>
>>>> *computation that halts* … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>
>>>
>>> Look, you've been told many times that you lack the necessary
>>> intellect to understand what other people think and believe about
>>> what you say. You're always quoting other people and misunderstanding
>>> their position, and there's a simple solution that - JUST DON'T QUOTE
>>> OTHER PEOPLE IN YOUR POSTS!
>>>
>>> Make your points in your own words.
>>>
>>> Mike.
>>
>> You completely dodged the question about the definition of halting.
>> It seems to me that I am simply correct about this (anchored in Linz)
>> and when you say that I am incorrect, you already know that I am correct.
>>
>
> Where do I say that you get this wrong when you quote the Linz text?
> Answer: I never say that.
>
>
> Mike.


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<tb44n7$fmbg$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: jbb...@notatt.com (Jeff Barnett)
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Date: Mon, 18 Jul 2022 11:19:33 -0600
Organization: A noiseless patient Spider
Lines: 162
Message-ID: <tb44n7$fmbg$1@dont-email.me>
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
<S%aBK.57712$sZ1.46897@fx07.iad>
<BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
<tb3nvv$1hdj$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
Injection-Date: Mon, 18 Jul 2022 17:19:35 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="13daf0fb79573f67e60cc8303d97583b";
logging-data="514416"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/lFOnmIKXXLlXl8Ogu6ACq9MzwYyylnsw="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Cancel-Lock: sha1:tfuPQkmUbSgcwVLdQPbs1PpB8eM=
In-Reply-To: <tb3nvv$1hdj$1@gioia.aioe.org>
Content-Language: en-US
 by: Jeff Barnett - Mon, 18 Jul 2022 17:19 UTC

On 7/18/2022 7:42 AM, Mike Terry wrote:
> On 18/07/2022 14:03, olcott wrote:
>> On 7/18/2022 5:56 AM, Richard Damon wrote:
>>> On 7/17/22 11:45 PM, olcott wrote:
>>>> On 7/17/2022 9:53 PM, Richard Damon wrote:
>>>>> On 7/17/22 9:48 PM, olcott wrote:
>>>>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of
>>>>>>>>>>>>>>>>>> steps, and each
>>>>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation
>>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We can see from the x86 execution trace of the
>>>>>>>>>>>>>>>>>> simulated P that the behavior of this simulated P
>>>>>>>>>>>>>>>>>> exactly matches its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What we can also see from this same execution trace is
>>>>>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck
>>>>>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever
>>>>>>>>>>>>>>>>>> preventing this simulated P from ever terminating
>>>>>>>>>>>>>>>>>> normally by reaching its C:"return" or x86:"ret"
>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>>>>>> simulation when it sees that the simulation will reach
>>>>>>>>>>>>>>>>> the first call to H in the simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You logic is based on the assumption that H actually
>>>>>>>>>>>>>>>>> won't stop simulating its input, when in actual fact it
>>>>>>>>>>>>>>>>> will. Thus you have a false premise in your logic, so H
>>>>>>>>>>>>>>>>> never actually proved its fact considering the H that
>>>>>>>>>>>>>>>>> it is.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this
>>>>>>>>>>>>>>>>> makes a P that never halts. But since this is NOT the
>>>>>>>>>>>>>>>>> definition of H, that doesn't say anything about what
>>>>>>>>>>>>>>>>> the machine where H does abort its simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>>>>>> simulated P reaches its last instruction. Even though I
>>>>>>>>>>>>>>>> have corrected you on this many hundreds of times you
>>>>>>>>>>>>>>>> still fail to understand that an aborted simulation does
>>>>>>>>>>>>>>>> not mean that the simulated input halted. You are
>>>>>>>>>>>>>>>> moronically stupid on this point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that
>>>>>>>>>>>>>>> input can't continue to reach the final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your replies are moronically stupid because they always
>>>>>>>>>>>>>> make sure to maimtain the same false assumptions (utterly
>>>>>>>>>>>>>> impervious to all reason) even when these false
>>>>>>>>>>>>>> assumptions corrected hundreds of times.
>>>>>>>>>>>>>
>>>>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>>>>
>>>>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that
>>>>>>>>>>>> the
>>>>>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>>>>>  >
>>>>>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly
>>>>>>>>>>>> he explains
>>>>>>>>>>>>  > things.  I think he believes that the simulation would
>>>>>>>>>>>> never halt
>>>>>>>>>>>>  > *because his never-halting-abort test matched*, NOT
>>>>>>>>>>>> simply as a
>>>>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand
>>>>>>>>>>>> that a simulator
>>>>>>>>>>>>  > that steps 10 steps then stops regardless, does not imply
>>>>>>>>>>>> that the
>>>>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>>>>
>>>>>>>>>>> An incomplete simulation not reaching a halting state does
>>>>>>>>>>> NOT prove that the input is non-halting.
>>>>>>>>>>>
>>>>>>>>>> *Yes it does, this is simply over your head*
>>>>>>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>>>>>>> simulation can be aborted and the input rejected as non-halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, you are totally wrong on that. If you say I am mistaken,
>>>>>>>>> which of these statements, which PROVE my point, is in error?
>>>>>>>>> If none are, then my statement is PROVEN. Note, these are based
>>>>>>>>> on the well established definition of Computation Theory and
>>>>>>>>> statement YOU have made about your program.
>>>>>>>>>
>>>>>>>>> Just claiming you have proven the opposite is NOT enough, as
>>>>>>>>> all that does is show that your logic system is inconsistent,
>>>>>>>>> because you have added inconsistent rules to your system
>>>>>>>>> (likely rules that just aren't true).
>>>>>>>>>
>>>>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must
>>>>>>>>> actually be returning 0.
>>>>>>>>>
>>>>>>>>> 2) P calls H(P,P)
>>>>>>>>>
>>>>>>>>
>>>>>>>> P is aborted before the call is ever made.
>>>>>>>> This seems to be the key to overcome referential transparency.
>>>>>>>
>>>>>>> Just you proving your an idiot, and not reading?
>>>>>>>
>>>>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>>>>
>>>>>>> There IS no "Aborts" at the source code level.
>>>>>> We have been talking about this for many months and you haven't
>>>>>> noticed that H operates at the machine language level?
>>>>>>
>>>>>
>>>>> But the code for P was still specified at a source code level.
>>>>>
>>>>> You keep on trying to say that the behavior of the input to H(P,P)
>>>>> doesn't match the behavior of P(P), but the point you miss is that
>>>>> then your code for P is wrong.
>>>>
>>>> You are simply too stupid to verify that facts to prove that it is
>>>> correct.
>>>>
>>>> *Halting problem proofs refuted on the basis of software engineering*
>>>>
>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>
>>>>
>>>
>>> So, you are admitting that there is no error in my claim and it IS a
>>> fact that H does not correctly determine to Halting of P(P)?
>>>
>>> Then who is the one too stupid to verify facts?
>>>
>>> Note, if my proof is correct, and your proof is corret, all this
>>> proves is that the extra rules you added to your logic make your
>>> logic system inconsistent, by the basic definition of inconsistency.
>>>
>>>
>>
>> I have told you a thousands times that halting is terminating normally
>> by reaching the last instruction (final state) and you still have it
>> stuck in your head that halting is stopping for any reason.
>>
>> Mike still says that I get this wrong when I have proven that I get it
>> correctly hundreds of times:
>>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company.
>>
>
> Look, you've been told many times that you lack the necessary intellect
> to understand what other people think and believe about what you say.
> You're always quoting other people and misunderstanding their position,
> and there's a simple solution that - JUST DON'T QUOTE OTHER PEOPLE IN
> YOUR POSTS!
>
> Make your points in your own words.
Mike, that's not fair. If he followed your advice, he would have
disappeared from technical forums decades ago. And then everyone would
miss the entertainment value mentally chasing a greased pig.
--
Jeff Barnett


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<22mBK.488606$70j.170170@fx16.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.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.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
<S%aBK.57712$sZ1.46897@fx07.iad>
<BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 188
Message-ID: <22mBK.488606$70j.170170@fx16.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: Mon, 18 Jul 2022 19:30:05 -0400
X-Received-Bytes: 10034
 by: Richard Damon - Mon, 18 Jul 2022 23:30 UTC

On 7/18/22 9:03 AM, olcott wrote:
> On 7/18/2022 5:56 AM, Richard Damon wrote:
>> On 7/17/22 11:45 PM, olcott wrote:
>>> On 7/17/2022 9:53 PM, Richard Damon wrote:
>>>> On 7/17/22 9:48 PM, olcott wrote:
>>>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of
>>>>>>>>>>>>>>>>> steps, and each
>>>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation
>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We can see from the x86 execution trace of the
>>>>>>>>>>>>>>>>> simulated P that the behavior of this simulated P
>>>>>>>>>>>>>>>>> exactly matches its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What we can also see from this same execution trace is
>>>>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck
>>>>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever
>>>>>>>>>>>>>>>>> preventing this simulated P from ever terminating
>>>>>>>>>>>>>>>>> normally by reaching its C:"return" or x86:"ret"
>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>>>>> simulation when it sees that the simulation will reach
>>>>>>>>>>>>>>>> the first call to H in the simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You logic is based on the assumption that H actually
>>>>>>>>>>>>>>>> won't stop simulating its input, when in actual fact it
>>>>>>>>>>>>>>>> will. Thus you have a false premise in your logic, so H
>>>>>>>>>>>>>>>> never actually proved its fact considering the H that it
>>>>>>>>>>>>>>>> is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes
>>>>>>>>>>>>>>>> a P that never halts. But since this is NOT the
>>>>>>>>>>>>>>>> definition of H, that doesn't say anything about what
>>>>>>>>>>>>>>>> the machine where H does abort its simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>>>>> simulated P reaches its last instruction. Even though I
>>>>>>>>>>>>>>> have corrected you on this many hundreds of times you
>>>>>>>>>>>>>>> still fail to understand that an aborted simulation does
>>>>>>>>>>>>>>> not mean that the simulated input halted. You are
>>>>>>>>>>>>>>> moronically stupid on this point.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that
>>>>>>>>>>>>>> input can't continue to reach the final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your replies are moronically stupid because they always
>>>>>>>>>>>>> make sure to maimtain the same false assumptions (utterly
>>>>>>>>>>>>> impervious to all reason) even when these false assumptions
>>>>>>>>>>>>> corrected hundreds of times.
>>>>>>>>>>>>
>>>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>>>
>>>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>>>>  >
>>>>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly
>>>>>>>>>>> he explains
>>>>>>>>>>>  > things.  I think he believes that the simulation would
>>>>>>>>>>> never halt
>>>>>>>>>>>  > *because his never-halting-abort test matched*, NOT simply
>>>>>>>>>>> as a
>>>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand that
>>>>>>>>>>> a simulator
>>>>>>>>>>>  > that steps 10 steps then stops regardless, does not imply
>>>>>>>>>>> that the
>>>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>>>
>>>>>>>>>> An incomplete simulation not reaching a halting state does NOT
>>>>>>>>>> prove that the input is non-halting.
>>>>>>>>>>
>>>>>>>>> *Yes it does, this is simply over your head*
>>>>>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>>>>>> simulation can be aborted and the input rejected as non-halting.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, you are totally wrong on that. If you say I am mistaken,
>>>>>>>> which of these statements, which PROVE my point, is in error? If
>>>>>>>> none are, then my statement is PROVEN. Note, these are based on
>>>>>>>> the well established definition of Computation Theory and
>>>>>>>> statement YOU have made about your program.
>>>>>>>>
>>>>>>>> Just claiming you have proven the opposite is NOT enough, as all
>>>>>>>> that does is show that your logic system is inconsistent,
>>>>>>>> because you have added inconsistent rules to your system (likely
>>>>>>>> rules that just aren't true).
>>>>>>>>
>>>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually
>>>>>>>> be returning 0.
>>>>>>>>
>>>>>>>> 2) P calls H(P,P)
>>>>>>>>
>>>>>>>
>>>>>>> P is aborted before the call is ever made.
>>>>>>> This seems to be the key to overcome referential transparency.
>>>>>>
>>>>>> Just you proving your an idiot, and not reading?
>>>>>>
>>>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>>>
>>>>>> There IS no "Aborts" at the source code level.
>>>>> We have been talking about this for many months and you haven't
>>>>> noticed that H operates at the machine language level?
>>>>>
>>>>
>>>> But the code for P was still specified at a source code level.
>>>>
>>>> You keep on trying to say that the behavior of the input to H(P,P)
>>>> doesn't match the behavior of P(P), but the point you miss is that
>>>> then your code for P is wrong.
>>>
>>> You are simply too stupid to verify that facts to prove that it is
>>> correct.
>>>
>>> *Halting problem proofs refuted on the basis of software engineering*
>>>
>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>
>>>
>>
>> So, you are admitting that there is no error in my claim and it IS a
>> fact that H does not correctly determine to Halting of P(P)?
>>
>> Then who is the one too stupid to verify facts?
>>
>> Note, if my proof is correct, and your proof is corret, all this
>> proves is that the extra rules you added to your logic make your logic
>> system inconsistent, by the basic definition of inconsistency.
>>
>>
>
> I have told you a thousands times that halting is terminating normally
> by reaching the last instruction (final state) and you still have it
> stuck in your head that halting is stopping for any reason.


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<RQnBK.48998$Ae2.15985@fx35.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.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.11.0
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly
simulate its input ?
Content-Language: en-US
Newsgroups: comp.theory
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com>
<mwSAK.484483$J0r9.388519@fx11.iad>
<2OCdnYj6xoDYkEn_nZ2dnUU7_83NnZ2d@giganews.com>
<jZWAK.577488$JVi.507916@fx17.iad>
<GZOdncG7yOmAoEn_nZ2dnUU7_8zNnZ2d@giganews.com>
<R9XAK.57708$sZ1.6803@fx07.iad>
<LNydnSQOkIQxzEn_nZ2dnUU7_81j4p2d@giganews.com>
<aiZAK.577919$JVi.241046@fx17.iad>
<NomdnWvs3OnZ-0n_nZ2dnUU7_8xg4p2d@giganews.com>
<jV_AK.484595$70j.462777@fx16.iad>
<jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com>
<2G2BK.47678$vd2.20719@fx39.iad>
<7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com>
<cX3BK.486740$J0r9.190196@fx11.iad>
<a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com>
<S%aBK.57712$sZ1.46897@fx07.iad>
<BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com>
<tb3nvv$1hdj$1@gioia.aioe.org>
<TM6dnaEGr5aM-Uj_nZ2dnUU7_8xg4p2d@giganews.com>
<tb3onv$1tvh$1@gioia.aioe.org>
<bfSdnfSEloG6-kj_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <bfSdnfSEloG6-kj_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 263
Message-ID: <RQnBK.48998$Ae2.15985@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: Mon, 18 Jul 2022 21:32:32 -0400
X-Received-Bytes: 14543
 by: Richard Damon - Tue, 19 Jul 2022 01:32 UTC

On 7/18/22 9:59 AM, olcott wrote:
> On 7/18/2022 8:55 AM, Mike Terry wrote:
>> On 18/07/2022 14:45, olcott wrote:
>>> On 7/18/2022 8:42 AM, Mike Terry wrote:
>>>> On 18/07/2022 14:03, olcott wrote:
>>>>> On 7/18/2022 5:56 AM, Richard Damon wrote:
>>>>>> On 7/17/22 11:45 PM, olcott wrote:
>>>>>>> On 7/17/2022 9:53 PM, Richard Damon wrote:
>>>>>>>> On 7/17/22 9:48 PM, olcott wrote:
>>>>>>>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>>>>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of
>>>>>>>>>>>>>>>>>>>>> steps, and each
>>>>>>>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P)
>>>>>>>>>>>>>>>>>>>>> calculation steps.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We can see from the x86 execution trace of the
>>>>>>>>>>>>>>>>>>>>> simulated P that the behavior of this simulated P
>>>>>>>>>>>>>>>>>>>>> exactly matches its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> What we can also see from this same execution trace
>>>>>>>>>>>>>>>>>>>>> is that when H calls H(P,P) the simulated P remains
>>>>>>>>>>>>>>>>>>>>> stuck calling H(P,P) to simulate itself again thus
>>>>>>>>>>>>>>>>>>>>> forever preventing this simulated P from ever
>>>>>>>>>>>>>>>>>>>>> terminating normally by reaching its C:"return" or
>>>>>>>>>>>>>>>>>>>>> x86:"ret" instruction.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>>>>>>>>> simulation when it sees that the simulation will
>>>>>>>>>>>>>>>>>>>> reach the first call to H in the simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You logic is based on the assumption that H actually
>>>>>>>>>>>>>>>>>>>> won't stop simulating its input, when in actual fact
>>>>>>>>>>>>>>>>>>>> it will. Thus you have a false premise in your
>>>>>>>>>>>>>>>>>>>> logic, so H never actually proved its fact
>>>>>>>>>>>>>>>>>>>> considering the H that it is.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this
>>>>>>>>>>>>>>>>>>>> makes a P that never halts. But since this is NOT
>>>>>>>>>>>>>>>>>>>> the definition of H, that doesn't say anything about
>>>>>>>>>>>>>>>>>>>> what the machine where H does abort its simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>>>>>>>>> simulated P reaches its last instruction. Even though
>>>>>>>>>>>>>>>>>>> I have corrected you on this many hundreds of times
>>>>>>>>>>>>>>>>>>> you still fail to understand that an aborted
>>>>>>>>>>>>>>>>>>> simulation does not mean that the simulated input
>>>>>>>>>>>>>>>>>>> halted. You are moronically stupid on this point.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that
>>>>>>>>>>>>>>>>>> input can't continue to reach the final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Your replies are moronically stupid because they always
>>>>>>>>>>>>>>>>> make sure to maimtain the same false assumptions
>>>>>>>>>>>>>>>>> (utterly impervious to all reason) even when these
>>>>>>>>>>>>>>>>> false assumptions corrected hundreds of times.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes
>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>  >> simulation not reaching the final state PROVES
>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>  >
>>>>>>>>>>>>>>>  > I don't believe PO thinks that, irrespective of how
>>>>>>>>>>>>>>> badly he explains
>>>>>>>>>>>>>>>  > things.  I think he believes that the simulation would
>>>>>>>>>>>>>>> never halt
>>>>>>>>>>>>>>>  > *because his never-halting-abort test matched*, NOT
>>>>>>>>>>>>>>> simply as a
>>>>>>>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand
>>>>>>>>>>>>>>> that a simulator
>>>>>>>>>>>>>>>  > that steps 10 steps then stops regardless, does not
>>>>>>>>>>>>>>> imply that the
>>>>>>>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> An incomplete simulation not reaching a halting state does
>>>>>>>>>>>>>> NOT prove that the input is non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> *Yes it does, this is simply over your head*
>>>>>>>>>>>>> Once a non-halting behavior pattern is correctly matched
>>>>>>>>>>>>> the simulation can be aborted and the input rejected as
>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, you are totally wrong on that. If you say I am mistaken,
>>>>>>>>>>>> which of these statements, which PROVE my point, is in
>>>>>>>>>>>> error? If none are, then my statement is PROVEN. Note, these
>>>>>>>>>>>> are based on the well established definition of Computation
>>>>>>>>>>>> Theory and statement YOU have made about your program.
>>>>>>>>>>>>
>>>>>>>>>>>> Just claiming you have proven the opposite is NOT enough, as
>>>>>>>>>>>> all that does is show that your logic system is
>>>>>>>>>>>> inconsistent, because you have added inconsistent rules to
>>>>>>>>>>>> your system (likely rules that just aren't true).
>>>>>>>>>>>>
>>>>>>>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must
>>>>>>>>>>>> actually be returning 0.
>>>>>>>>>>>>
>>>>>>>>>>>> 2) P calls H(P,P)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> P is aborted before the call is ever made.
>>>>>>>>>>> This seems to be the key to overcome referential transparency.
>>>>>>>>>>
>>>>>>>>>> Just you proving your an idiot, and not reading?
>>>>>>>>>>
>>>>>>>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>>>>>>>
>>>>>>>>>> There IS no "Aborts" at the source code level.
>>>>>>>>> We have been talking about this for many months and you haven't
>>>>>>>>> noticed that H operates at the machine language level?
>>>>>>>>>
>>>>>>>>
>>>>>>>> But the code for P was still specified at a source code level.
>>>>>>>>
>>>>>>>> You keep on trying to say that the behavior of the input to
>>>>>>>> H(P,P) doesn't match the behavior of P(P), but the point you
>>>>>>>> miss is that then your code for P is wrong.
>>>>>>>
>>>>>>> You are simply too stupid to verify that facts to prove that it
>>>>>>> is correct.
>>>>>>>
>>>>>>> *Halting problem proofs refuted on the basis of software
>>>>>>> engineering*
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So, you are admitting that there is no error in my claim and it IS
>>>>>> a fact that H does not correctly determine to Halting of P(P)?
>>>>>>
>>>>>> Then who is the one too stupid to verify facts?
>>>>>>
>>>>>> Note, if my proof is correct, and your proof is corret, all this
>>>>>> proves is that the extra rules you added to your logic make your
>>>>>> logic system inconsistent, by the basic definition of inconsistency.
>>>>>>
>>>>>>
>>>>>
>>>>> I have told you a thousands times that halting is terminating
>>>>> normally by reaching the last instruction (final state) and you
>>>>> still have it stuck in your head that halting is stopping for any
>>>>> reason.
>>>>>
>>>>> Mike still says that I get this wrong when I have proven that I get
>>>>> it correctly hundreds of times:
>>>>>
>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>>
>>>>
>>>> Look, you've been told many times that you lack the necessary
>>>> intellect to understand what other people think and believe about
>>>> what you say. You're always quoting other people and
>>>> misunderstanding their position, and there's a simple solution that
>>>> - JUST DON'T QUOTE OTHER PEOPLE IN YOUR POSTS!
>>>>
>>>> Make your points in your own words.
>>>>
>>>> Mike.
>>>
>>> You completely dodged the question about the definition of halting.
>>> It seems to me that I am simply correct about this (anchored in Linz)
>>> and when you say that I am incorrect, you already know that I am
>>> correct.
>>>
>>
>> Where do I say that you get this wrong when you quote the Linz text?
>> Answer: I never say that.
>>
>>
>> Mike.
>
> The final state of a TM is the same as the final instruction of a C
> function in both cases it is the last instruction. An aborted TM and and
> aborted C function cannot be correctly construed as halting on the basis
> that they were aborted and thus stopped running.
>


Click here to read the complete article
Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?

<tb5svl$10c0p$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: mikko.le...@iki.fi (Mikko)
Newsgroups: comp.theory
Subject: Re: Picking up where Mike Terry left off: Does H(P,P) correctly simulate its input ?
Date: Tue, 19 Jul 2022 12:19:50 +0300
Organization: -
Lines: 11
Message-ID: <tb5svl$10c0p$1@dont-email.me>
References: <1KOdnWZjcsRi4E7_nZ2dnUU7_83NnZ2d@giganews.com> <jNedncZ9BZBfMkn_nZ2dnUU7_83NnZ2d@giganews.com> <2G2BK.47678$vd2.20719@fx39.iad> <7Iidnb1aPtFhJkn_nZ2dnUU7_83NnZ2d@giganews.com> <cX3BK.486740$J0r9.190196@fx11.iad> <a_udnZs736LESkn_nZ2dnUU7_8zNnZ2d@giganews.com> <S%aBK.57712$sZ1.46897@fx07.iad> <BrqdnXXG5u-Lx0j_nZ2dnUU7_83NnZ2d@giganews.com> <tb3nvv$1hdj$1@gioia.aioe.org> <TM6dnaEGr5aM-Uj_nZ2dnUU7_8xg4p2d@giganews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: reader01.eternal-september.org; posting-host="38b4c2acf1429dd14741057220b9a527";
logging-data="1060889"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX181pSoTL4ob0bk9rwMRvwZH"
User-Agent: Unison/2.2
Cancel-Lock: sha1:0Hk8X+aqCngaVbEXN7XQhbRJJzE=
 by: Mikko - Tue, 19 Jul 2022 09:19 UTC

On 2022-07-18 13:45:52 +0000, olcott said:

> You completely dodged the question about the definition of halting.
> It seems to me that I am simply correct about this (anchored in Linz)
> and when you say that I am incorrect, you already know that I am correct.

It only seems that way because you always quote Linz' definition of
halting incompletely, with "..." instead of linz' words.

Mikko

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor