Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

win-nt from the people who invented edlin. -- MaDsen Wikholm, mwikholm@at8.abo.fi

devel / comp.lang.c / Re: the correct x86 emulation of the input to H(P,P)==0

SubjectAuthor
* Proving that P(P) != the correct x86 emulation of the input to H(P,P)olcott
+* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|`* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
| `* Re: Proving that P(P) != the correct x86 emulation of the input torthiebaud
|  `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|   +* Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)Otto J. Makela
|   |`- Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|   `* Re: Proving that P(P) != the correct x86 emulation of the input toFreethinker
|    `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|     `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|      `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       +* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|       |`* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       | `* Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)Mr Flibble
|       |  `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   +* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|       |   |`* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   | `* Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)Mr Flibble
|       |   |  `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |   `* Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)Mr Flibble
|       |   |    `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |     `* Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)Mr Flibble
|       |   |      `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |       +- Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)Mr Flibble
|       |   |       `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |        `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |         `* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|       |   |          `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |           `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |            `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |             `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |              `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |               `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                 +* Re: Proving that P(P) != the correct x86 emulation of the input toFreethinker
|       |   |                 |`- Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                 `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                  `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                   `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                    `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                     `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                      `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                       `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                        `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                         +* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|       |   |                         |`* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                         | `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                         |  +* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                         |  |`- Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                         |  `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                         |   `- Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                         `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                          `* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|       |   |                           +- Re: Proving that P(P) != the correct x86 emulation of the input toFreethinker
|       |   |                           +* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                           |+- Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                           |`* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|       |   |                           | `* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                           |  +* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|       |   |                           |  |`* Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                           |  | `* Re: Proving that P(P) != the correct x86 emulation of the input toMr Flibble
|       |   |                           |  |  `- Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                           |  `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       |   |                           |   `* Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)Keith Thompson
|       |   |                           |    +- Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   |                           |    `* Re: the correct x86 emulation of the input to H(P,P)==0olcott
|       |   |                           |     `* Re: the correct x86 emulation of the input to H(P,P)==0Mr Flibble
|       |   |                           |      `- Re: the correct x86 emulation of the input to H(P,P)==0olcott
|       |   |                           `* Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)Ben Bacarisse
|       |   |                            `- Re: Proving that P(P) != the correct x86 emulation of the input toolcott
|       |   `- Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|       `* Re: Proving that P(P) != the correct x86 emulation of the input toRichard Damon
|        `- Re: Proving that P(P) != the correct x86 emulation of the input toolcott
`* Re: Proving that P(P) != the correct x86 emulation of the input tojak
 `- Re: Proving that P(P) != the correct x86 emulation of the input toolcott

Pages:123
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<TJidncDGmaeShjv_nZ2dnUU7_81g4p2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21959&group=comp.lang.c#21959

  copy link   Newsgroups: 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 12 Jun 2022 11:57:51 -0500
Date: Sun, 12 Jun 2022 11:57:50 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<CbWdnUTPEtxUQzn_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611194703.000049ac@reddwarf.jmc>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<20220612175516.000007e1@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220612175516.000007e1@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <TJidncDGmaeShjv_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 390
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-EuIedlz4sya6FyjvGiPT4U065Ynz22YeCSSDzg7cSUS8Up48enSBUkMpaN8W3LbU1pZPWHS9i7uNy5v!k5MJ5zcFcU+hcO9I8KiAJj+nhrxyL1s96LjGOfPMVFfCotWlL8tTWco3wnnwP1T5QIKkEyMuscSq
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: 20311
 by: olcott - Sun, 12 Jun 2022 16:57 UTC

On 6/12/2022 11:55 AM, Mr Flibble wrote:
> On Sun, 12 Jun 2022 09:53:25 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>
>>> On 6/11/22 11:52 PM, olcott wrote:
>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent reviewer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls validation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001317](02)  8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>      jmp 00001319 [0000131b](01)  5d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>            pop ebp [0000131c](01)  c3
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>             ret Size in bytes:(0007)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could be
>>>>>>>>>>>>>>>>>>>>>>>>>>> doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>> of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set
>>>>>>>>>>>>>>>>>>>>>>>>>>> more than once.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing but
>>>>>>>>>>>>>>>>>>>>>>>>> smoke and
>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>> from the following
>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
>>>>>>>>>>>>>>>>>>>>>>>> proves your incompetence.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55
>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343][00212333][00212337] 8bec
>>>>>>>>>>>>>>>>>>>>>>>>     mov ebp,esp [00001345][00212333][00212337]
>>>>>>>>>>>>>>>>>>>>>>>> ebfe       jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more
>>>>>>>>>>>>>>>>>>>>>>> about your
>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact that
>>>>>>>>>>>>>>>>>>>>>> every competent
>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
>>>>>>>>>>>>>>>>>>>>>> trivial algorithm
>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
>>>>>>>>>>>>>>>>>>>>> size) different ways
>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
>>>>>>>>>>>>>>>>>>>>> infinite loop is the
>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected however
>>>>>>>>>>>>>>>>>>>>> you are not
>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
>>>>>>>>>>>>>>>>>>>> easily detected
>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind of
>>>>>>>>>>>>>>>>>>>> infinite loop at
>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
>>>>>>>>>>>>>>>>>>>> correctly detect one
>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
>>>>>>>>>>>>>>>>>>>> threw in some
>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just to
>>>>>>>>>>>>>>>>>>>> make my code a
>>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
>>>>>>>>>>>>>>>>>> project thus I am the
>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of
>>>>>>>>>>>>>>>>>> an H and P having
>>>>>>>>>>>>>>>>>> the following relationship is correctly decided as
>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>        For any program H that might determine if
>>>>>>>>>>>>>>>>>> programs halt, a
>>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>>        program P, called with some input, can pass
>>>>>>>>>>>>>>>>>> its own source and
>>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>>        H and then specifically do the opposite of
>>>>>>>>>>>>>>>>>> what H predicts P
>>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>>        can exist that handles this case.
>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
>>>>>>>>>>>>>>>>> halted so your H is not
>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
>>>>>>>>>>>>>>>>> according to what
>>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would
>>>>>>>>>>>>>>>> never stop running.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
>>>>>>>>>>>>>> You already admitted this thus proving that you are
>>>>>>>>>>>>>> lying now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If H aborts its simulation, and rejects the input, then
>>>>>>>>>>>>> THAT P, when properly simulated will reach its final
>>>>>>>>>>>>> state.
>>>>>>>>>>>>
>>>>>>>>>>>> The you believe a terminated process continues to execute
>>>>>>>>>>>> after it has been terminated is nuts. No one here believes
>>>>>>>>>>>> that a terminated process keeps running.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>>> partially simulated machine and not the machine itself.
>>>>>>>>>>
>>>>>>>>>> When the behavior of the complete and correct x86 emulation
>>>>>>>>>> of an input is correctly predicted to never stop running
>>>>>>>>>> then H(P,P)==0 is necessarily correct.
>>>>>>>>>
>>>>>>>>> Yes, and if H does that, it never returns that 0, so it is
>>>>>>>>> still wrong.
>>>>>>>>>
>>>>>>>>
>>>>>>>> With my latest update H correctly predicts that its complete
>>>>>>>> x86 emulation of P would never stop running before the second
>>>>>>>> emulation even begins.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Saying it doesn't make it true.
>>>>>>>
>>>>>>
>>>>>> This proves that it is true.
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>    if (H(x, x))
>>>>>>      HERE: goto HERE;
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> _P()
>>>>>> [00001352](01)  55              push ebp
>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>> [00001358](01)  50              push eax      // push P
>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>> [0000136b](01)  5d              pop ebp
>>>>>> [0000136c](01)  c3              ret
>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>
>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>> input that it must emulate the first seven instructions of P.
>>>>>> Because the seventh instruction of P repeats this process we can
>>>>>> know with complete certainty that the emulated P never reaches
>>>>>> its final “ret” instruction, thus never halts.
>>>>
>>>> The above is a sufficient summation of the algorithm to evaluate
>>>> the correctness of H(P,P)==0. H uses an x86 emulator to simulate
>>>> its input.
>>>
>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Except that the correct emulation needs to emulate that
>>>>> emulation, not just start it again.
>>>>>
>>>>
>>>> The updated version correctly aborts its x86 emulation of P as
>>>> soon as P calls H(P,P), thus there are zero nested emulations.
>>>
>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
>>> non-halting.
>>>
>>> What PROOF do you have that it is correct? It is just another of
>>> your FALSE presumptions.
>>>
>>> You can prove all sorts of stuff if you are allowed false premises.
>>>
>>>>
>>>> To provide context for other reviewers I created the x86utm
>>>> operating system so that I could show a simulating halt decider
>>>> halt decider C function that correctly decides the halt status of
>>>> another C function P where H and P have the halting problem
>>>> relationship as shown in the next paragraph.
>>>>
>>>>       For any program H that might determine if programs halt, a
>>>> "pathological"
>>>>       program P, called with some input, can pass its own source
>>>> and its input to
>>>>       H and then specifically do the opposite of what H predicts P
>>>> will do. No H
>>>>       can exist that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>>
>>>> Halting problem undecidability and infinitely nested simulation
>>>> (V5)
>>>>
>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>
>>>>
>>>>
>>>>
>>>
>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>
>>
>> That something is beyond your intellectual capacity is zero evidence
>> what-so-ever that it is false. Only competent software engineers can
>> validate my claim.
>
> Everybody else is stupid and you are correct. Mate, you are a tool.
>
> /Flibble
>


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<_kppK.37416$W3d4.20202@fx05.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21960&group=comp.lang.c#21960

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx05.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611192339.0000733d@reddwarf.jmc>
<CbWdnUTPEtxUQzn_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611194703.000049ac@reddwarf.jmc>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 397
Message-ID: <_kppK.37416$W3d4.20202@fx05.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, 12 Jun 2022 13:26:18 -0400
X-Received-Bytes: 20272
 by: Richard Damon - Sun, 12 Jun 2022 17:26 UTC

On 6/12/22 10:53 AM, olcott wrote:
> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>
>> On 6/11/22 11:52 PM, olcott wrote:
>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts prove
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers consistently
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent reviewer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my claims.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively verifiable
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls validation is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal mathematical
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by programs
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001317](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001319](02)  ebfe            jmp 00001319
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131b](01)  5d              pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c](01)  c3              ret
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Size in bytes:(0007) [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop if
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are necessary
>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could be
>>>>>>>>>>>>>>>>>>>>>>>>>> doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the emulation of
>>>>>>>>>>>>>>>>>>>>>>>>>> the x86
>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine (CPU/RAM)
>>>>>>>>>>>>>>>>>>>>>>>>>> state when the
>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set more
>>>>>>>>>>>>>>>>>>>>>>>>>> than once.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge that
>>>>>>>>>>>>>>>>>>>>>>>>> you are
>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing but
>>>>>>>>>>>>>>>>>>>>>>>> smoke and
>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can easily
>>>>>>>>>>>>>>>>>>>>>>> determine the
>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop from
>>>>>>>>>>>>>>>>>>>>>>> the following
>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this proves
>>>>>>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>>>>> incompetence.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution
>>>>>>>>>>>>>>>>>>>>>>> Trace Stored
>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov
>>>>>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more about
>>>>>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact that
>>>>>>>>>>>>>>>>>>>>> every competent
>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
>>>>>>>>>>>>>>>>>>>>> trivial algorithm
>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite behavior
>>>>>>>>>>>>>>>>>>>>> pattern.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM size)
>>>>>>>>>>>>>>>>>>>> different ways
>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above infinite
>>>>>>>>>>>>>>>>>>>> loop is the
>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected however you
>>>>>>>>>>>>>>>>>>>> are not
>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
>>>>>>>>>>>>>>>>>>> easily detected
>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind of
>>>>>>>>>>>>>>>>>>> infinite loop at
>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
>>>>>>>>>>>>>>>>>>> correctly detect one
>>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
>>>>>>>>>>>>>>>>>>> threw in some
>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just to
>>>>>>>>>>>>>>>>>>> make my code a
>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my project
>>>>>>>>>>>>>>>>> thus I am the
>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of an H
>>>>>>>>>>>>>>>>> and P having
>>>>>>>>>>>>>>>>> the following relationship is correctly decided as
>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>        For any program H that might determine if
>>>>>>>>>>>>>>>>> programs halt, a
>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>        program P, called with some input, can pass its
>>>>>>>>>>>>>>>>> own source and
>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>        H and then specifically do the opposite of what
>>>>>>>>>>>>>>>>> H predicts P
>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>        can exist that handles this case.
>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have halted
>>>>>>>>>>>>>>>> so your H is not
>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
>>>>>>>>>>>>>>>> according to what
>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would never
>>>>>>>>>>>>>>> stop running.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even posted
>>>>>>>>>>>>>> yourself, the trace of the simulation of the input to
>>>>>>>>>>>>>> H(P,P) that halts when H(P,,P) returns 0.
>>>>>>>>>>>>> The simulated P never ever reaches its final state.
>>>>>>>>>>>>> You already admitted this thus proving that you are lying now.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>
>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>
>>>>>>>>>>>> If H aborts its simulation, and rejects the input, then THAT
>>>>>>>>>>>> P, when properly simulated will reach its final state.
>>>>>>>>>>>
>>>>>>>>>>> The you believe a terminated process continues to execute
>>>>>>>>>>> after it has been terminated is nuts. No one here believes
>>>>>>>>>>> that a terminated process keeps running.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>> partially simulated machine and not the machine itself.
>>>>>>>>>
>>>>>>>>> When the behavior of the complete and correct x86 emulation of
>>>>>>>>> an input is correctly predicted to never stop running then
>>>>>>>>> H(P,P)==0 is necessarily correct.
>>>>>>>>
>>>>>>>> Yes, and if H does that, it never returns that 0, so it is still
>>>>>>>> wrong.
>>>>>>>>
>>>>>>>
>>>>>>> With my latest update H correctly predicts that its complete x86
>>>>>>> emulation of P would never stop running before the second
>>>>>>> emulation even begins.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Saying it doesn't make it true.
>>>>>>
>>>>>
>>>>> This proves that it is true.
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01)  55              push ebp
>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001358](01)  50              push eax      // push P
>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000135c](01)  51              push ecx      // push P
>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>> [00001362](03)  83c408          add esp,+08
>>>>> [00001365](02)  85c0            test eax,eax
>>>>> [00001367](02)  7402            jz 0000136b
>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>> [0000136b](01)  5d              pop ebp
>>>>> [0000136c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>> input that it must emulate the first seven instructions of P.
>>>>> Because the seventh instruction of P repeats this process we can
>>>>> know with complete certainty that the emulated P never reaches its
>>>>> final “ret” instruction, thus never halts.
>>>
>>> The above is a sufficient summation of the algorithm to evaluate the
>>> correctness of H(P,P)==0. H uses an x86 emulator to simulate its input.
>>>
>>
>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>
>>>>>
>>>>>
>>>>
>>>> Except that the correct emulation needs to emulate that emulation,
>>>> not just start it again.
>>>>
>>>
>>> The updated version correctly aborts its x86 emulation of P as soon
>>> as P calls H(P,P), thus there are zero nested emulations.
>>
>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of non-halting.
>>
>> What PROOF do you have that it is correct? It is just another of your
>> FALSE presumptions.
>>
>> You can prove all sorts of stuff if you are allowed false premises.
>>
>>>
>>> To provide context for other reviewers I created the x86utm operating
>>> system so that I could show a simulating halt decider halt decider C
>>> function that correctly decides the halt status of another C function
>>> P where H and P have the halting problem relationship as shown in the
>>> next paragraph.
>>>
>>>       For any program H that might determine if programs halt, a
>>> "pathological"
>>>       program P, called with some input, can pass its own source and
>>> its input to
>>>       H and then specifically do the opposite of what H predicts P
>>> will do. No H
>>>       can exist that handles this case.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>>
>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>
>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>
>>>
>>>
>>>
>>
>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>
>
> That something is beyond your intellectual capacity is zero evidence
> what-so-ever that it is false. Only competent software engineers can
> validate my claim.


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<20220612182842.00006d41@reddwarf.jmc>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21961&group=comp.lang.c#21961

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx05.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Message-ID: <20220612182842.00006d41@reddwarf.jmc>
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<CbWdnUTPEtxUQzn_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611194703.000049ac@reddwarf.jmc>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 432
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 12 Jun 2022 17:28:42 UTC
Date: Sun, 12 Jun 2022 18:28:42 +0100
X-Received-Bytes: 22280
 by: Mr Flibble - Sun, 12 Jun 2022 17:28 UTC

On Sun, 12 Jun 2022 13:26:18 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 6/12/22 10:53 AM, olcott wrote:
> > On 6/12/2022 7:02 AM, Richard Damon wrote:
> >>
> >> On 6/11/22 11:52 PM, olcott wrote:
> >>> On 6/11/2022 7:43 PM, Richard Damon wrote:
> >>>> On 6/11/22 8:03 PM, olcott wrote:
> >>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
> >>>>>> On 6/11/22 7:19 PM, olcott wrote:
> >>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
> >>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
> >>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
> >>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
> >>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
> >>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
> >>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
> >>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
> >>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
> >>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
> >>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
> >>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with yourself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls validation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is axiomatic.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of their meaning.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001317](02)  8bec
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319 [0000131b](01)  5d
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>              pop ebp [0000131c](01)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c3              ret Size in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes:(0007) [0000131c]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> if the infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
> >>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
> >>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
> >>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
> >>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
> >>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
> >>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
> >>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
> >>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could be
> >>>>>>>>>>>>>>>>>>>>>>>>>> doing naive
> >>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the emulation
> >>>>>>>>>>>>>>>>>>>>>>>>>> of the x86
> >>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
> >>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
> >>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
> >>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
> >>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set
> >>>>>>>>>>>>>>>>>>>>>>>>>> more than once.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
> >>>>>>>>>>>>>>>>>>>>>>>>> that you are
> >>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
> >>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
> >>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing but
> >>>>>>>>>>>>>>>>>>>>>>>> smoke and
> >>>>>>>>>>>>>>>>>>>>>>>> mirrors.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
> >>>>>>>>>>>>>>>>>>>>>>> easily determine the
> >>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
> >>>>>>>>>>>>>>>>>>>>>>> from the following
> >>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
> >>>>>>>>>>>>>>>>>>>>>>> proves your
> >>>>>>>>>>>>>>>>>>>>>>> incompetence.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
> >>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
> >>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55
> >>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343][00212333][00212337] 8bec
> >>>>>>>>>>>>>>>>>>>>>>>      mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
> >>>>>>>>>>>>>>>>>>>>>>> 00001345
> >>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
> >>>>>>>>>>>>>>>>>>>>>>> 00001345
> >>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
> >>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more
> >>>>>>>>>>>>>>>>>>>>>> about your
> >>>>>>>>>>>>>>>>>>>>>> character than anything else.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
> >>>>>>>>>>>>>>>>>>>>> that every competent
> >>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
> >>>>>>>>>>>>>>>>>>>>> trivial algorithm
> >>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
> >>>>>>>>>>>>>>>>>>>>> behavior pattern.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
> >>>>>>>>>>>>>>>>>>>> size) different ways
> >>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
> >>>>>>>>>>>>>>>>>>>> infinite loop is the
> >>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected however
> >>>>>>>>>>>>>>>>>>>> you are not
> >>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
> >>>>>>>>>>>>>>>>>>> easily detected
> >>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind of
> >>>>>>>>>>>>>>>>>>> infinite loop at
> >>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
> >>>>>>>>>>>>>>>>>>> correctly detect one
> >>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
> >>>>>>>>>>>>>>>>>>> threw in some
> >>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just
> >>>>>>>>>>>>>>>>>>> to make my code a
> >>>>>>>>>>>>>>>>>>> little more robust.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> YOU don't get to define scope.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
> >>>>>>>>>>>>>>>>> project thus I am the
> >>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of
> >>>>>>>>>>>>>>>>> an H and P having
> >>>>>>>>>>>>>>>>> the following relationship is correctly decided as
> >>>>>>>>>>>>>>>>> non-halting.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>        For any program H that might determine if
> >>>>>>>>>>>>>>>>> programs halt, a
> >>>>>>>>>>>>>>>>> "pathological"
> >>>>>>>>>>>>>>>>>        program P, called with some input, can pass
> >>>>>>>>>>>>>>>>> its own source and
> >>>>>>>>>>>>>>>>> its input to
> >>>>>>>>>>>>>>>>>        H and then specifically do the opposite of
> >>>>>>>>>>>>>>>>> what H predicts P
> >>>>>>>>>>>>>>>>> will do. No H
> >>>>>>>>>>>>>>>>>        can exist that handles this case.
> >>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
> >>>>>>>>>>>>>>>> halted so your H is not
> >>>>>>>>>>>>>>>> a program "that might determine if programs halt"
> >>>>>>>>>>>>>>>> according to what
> >>>>>>>>>>>>>>>> is in scope of your "research project".
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It is an easily verified fact that the correct and
> >>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would
> >>>>>>>>>>>>>>> never stop running.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
> >>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
> >>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
> >>>>>>>>>>>>> The simulated P never ever reaches its final state.
> >>>>>>>>>>>>> You already admitted this thus proving that you are
> >>>>>>>>>>>>> lying now.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Your missing words.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The simulation BY H, can't reach the final state.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If H aborts its simulation, and rejects the input, then
> >>>>>>>>>>>> THAT P, when properly simulated will reach its final
> >>>>>>>>>>>> state.
> >>>>>>>>>>>
> >>>>>>>>>>> The you believe a terminated process continues to execute
> >>>>>>>>>>> after it has been terminated is nuts. No one here
> >>>>>>>>>>> believes that a terminated process keeps running.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> And you seem to be mistaken that Halting is about the
> >>>>>>>>>> partially simulated machine and not the machine itself.
> >>>>>>>>>
> >>>>>>>>> When the behavior of the complete and correct x86 emulation
> >>>>>>>>> of an input is correctly predicted to never stop running
> >>>>>>>>> then H(P,P)==0 is necessarily correct.
> >>>>>>>>
> >>>>>>>> Yes, and if H does that, it never returns that 0, so it is
> >>>>>>>> still wrong.
> >>>>>>>>
> >>>>>>>
> >>>>>>> With my latest update H correctly predicts that its complete
> >>>>>>> x86 emulation of P would never stop running before the second
> >>>>>>> emulation even begins.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> Saying it doesn't make it true.
> >>>>>>
> >>>>>
> >>>>> This proves that it is true.
> >>>>>
> >>>>> void P(u32 x)
> >>>>> {
> >>>>>    if (H(x, x))
> >>>>>      HERE: goto HERE;
> >>>>>    return;
> >>>>> }
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>> }
> >>>>>
> >>>>> _P()
> >>>>> [00001352](01)  55              push ebp
> >>>>> [00001353](02)  8bec            mov ebp,esp
> >>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
> >>>>> [00001358](01)  50              push eax      // push P
> >>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> >>>>> [0000135c](01)  51              push ecx      // push P
> >>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
> >>>>> [00001362](03)  83c408          add esp,+08
> >>>>> [00001365](02)  85c0            test eax,eax
> >>>>> [00001367](02)  7402            jz 0000136b
> >>>>> [00001369](02)  ebfe            jmp 00001369
> >>>>> [0000136b](01)  5d              pop ebp
> >>>>> [0000136c](01)  c3              ret
> >>>>> Size in bytes:(0027) [0000136c]
> >>>>>
> >>>>> It is completely obvious that when H(P,P) correctly emulates
> >>>>> its input that it must emulate the first seven instructions of
> >>>>> P. Because the seventh instruction of P repeats this process we
> >>>>> can know with complete certainty that the emulated P never
> >>>>> reaches its final “ret” instruction, thus never halts.
> >>>
> >>> The above is a sufficient summation of the algorithm to evaluate
> >>> the correctness of H(P,P)==0. H uses an x86 emulator to simulate
> >>> its input.
> >>
> >> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
> >>
> >>>>>
> >>>>>
> >>>>
> >>>> Except that the correct emulation needs to emulate that
> >>>> emulation, not just start it again.
> >>>>
> >>>
> >>> The updated version correctly aborts its x86 emulation of P as
> >>> soon as P calls H(P,P), thus there are zero nested emulations.
> >>
> >> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
> >> non-halting.
> >>
> >> What PROOF do you have that it is correct? It is just another of
> >> your FALSE presumptions.
> >>
> >> You can prove all sorts of stuff if you are allowed false premises.
> >>
> >>>
> >>> To provide context for other reviewers I created the x86utm
> >>> operating system so that I could show a simulating halt decider
> >>> halt decider C function that correctly decides the halt status of
> >>> another C function P where H and P have the halting problem
> >>> relationship as shown in the next paragraph.
> >>>
> >>>       For any program H that might determine if programs halt, a
> >>> "pathological"
> >>>       program P, called with some input, can pass its own source
> >>> and its input to
> >>>       H and then specifically do the opposite of what H predicts
> >>> P will do. No H
> >>>       can exist that handles this case.
> >>> https://en.wikipedia.org/wiki/Halting_problem
> >>>
> >>>
> >>> Halting problem undecidability and infinitely nested simulation
> >>> (V5)
> >>>
> >>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>>
> >>>
> >>>
> >>>
> >>
> >> It is FALSE that P(P) calling H(P,P) proves non-halting.
> >>
> >
> > That something is beyond your intellectual capacity is zero
> > evidence what-so-ever that it is false. Only competent software
> > engineers can validate my claim.
>
> What, do you deny that when P(P) calls H(P,P) and it returns the 0 to
> it that P hatis? If so, then you have lied that you built P correctly.
>
> IF H(P,P) doesn't return the 0, then you have lied about what H does,
> or that it is actually the needed computation.
>
> The ONLY case where P(P) calling H(P,P) is actually non-halting is
> the case where H(P,P) never aborts its simulation, EVER, and such an
> H can't return 0 for H(P,P), so you lie that H is correct returning a
> value it never returns.
>
> Which LIE will you admit to? Or are there more than one of them?
>
> FAIL.


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<6sppK.16491$gjlb.9044@fx44.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21962&group=comp.lang.c#21962

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx44.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611194703.000049ac@reddwarf.jmc>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<20220612175516.000007e1@reddwarf.jmc>
<TJidncDGmaeShjv_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <TJidncDGmaeShjv_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 34
Message-ID: <6sppK.16491$gjlb.9044@fx44.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, 12 Jun 2022 13:33:51 -0400
X-Received-Bytes: 2911
 by: Richard Damon - Sun, 12 Jun 2022 17:33 UTC

On 6/12/22 12:57 PM, olcott wrote:
> On 6/12/2022 11:55 AM, Mr Flibble wrote:
>> On Sun, 12 Jun 2022 09:53:25 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>
>>>>
>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>
>>> That something is beyond your intellectual capacity is zero evidence
>>> what-so-ever that it is false. Only competent software engineers can
>>> validate my claim.
>>
>> Everybody else is stupid and you are correct. Mate, you are a tool.
>>
>> /Flibble
>>
>
> Only you and Richard.
>

So, everyone else who says you are wrong is right, and you admit to
being actually wrong?

You can't stand what I say, because I apparently can detect the core
flaws in your arguments and directly challenge them.

Your whole strategy is based on flawed logic, in part because you just
won't admit that there IS a core logic you need to follow.

This is because your basic idea about what is Truth is flawed an
inconsistent, but you just can't hear that.

Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<y8SdnWcbvoftszv_nZ2dnUU7_8zNnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21963&group=comp.lang.c#21963

  copy link   Newsgroups: 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: Sun, 12 Jun 2022 13:20:32 -0500
Date: Sun, 12 Jun 2022 13:20:30 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<20220612175516.000007e1@reddwarf.jmc>
<TJidncDGmaeShjv_nZ2dnUU7_81g4p2d@giganews.com>
<6sppK.16491$gjlb.9044@fx44.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <6sppK.16491$gjlb.9044@fx44.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <y8SdnWcbvoftszv_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 46
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-cBlBk78hdIbGOaPifOANaODKZkLh0NI6c8kC+xzOD9pR61bSN32FDRjqQ7FXtMYr1StrunrcLL1qHGw!5K6S8skE6zQFU+bfX11NiIHhcre/lpaLvWBGyiGhfZgis7iNATN2t0qMfaVIMkpi8GJVK40wFhVH
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: 3728
 by: olcott - Sun, 12 Jun 2022 18:20 UTC

On 6/12/2022 12:33 PM, Richard Damon wrote:
>
> On 6/12/22 12:57 PM, olcott wrote:
>> On 6/12/2022 11:55 AM, Mr Flibble wrote:
>>> On Sun, 12 Jun 2022 09:53:25 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>
>>>>>
>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>
>>>> That something is beyond your intellectual capacity is zero evidence
>>>> what-so-ever that it is false. Only competent software engineers can
>>>> validate my claim.
>>>
>>> Everybody else is stupid and you are correct. Mate, you are a tool.
>>>
>>> /Flibble
>>>
>>
>> Only you and Richard.
>>
>
> So, everyone else who says you are wrong is right, and you admit to
> being actually wrong?

Everyone else is sufficiently competent to explain their reasoning and
not directly contradict verifiable facts except for this one issue:

A halt decider must compute the mapping from its input finite strings to
an accept or reject state based on the actual behavior that is actually
specified by this input.

The problem where is that although I have proved that the correct and
complete x86 emulation of the inputs to H(P,P) would never stop running
they still believe that H should report that its input halts on the
basis of an entirely different sequence of instructions specified by the
execution of P(P).

--
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: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<y8SdnWEbvodosjv_nZ2dnUU7_8xh4p2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21964&group=comp.lang.c#21964

  copy link   Newsgroups: 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: Sun, 12 Jun 2022 13:27:01 -0500
Date: Sun, 12 Jun 2022 13:27:00 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<20220612175516.000007e1@reddwarf.jmc>
<TJidncDGmaeShjv_nZ2dnUU7_81g4p2d@giganews.com>
<6sppK.16491$gjlb.9044@fx44.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <6sppK.16491$gjlb.9044@fx44.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <y8SdnWEbvodosjv_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 54
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-aaTwlA+/aI84S31kblkNx5bfuqpzPtFYhnquh7L2TDxOqdPZMgl/aJCL0/KIg1bamNztcMdB0pE3NKQ!7cZ6dwfGUgT3Nlg25SMDq/SmcfLshddNsGAp2TzHzbmJkfnqxTx+msh+Gdv0kA2rLcfgpvHuSCtK
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: 3875
 by: olcott - Sun, 12 Jun 2022 18:27 UTC

On 6/12/2022 12:33 PM, Richard Damon wrote:
>
> On 6/12/22 12:57 PM, olcott wrote:
>> On 6/12/2022 11:55 AM, Mr Flibble wrote:
>>> On Sun, 12 Jun 2022 09:53:25 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>
>>>>>
>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>
>>>> That something is beyond your intellectual capacity is zero evidence
>>>> what-so-ever that it is false. Only competent software engineers can
>>>> validate my claim.
>>>
>>> Everybody else is stupid and you are correct. Mate, you are a tool.
>>>
>>> /Flibble
>>>
>>
>> Only you and Richard.
>>
>
> So, everyone else who says you are wrong is right, and you admit to
> being actually wrong?
>
> You can't stand what I say, because I apparently can detect the core
> flaws in your arguments and directly challenge them.
>
> Your whole strategy is based on flawed logic, in part because you just
> won't admit that there IS a core logic you need to follow.
>

This is the core logic:

The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete emulation of the input would never stop running, or reach its
“ret” instruction then the SHD aborts its emulation and correctly
returns 0.

> This is because your basic idea about what is Truth is flawed an
> inconsistent, but you just can't hear that.

--
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: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<t85cec$1ujn$2@gioia.aioe.org>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21965&group=comp.lang.c#21965

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!aioe.org!67c4kB/Q+zzT5YDC1WyvkQ.user.46.165.242.91.POSTED!not-for-mail
From: freethin...@mymail.com (Freethinker)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Date: Sun, 12 Jun 2022 20:48:44 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t85cec$1ujn$2@gioia.aioe.org>
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611194703.000049ac@reddwarf.jmc>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="64119"; posting-host="67c4kB/Q+zzT5YDC1WyvkQ.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: de-DE
 by: Freethinker - Sun, 12 Jun 2022 18:48 UTC

On 12.06.22 19:28, Mr Flibble wrote:
> On Sun, 12 Jun 2022 13:26:18 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 6/12/22 10:53 AM, olcott wrote:
>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>
>>>> On 6/11/22 11:52 PM, olcott wrote:
>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls validation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001317](02)  8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319 [0000131b](01)  5d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>              pop ebp [0000131c](01)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c3              ret Size in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes:(0007) [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could be
>>>>>>>>>>>>>>>>>>>>>>>>>>>> doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set
>>>>>>>>>>>>>>>>>>>>>>>>>>>> more than once.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
>>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
>>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing but
>>>>>>>>>>>>>>>>>>>>>>>>>> smoke and
>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
>>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>> from the following
>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
>>>>>>>>>>>>>>>>>>>>>>>>> proves your
>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55
>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343][00212333][00212337] 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>      mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more
>>>>>>>>>>>>>>>>>>>>>>>> about your
>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
>>>>>>>>>>>>>>>>>>>>>>> that every competent
>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
>>>>>>>>>>>>>>>>>>>>>>> trivial algorithm
>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
>>>>>>>>>>>>>>>>>>>>>> size) different ways
>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected however
>>>>>>>>>>>>>>>>>>>>>> you are not
>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
>>>>>>>>>>>>>>>>>>>>> easily detected
>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind of
>>>>>>>>>>>>>>>>>>>>> infinite loop at
>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
>>>>>>>>>>>>>>>>>>>>> correctly detect one
>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
>>>>>>>>>>>>>>>>>>>>> threw in some
>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just
>>>>>>>>>>>>>>>>>>>>> to make my code a
>>>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
>>>>>>>>>>>>>>>>>>> project thus I am the
>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of
>>>>>>>>>>>>>>>>>>> an H and P having
>>>>>>>>>>>>>>>>>>> the following relationship is correctly decided as
>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>        For any program H that might determine if
>>>>>>>>>>>>>>>>>>> programs halt, a
>>>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>>>        program P, called with some input, can pass
>>>>>>>>>>>>>>>>>>> its own source and
>>>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>>>        H and then specifically do the opposite of
>>>>>>>>>>>>>>>>>>> what H predicts P
>>>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>>>        can exist that handles this case.
>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
>>>>>>>>>>>>>>>>>> halted so your H is not
>>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
>>>>>>>>>>>>>>>>>> according to what
>>>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would
>>>>>>>>>>>>>>>>> never stop running.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
>>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
>>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
>>>>>>>>>>>>>>> You already admitted this thus proving that you are
>>>>>>>>>>>>>>> lying now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input, then
>>>>>>>>>>>>>> THAT P, when properly simulated will reach its final
>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The you believe a terminated process continues to execute
>>>>>>>>>>>>> after it has been terminated is nuts. No one here
>>>>>>>>>>>>> believes that a terminated process keeps running.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>>>> partially simulated machine and not the machine itself.
>>>>>>>>>>>
>>>>>>>>>>> When the behavior of the complete and correct x86 emulation
>>>>>>>>>>> of an input is correctly predicted to never stop running
>>>>>>>>>>> then H(P,P)==0 is necessarily correct.
>>>>>>>>>>
>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it is
>>>>>>>>>> still wrong.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With my latest update H correctly predicts that its complete
>>>>>>>>> x86 emulation of P would never stop running before the second
>>>>>>>>> emulation even begins.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Saying it doesn't make it true.
>>>>>>>>
>>>>>>>
>>>>>>> This proves that it is true.
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>    if (H(x, x))
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [00001352](01)  55              push ebp
>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>> [0000136c](01)  c3              ret
>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>
>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>> its input that it must emulate the first seven instructions of
>>>>>>> P. Because the seventh instruction of P repeats this process we
>>>>>>> can know with complete certainty that the emulated P never
>>>>>>> reaches its final “ret” instruction, thus never halts.
>>>>>
>>>>> The above is a sufficient summation of the algorithm to evaluate
>>>>> the correctness of H(P,P)==0. H uses an x86 emulator to simulate
>>>>> its input.
>>>>
>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Except that the correct emulation needs to emulate that
>>>>>> emulation, not just start it again.
>>>>>>
>>>>>
>>>>> The updated version correctly aborts its x86 emulation of P as
>>>>> soon as P calls H(P,P), thus there are zero nested emulations.
>>>>
>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
>>>> non-halting.
>>>>
>>>> What PROOF do you have that it is correct? It is just another of
>>>> your FALSE presumptions.
>>>>
>>>> You can prove all sorts of stuff if you are allowed false premises.
>>>>
>>>>>
>>>>> To provide context for other reviewers I created the x86utm
>>>>> operating system so that I could show a simulating halt decider
>>>>> halt decider C function that correctly decides the halt status of
>>>>> another C function P where H and P have the halting problem
>>>>> relationship as shown in the next paragraph.
>>>>>
>>>>>       For any program H that might determine if programs halt, a
>>>>> "pathological"
>>>>>       program P, called with some input, can pass its own source
>>>>> and its input to
>>>>>       H and then specifically do the opposite of what H predicts
>>>>> P will do. No H
>>>>>       can exist that handles this case.
>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation
>>>>> (V5)
>>>>>
>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>
>>>
>>> That something is beyond your intellectual capacity is zero
>>> evidence what-so-ever that it is false. Only competent software
>>> engineers can validate my claim.
>>
>> What, do you deny that when P(P) calls H(P,P) and it returns the 0 to
>> it that P hatis? If so, then you have lied that you built P correctly.
>>
>> IF H(P,P) doesn't return the 0, then you have lied about what H does,
>> or that it is actually the needed computation.
>>
>> The ONLY case where P(P) calling H(P,P) is actually non-halting is
>> the case where H(P,P) never aborts its simulation, EVER, and such an
>> H can't return 0 for H(P,P), so you lie that H is correct returning a
>> value it never returns.
>>
>> Which LIE will you admit to? Or are there more than one of them?
>>
>> FAIL.
>
> I agree Olcott is a liar: he keeps repeating the lie that I don't know
> what unreachable code is.
>
> Is there any point trying to continue to debate with a pathological
> liar?
>
> /Flibble
>
If you want to have even more fun, try with Trump.


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21966&group=comp.lang.c#21966

  copy link   Newsgroups: 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 12 Jun 2022 14:17:10 -0500
Date: Sun, 12 Jun 2022 14:17:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611194703.000049ac@reddwarf.jmc>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220612182842.00006d41@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 443
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-wYrOjeEXDdm/2n0ChtwoVFyAmbnLskSwPHTzSkD+IM2Bp8j1esBuyeXr2YhBXxaOJx+eXoGJWMMWheY!9BevYC/Btb/21dWeh0SEH6sJQ8WpRqfjxaYSaWRczJmn5xUM5+wcyF8uc1uJ9pBtec9egATIhAAO
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: 23098
 by: olcott - Sun, 12 Jun 2022 19:17 UTC

On 6/12/2022 12:28 PM, Mr Flibble wrote:
> On Sun, 12 Jun 2022 13:26:18 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 6/12/22 10:53 AM, olcott wrote:
>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>
>>>> On 6/11/22 11:52 PM, olcott wrote:
>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls validation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001317](02)  8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319 [0000131b](01)  5d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>              pop ebp [0000131c](01)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c3              ret Size in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes:(0007) [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could be
>>>>>>>>>>>>>>>>>>>>>>>>>>>> doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set
>>>>>>>>>>>>>>>>>>>>>>>>>>>> more than once.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
>>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
>>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing but
>>>>>>>>>>>>>>>>>>>>>>>>>> smoke and
>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
>>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>> from the following
>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
>>>>>>>>>>>>>>>>>>>>>>>>> proves your
>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55
>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343][00212333][00212337] 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>      mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more
>>>>>>>>>>>>>>>>>>>>>>>> about your
>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
>>>>>>>>>>>>>>>>>>>>>>> that every competent
>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
>>>>>>>>>>>>>>>>>>>>>>> trivial algorithm
>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
>>>>>>>>>>>>>>>>>>>>>> size) different ways
>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected however
>>>>>>>>>>>>>>>>>>>>>> you are not
>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
>>>>>>>>>>>>>>>>>>>>> easily detected
>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind of
>>>>>>>>>>>>>>>>>>>>> infinite loop at
>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
>>>>>>>>>>>>>>>>>>>>> correctly detect one
>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
>>>>>>>>>>>>>>>>>>>>> threw in some
>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just
>>>>>>>>>>>>>>>>>>>>> to make my code a
>>>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
>>>>>>>>>>>>>>>>>>> project thus I am the
>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of
>>>>>>>>>>>>>>>>>>> an H and P having
>>>>>>>>>>>>>>>>>>> the following relationship is correctly decided as
>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>        For any program H that might determine if
>>>>>>>>>>>>>>>>>>> programs halt, a
>>>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>>>        program P, called with some input, can pass
>>>>>>>>>>>>>>>>>>> its own source and
>>>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>>>        H and then specifically do the opposite of
>>>>>>>>>>>>>>>>>>> what H predicts P
>>>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>>>        can exist that handles this case.
>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
>>>>>>>>>>>>>>>>>> halted so your H is not
>>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
>>>>>>>>>>>>>>>>>> according to what
>>>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would
>>>>>>>>>>>>>>>>> never stop running.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
>>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
>>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
>>>>>>>>>>>>>>> You already admitted this thus proving that you are
>>>>>>>>>>>>>>> lying now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input, then
>>>>>>>>>>>>>> THAT P, when properly simulated will reach its final
>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The you believe a terminated process continues to execute
>>>>>>>>>>>>> after it has been terminated is nuts. No one here
>>>>>>>>>>>>> believes that a terminated process keeps running.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>>>> partially simulated machine and not the machine itself.
>>>>>>>>>>>
>>>>>>>>>>> When the behavior of the complete and correct x86 emulation
>>>>>>>>>>> of an input is correctly predicted to never stop running
>>>>>>>>>>> then H(P,P)==0 is necessarily correct.
>>>>>>>>>>
>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it is
>>>>>>>>>> still wrong.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With my latest update H correctly predicts that its complete
>>>>>>>>> x86 emulation of P would never stop running before the second
>>>>>>>>> emulation even begins.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Saying it doesn't make it true.
>>>>>>>>
>>>>>>>
>>>>>>> This proves that it is true.
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>    if (H(x, x))
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>> }
>>>>>>>
>>>>>>> _P()
>>>>>>> [00001352](01)  55              push ebp
>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>> [0000136c](01)  c3              ret
>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>
>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>> its input that it must emulate the first seven instructions of
>>>>>>> P. Because the seventh instruction of P repeats this process we
>>>>>>> can know with complete certainty that the emulated P never
>>>>>>> reaches its final “ret” instruction, thus never halts.
>>>>>
>>>>> The above is a sufficient summation of the algorithm to evaluate
>>>>> the correctness of H(P,P)==0. H uses an x86 emulator to simulate
>>>>> its input.
>>>>
>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Except that the correct emulation needs to emulate that
>>>>>> emulation, not just start it again.
>>>>>>
>>>>>
>>>>> The updated version correctly aborts its x86 emulation of P as
>>>>> soon as P calls H(P,P), thus there are zero nested emulations.
>>>>
>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
>>>> non-halting.
>>>>
>>>> What PROOF do you have that it is correct? It is just another of
>>>> your FALSE presumptions.
>>>>
>>>> You can prove all sorts of stuff if you are allowed false premises.
>>>>
>>>>>
>>>>> To provide context for other reviewers I created the x86utm
>>>>> operating system so that I could show a simulating halt decider
>>>>> halt decider C function that correctly decides the halt status of
>>>>> another C function P where H and P have the halting problem
>>>>> relationship as shown in the next paragraph.
>>>>>
>>>>>       For any program H that might determine if programs halt, a
>>>>> "pathological"
>>>>>       program P, called with some input, can pass its own source
>>>>> and its input to
>>>>>       H and then specifically do the opposite of what H predicts
>>>>> P will do. No H
>>>>>       can exist that handles this case.
>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation
>>>>> (V5)
>>>>>
>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>
>>>
>>> That something is beyond your intellectual capacity is zero
>>> evidence what-so-ever that it is false. Only competent software
>>> engineers can validate my claim.
>>
>> What, do you deny that when P(P) calls H(P,P) and it returns the 0 to
>> it that P hatis? If so, then you have lied that you built P correctly.
>>
>> IF H(P,P) doesn't return the 0, then you have lied about what H does,
>> or that it is actually the needed computation.
>>
>> The ONLY case where P(P) calling H(P,P) is actually non-halting is
>> the case where H(P,P) never aborts its simulation, EVER, and such an
>> H can't return 0 for H(P,P), so you lie that H is correct returning a
>> value it never returns.
>>
>> Which LIE will you admit to? Or are there more than one of them?
>>
>> FAIL.
>
> I agree Olcott is a liar: he keeps repeating the lie that I don't know
> what unreachable code is.
I saved a copy of this in case it ever comes up again.


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<JgrpK.6742$OT.537@fx39.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21967&group=comp.lang.c#21967

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.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.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 453
Message-ID: <JgrpK.6742$OT.537@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, 12 Jun 2022 15:38:16 -0400
X-Received-Bytes: 24260
 by: Richard Damon - Sun, 12 Jun 2022 19:38 UTC

On 6/12/22 3:17 PM, olcott wrote:
> On 6/12/2022 12:28 PM, Mr Flibble wrote:
>> On Sun, 12 Jun 2022 13:26:18 -0400
>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>>> On 6/12/22 10:53 AM, olcott wrote:
>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>
>>>>> On 6/11/22 11:52 PM, olcott wrote:
>>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls validation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001317](02)  8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>        jmp 00001319 [0000131b](01)  5d
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>               pop ebp [0000131c](01)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c3              ret Size in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes:(0007) [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more than once.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing but
>>>>>>>>>>>>>>>>>>>>>>>>>>> smoke and
>>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
>>>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>> from the following
>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
>>>>>>>>>>>>>>>>>>>>>>>>>> proves your
>>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
>>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55
>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343][00212333][00212337] 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>       mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp
>>>>>>>>>>>>>>>>>>>>>>>>>> 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
>>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more
>>>>>>>>>>>>>>>>>>>>>>>>> about your
>>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
>>>>>>>>>>>>>>>>>>>>>>>> that every competent
>>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
>>>>>>>>>>>>>>>>>>>>>>>> trivial algorithm
>>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
>>>>>>>>>>>>>>>>>>>>>>> size) different ways
>>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
>>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
>>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected however
>>>>>>>>>>>>>>>>>>>>>>> you are not
>>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
>>>>>>>>>>>>>>>>>>>>>> easily detected
>>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind of
>>>>>>>>>>>>>>>>>>>>>> infinite loop at
>>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
>>>>>>>>>>>>>>>>>>>>>> correctly detect one
>>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
>>>>>>>>>>>>>>>>>>>>>> threw in some
>>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just
>>>>>>>>>>>>>>>>>>>>>> to make my code a
>>>>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
>>>>>>>>>>>>>>>>>>>> project thus I am the
>>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of
>>>>>>>>>>>>>>>>>>>> an H and P having
>>>>>>>>>>>>>>>>>>>> the following relationship is correctly decided as
>>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>         For any program H that might determine if
>>>>>>>>>>>>>>>>>>>> programs halt, a
>>>>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>>>>         program P, called with some input, can pass
>>>>>>>>>>>>>>>>>>>> its own source and
>>>>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>>>>         H and then specifically do the opposite of
>>>>>>>>>>>>>>>>>>>> what H predicts P
>>>>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>>>>         can exist that handles this case.
>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
>>>>>>>>>>>>>>>>>>> halted so your H is not
>>>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
>>>>>>>>>>>>>>>>>>> according to what
>>>>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would
>>>>>>>>>>>>>>>>>> never stop running.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
>>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
>>>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
>>>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
>>>>>>>>>>>>>>>> You already admitted this thus proving that you are
>>>>>>>>>>>>>>>> lying now.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input, then
>>>>>>>>>>>>>>> THAT P, when properly simulated will reach its final
>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The you believe a terminated process continues to execute
>>>>>>>>>>>>>> after it has been terminated is nuts. No one here
>>>>>>>>>>>>>> believes that a terminated process keeps running.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>>>>> partially simulated machine and not the machine itself.
>>>>>>>>>>>>
>>>>>>>>>>>> When the behavior of the complete and correct x86 emulation
>>>>>>>>>>>> of an input is correctly predicted to never stop running
>>>>>>>>>>>> then H(P,P)==0 is necessarily correct.
>>>>>>>>>>>
>>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it is
>>>>>>>>>>> still wrong.
>>>>>>>>>>
>>>>>>>>>> With my latest update H correctly predicts that its complete
>>>>>>>>>> x86 emulation of P would never stop running before the second
>>>>>>>>>> emulation even begins.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Saying it doesn't make it true.
>>>>>>>>
>>>>>>>> This proves that it is true.
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>     if (H(x, x))
>>>>>>>>       HERE: goto HERE;
>>>>>>>>     return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>     Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00001352](01)  55              push ebp
>>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>>> [0000136c](01)  c3              ret
>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>
>>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>>> its input that it must emulate the first seven instructions of
>>>>>>>> P. Because the seventh instruction of P repeats this process we
>>>>>>>> can know with complete certainty that the emulated P never
>>>>>>>> reaches its final “ret” instruction, thus never halts.
>>>>>>
>>>>>> The above is a sufficient summation of the algorithm to evaluate
>>>>>> the correctness of H(P,P)==0. H uses an x86 emulator to simulate
>>>>>> its input.
>>>>>
>>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>>>>>>>
>>>>>>>
>>>>>>> Except that the correct emulation needs to emulate that
>>>>>>> emulation, not just start it again.
>>>>>>
>>>>>> The updated version correctly aborts its x86 emulation of P as
>>>>>> soon as P calls H(P,P), thus there are zero nested emulations.
>>>>>
>>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
>>>>> non-halting.
>>>>>
>>>>> What PROOF do you have that it is correct? It is just another of
>>>>> your FALSE presumptions.
>>>>>
>>>>> You can prove all sorts of stuff if you are allowed false premises.
>>>>>>
>>>>>> To provide context for other reviewers I created the x86utm
>>>>>> operating system so that I could show a simulating halt decider
>>>>>> halt decider C function that correctly decides the halt status of
>>>>>> another C function P where H and P have the halting problem
>>>>>> relationship as shown in the next paragraph.
>>>>>>
>>>>>>        For any program H that might determine if programs halt, a
>>>>>> "pathological"
>>>>>>        program P, called with some input, can pass its own source
>>>>>> and its input to
>>>>>>        H and then specifically do the opposite of what H predicts
>>>>>> P will do. No H
>>>>>>        can exist that handles this case.
>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>> (V5)
>>>>>>
>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>
>>>> That something is beyond your intellectual capacity is zero
>>>> evidence what-so-ever that it is false. Only competent software
>>>> engineers can validate my claim.
>>>
>>> What, do you deny that when P(P) calls H(P,P) and it returns the 0 to
>>> it that P hatis? If so, then you have lied that you built P correctly.
>>>
>>> IF H(P,P) doesn't return the 0, then you have lied about what H does,
>>> or that it is actually the needed computation.
>>>
>>> The ONLY case where P(P) calling H(P,P) is actually non-halting is
>>> the case where H(P,P) never aborts its simulation, EVER, and such an
>>> H can't return 0 for H(P,P), so you lie that H is correct returning a
>>> value it never returns.
>>>
>>> Which LIE will you admit to? Or are there more than one of them?
>>>
>>> FAIL.
>>
>> I agree Olcott is a liar: he keeps repeating the lie that I don't know
>> what unreachable code is.
> I saved a copy of this in case it ever comes up again.
>
> Below proves that you do not know that every instruction after
> [0000135d] is unreachable when you suggest that modifying the opcode at
> unreachable address 00001369 would change the behavior.


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<877d5loecp.fsf@bsb.me.uk>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21968&group=comp.lang.c#21968

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)
Followup-To: comp.theory
Date: Sun, 12 Jun 2022 20:45:26 +0100
Organization: A noiseless patient Spider
Lines: 21
Message-ID: <877d5loecp.fsf@bsb.me.uk>
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad>
<20220612182842.00006d41@reddwarf.jmc>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="c8dfa20b39e8ca79787b151b682fc94f";
logging-data="8666"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/sfslDG/YMCfY498X/nfOuKdFMsMC833o="
Cancel-Lock: sha1:9g1b6bb0kcgJ2Pf6bapZ+bRdDlU=
sha1:Ma+xjAljJv3QRZ5l7DW5zkTkCW4=
X-BSB-Auth: 1.98d49a354c309a10cc28.20220612204526BST.877d5loecp.fsf@bsb.me.uk
 by: Ben Bacarisse - Sun, 12 Jun 2022 19:45 UTC

Mr Flibble <flibble@reddwarf.jmc> writes:
> On Sun, 12 Jun 2022 13:26:18 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
<cut>

> Is there any point trying to continue to debate with a pathological
> liar?

Can I urge anyone who still wants to reply to add

Followup-To: comp.theory

to the header (as I have done here) or, ideally, simply ignore PO's
off-topic posts here? The same context is posted in several other
groups so I am not suggesting you don't reply if you feel the need.

And, since I am already posting, were all 390 lines of quoted material
really germane to your (or Richard's) point?

--
Ben.

Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<20220612204551.00006b65@reddwarf.jmc>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21969&group=comp.lang.c#21969

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx02.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Message-ID: <20220612204551.00006b65@reddwarf.jmc>
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<ltadnRCCH4YBeTn_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad>
<20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 485
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 12 Jun 2022 19:45:51 UTC
Date: Sun, 12 Jun 2022 20:45:51 +0100
X-Received-Bytes: 25311
 by: Mr Flibble - Sun, 12 Jun 2022 19:45 UTC

On Sun, 12 Jun 2022 14:17:08 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/12/2022 12:28 PM, Mr Flibble wrote:
> > On Sun, 12 Jun 2022 13:26:18 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 6/12/22 10:53 AM, olcott wrote:
> >>> On 6/12/2022 7:02 AM, Richard Damon wrote:
> >>>>
> >>>> On 6/11/22 11:52 PM, olcott wrote:
> >>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
> >>>>>> On 6/11/22 8:03 PM, olcott wrote:
> >>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
> >>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
> >>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
> >>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
> >>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
> >>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
> >>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
> >>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
> >>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
> >>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
> >>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
> >>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yourself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validation is axiomatic.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of their meaning.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001317](02)  8bec
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319 [0000131b](01)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5d pop ebp [0000131c](01)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c3              ret Size in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes:(0007) [0000131c]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if the infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> be doing naive
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> more than once.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
> >>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
> >>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
> >>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing
> >>>>>>>>>>>>>>>>>>>>>>>>>> but smoke and
> >>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
> >>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
> >>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
> >>>>>>>>>>>>>>>>>>>>>>>>> from the following
> >>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
> >>>>>>>>>>>>>>>>>>>>>>>>> proves your
> >>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
> >>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
> >>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55
> >>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343][00212333][00212337] 8bec
> >>>>>>>>>>>>>>>>>>>>>>>>>      mov ebp,esp
> >>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
> >>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
> >>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
> >>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more
> >>>>>>>>>>>>>>>>>>>>>>>> about your
> >>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
> >>>>>>>>>>>>>>>>>>>>>>> that every competent
> >>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
> >>>>>>>>>>>>>>>>>>>>>>> trivial algorithm
> >>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
> >>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
> >>>>>>>>>>>>>>>>>>>>>> size) different ways
> >>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
> >>>>>>>>>>>>>>>>>>>>>> infinite loop is the
> >>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected
> >>>>>>>>>>>>>>>>>>>>>> however you are not
> >>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
> >>>>>>>>>>>>>>>>>>>>> easily detected
> >>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind
> >>>>>>>>>>>>>>>>>>>>> of infinite loop at
> >>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
> >>>>>>>>>>>>>>>>>>>>> correctly detect one
> >>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
> >>>>>>>>>>>>>>>>>>>>> threw in some
> >>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just
> >>>>>>>>>>>>>>>>>>>>> to make my code a
> >>>>>>>>>>>>>>>>>>>>> little more robust.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
> >>>>>>>>>>>>>>>>>>> project thus I am the
> >>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of
> >>>>>>>>>>>>>>>>>>> an H and P having
> >>>>>>>>>>>>>>>>>>> the following relationship is correctly decided as
> >>>>>>>>>>>>>>>>>>> non-halting.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>        For any program H that might determine if
> >>>>>>>>>>>>>>>>>>> programs halt, a
> >>>>>>>>>>>>>>>>>>> "pathological"
> >>>>>>>>>>>>>>>>>>>        program P, called with some input, can
> >>>>>>>>>>>>>>>>>>> pass its own source and
> >>>>>>>>>>>>>>>>>>> its input to
> >>>>>>>>>>>>>>>>>>>        H and then specifically do the opposite of
> >>>>>>>>>>>>>>>>>>> what H predicts P
> >>>>>>>>>>>>>>>>>>> will do. No H
> >>>>>>>>>>>>>>>>>>>        can exist that handles this case.
> >>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
> >>>>>>>>>>>>>>>>>> halted so your H is not
> >>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
> >>>>>>>>>>>>>>>>>> according to what
> >>>>>>>>>>>>>>>>>> is in scope of your "research project".
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
> >>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would
> >>>>>>>>>>>>>>>>> never stop running.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
> >>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
> >>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
> >>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
> >>>>>>>>>>>>>>> You already admitted this thus proving that you are
> >>>>>>>>>>>>>>> lying now.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Your missing words.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If H aborts its simulation, and rejects the input, then
> >>>>>>>>>>>>>> THAT P, when properly simulated will reach its final
> >>>>>>>>>>>>>> state.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The you believe a terminated process continues to
> >>>>>>>>>>>>> execute after it has been terminated is nuts. No one
> >>>>>>>>>>>>> here believes that a terminated process keeps running.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> And you seem to be mistaken that Halting is about the
> >>>>>>>>>>>> partially simulated machine and not the machine itself.
> >>>>>>>>>>>
> >>>>>>>>>>> When the behavior of the complete and correct x86
> >>>>>>>>>>> emulation of an input is correctly predicted to never
> >>>>>>>>>>> stop running then H(P,P)==0 is necessarily correct.
> >>>>>>>>>>
> >>>>>>>>>> Yes, and if H does that, it never returns that 0, so it is
> >>>>>>>>>> still wrong.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> With my latest update H correctly predicts that its complete
> >>>>>>>>> x86 emulation of P would never stop running before the
> >>>>>>>>> second emulation even begins.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Saying it doesn't make it true.
> >>>>>>>>
> >>>>>>>
> >>>>>>> This proves that it is true.
> >>>>>>>
> >>>>>>> void P(u32 x)
> >>>>>>> {
> >>>>>>>    if (H(x, x))
> >>>>>>>      HERE: goto HERE;
> >>>>>>>    return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> int main()
> >>>>>>> {
> >>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>> }
> >>>>>>>
> >>>>>>> _P()
> >>>>>>> [00001352](01)  55              push ebp
> >>>>>>> [00001353](02)  8bec            mov ebp,esp
> >>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
> >>>>>>> [00001358](01)  50              push eax      // push P
> >>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> >>>>>>> [0000135c](01)  51              push ecx      // push P
> >>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
> >>>>>>> [00001362](03)  83c408          add esp,+08
> >>>>>>> [00001365](02)  85c0            test eax,eax
> >>>>>>> [00001367](02)  7402            jz 0000136b
> >>>>>>> [00001369](02)  ebfe            jmp 00001369
> >>>>>>> [0000136b](01)  5d              pop ebp
> >>>>>>> [0000136c](01)  c3              ret
> >>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>
> >>>>>>> It is completely obvious that when H(P,P) correctly emulates
> >>>>>>> its input that it must emulate the first seven instructions of
> >>>>>>> P. Because the seventh instruction of P repeats this process
> >>>>>>> we can know with complete certainty that the emulated P never
> >>>>>>> reaches its final “ret” instruction, thus never halts.
> >>>>>
> >>>>> The above is a sufficient summation of the algorithm to evaluate
> >>>>> the correctness of H(P,P)==0. H uses an x86 emulator to simulate
> >>>>> its input.
> >>>>
> >>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
> >>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> Except that the correct emulation needs to emulate that
> >>>>>> emulation, not just start it again.
> >>>>>>
> >>>>>
> >>>>> The updated version correctly aborts its x86 emulation of P as
> >>>>> soon as P calls H(P,P), thus there are zero nested emulations.
> >>>>
> >>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
> >>>> non-halting.
> >>>>
> >>>> What PROOF do you have that it is correct? It is just another of
> >>>> your FALSE presumptions.
> >>>>
> >>>> You can prove all sorts of stuff if you are allowed false
> >>>> premises.
> >>>>>
> >>>>> To provide context for other reviewers I created the x86utm
> >>>>> operating system so that I could show a simulating halt decider
> >>>>> halt decider C function that correctly decides the halt status
> >>>>> of another C function P where H and P have the halting problem
> >>>>> relationship as shown in the next paragraph.
> >>>>>
> >>>>>       For any program H that might determine if programs halt,
> >>>>> a "pathological"
> >>>>>       program P, called with some input, can pass its own
> >>>>> source and its input to
> >>>>>       H and then specifically do the opposite of what H
> >>>>> predicts P will do. No H
> >>>>>       can exist that handles this case.
> >>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>
> >>>>>
> >>>>> Halting problem undecidability and infinitely nested simulation
> >>>>> (V5)
> >>>>>
> >>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
> >>>>
> >>>
> >>> That something is beyond your intellectual capacity is zero
> >>> evidence what-so-ever that it is false. Only competent software
> >>> engineers can validate my claim.
> >>
> >> What, do you deny that when P(P) calls H(P,P) and it returns the 0
> >> to it that P hatis? If so, then you have lied that you built P
> >> correctly.
> >>
> >> IF H(P,P) doesn't return the 0, then you have lied about what H
> >> does, or that it is actually the needed computation.
> >>
> >> The ONLY case where P(P) calling H(P,P) is actually non-halting is
> >> the case where H(P,P) never aborts its simulation, EVER, and such
> >> an H can't return 0 for H(P,P), so you lie that H is correct
> >> returning a value it never returns.
> >>
> >> Which LIE will you admit to? Or are there more than one of them?
> >>
> >> FAIL.
> >
> > I agree Olcott is a liar: he keeps repeating the lie that I don't
> > know what unreachable code is.
> I saved a copy of this in case it ever comes up again.
>
> Below proves that you do not know that every instruction after
> [0000135d] is unreachable when you suggest that modifying the opcode
> at unreachable address 00001369 would change the behavior.


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21970&group=comp.lang.c#21970

  copy link   Newsgroups: 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: Sun, 12 Jun 2022 15:04:11 -0500
Date: Sun, 12 Jun 2022 15:04:09 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220612204551.00006b65@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 484
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-whf2WW0TJdPnTD7jfpJ2YI0vPW9p+8jJ6jQLrMgpCYcPbq5w5a2NPArzigR7t6M6HGqnf3Xa5N/Hp82!63cQopR/7akusSTEY7UCcTmIJziSqVBrsdGdEcaj+UfJqSm8n8OwaiLlqvFqrElAhbP7FGj4x26i
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: 25297
 by: olcott - Sun, 12 Jun 2022 20:04 UTC

On 6/12/2022 2:45 PM, Mr Flibble wrote:
> On Sun, 12 Jun 2022 14:17:08 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/12/2022 12:28 PM, Mr Flibble wrote:
>>> On Sun, 12 Jun 2022 13:26:18 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 6/12/22 10:53 AM, olcott wrote:
>>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/11/22 11:52 PM, olcott wrote:
>>>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>>>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validation is axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001317](02)  8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319 [0000131b](01)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5d pop ebp [0000131c](01)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c3              ret Size in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes:(0007) [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more than once.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing
>>>>>>>>>>>>>>>>>>>>>>>>>>>> but smoke and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
>>>>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>> from the following
>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
>>>>>>>>>>>>>>>>>>>>>>>>>>> proves your
>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
>>>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55
>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343][00212333][00212337] 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>      mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
>>>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more
>>>>>>>>>>>>>>>>>>>>>>>>>> about your
>>>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
>>>>>>>>>>>>>>>>>>>>>>>>> that every competent
>>>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
>>>>>>>>>>>>>>>>>>>>>>>>> trivial algorithm
>>>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
>>>>>>>>>>>>>>>>>>>>>>>> size) different ways
>>>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
>>>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected
>>>>>>>>>>>>>>>>>>>>>>>> however you are not
>>>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
>>>>>>>>>>>>>>>>>>>>>>> easily detected
>>>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind
>>>>>>>>>>>>>>>>>>>>>>> of infinite loop at
>>>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
>>>>>>>>>>>>>>>>>>>>>>> correctly detect one
>>>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
>>>>>>>>>>>>>>>>>>>>>>> threw in some
>>>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just
>>>>>>>>>>>>>>>>>>>>>>> to make my code a
>>>>>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
>>>>>>>>>>>>>>>>>>>>> project thus I am the
>>>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of
>>>>>>>>>>>>>>>>>>>>> an H and P having
>>>>>>>>>>>>>>>>>>>>> the following relationship is correctly decided as
>>>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>        For any program H that might determine if
>>>>>>>>>>>>>>>>>>>>> programs halt, a
>>>>>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>>>>>        program P, called with some input, can
>>>>>>>>>>>>>>>>>>>>> pass its own source and
>>>>>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>>>>>        H and then specifically do the opposite of
>>>>>>>>>>>>>>>>>>>>> what H predicts P
>>>>>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>>>>>        can exist that handles this case.
>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
>>>>>>>>>>>>>>>>>>>> halted so your H is not
>>>>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
>>>>>>>>>>>>>>>>>>>> according to what
>>>>>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would
>>>>>>>>>>>>>>>>>>> never stop running.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
>>>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
>>>>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
>>>>>>>>>>>>>>>>> You already admitted this thus proving that you are
>>>>>>>>>>>>>>>>> lying now.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input, then
>>>>>>>>>>>>>>>> THAT P, when properly simulated will reach its final
>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The you believe a terminated process continues to
>>>>>>>>>>>>>>> execute after it has been terminated is nuts. No one
>>>>>>>>>>>>>>> here believes that a terminated process keeps running.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>>>>>> partially simulated machine and not the machine itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When the behavior of the complete and correct x86
>>>>>>>>>>>>> emulation of an input is correctly predicted to never
>>>>>>>>>>>>> stop running then H(P,P)==0 is necessarily correct.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it is
>>>>>>>>>>>> still wrong.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> With my latest update H correctly predicts that its complete
>>>>>>>>>>> x86 emulation of P would never stop running before the
>>>>>>>>>>> second emulation even begins.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Saying it doesn't make it true.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This proves that it is true.
>>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>    if (H(x, x))
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00001352](01)  55              push ebp
>>>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>>>> [0000136c](01)  c3              ret
>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>
>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>>>> its input that it must emulate the first seven instructions of
>>>>>>>>> P. Because the seventh instruction of P repeats this process
>>>>>>>>> we can know with complete certainty that the emulated P never
>>>>>>>>> reaches its final “ret” instruction, thus never halts.
>>>>>>>
>>>>>>> The above is a sufficient summation of the algorithm to evaluate
>>>>>>> the correctness of H(P,P)==0. H uses an x86 emulator to simulate
>>>>>>> its input.
>>>>>>
>>>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that the correct emulation needs to emulate that
>>>>>>>> emulation, not just start it again.
>>>>>>>>
>>>>>>>
>>>>>>> The updated version correctly aborts its x86 emulation of P as
>>>>>>> soon as P calls H(P,P), thus there are zero nested emulations.
>>>>>>
>>>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
>>>>>> non-halting.
>>>>>>
>>>>>> What PROOF do you have that it is correct? It is just another of
>>>>>> your FALSE presumptions.
>>>>>>
>>>>>> You can prove all sorts of stuff if you are allowed false
>>>>>> premises.
>>>>>>>
>>>>>>> To provide context for other reviewers I created the x86utm
>>>>>>> operating system so that I could show a simulating halt decider
>>>>>>> halt decider C function that correctly decides the halt status
>>>>>>> of another C function P where H and P have the halting problem
>>>>>>> relationship as shown in the next paragraph.
>>>>>>>
>>>>>>>       For any program H that might determine if programs halt,
>>>>>>> a "pathological"
>>>>>>>       program P, called with some input, can pass its own
>>>>>>> source and its input to
>>>>>>>       H and then specifically do the opposite of what H
>>>>>>> predicts P will do. No H
>>>>>>>       can exist that handles this case.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>> (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>>>
>>>>>
>>>>> That something is beyond your intellectual capacity is zero
>>>>> evidence what-so-ever that it is false. Only competent software
>>>>> engineers can validate my claim.
>>>>
>>>> What, do you deny that when P(P) calls H(P,P) and it returns the 0
>>>> to it that P hatis? If so, then you have lied that you built P
>>>> correctly.
>>>>
>>>> IF H(P,P) doesn't return the 0, then you have lied about what H
>>>> does, or that it is actually the needed computation.
>>>>
>>>> The ONLY case where P(P) calling H(P,P) is actually non-halting is
>>>> the case where H(P,P) never aborts its simulation, EVER, and such
>>>> an H can't return 0 for H(P,P), so you lie that H is correct
>>>> returning a value it never returns.
>>>>
>>>> Which LIE will you admit to? Or are there more than one of them?
>>>>
>>>> FAIL.
>>>
>>> I agree Olcott is a liar: he keeps repeating the lie that I don't
>>> know what unreachable code is.
>> I saved a copy of this in case it ever comes up again.
>>
>> Below proves that you do not know that every instruction after
>> [0000135d] is unreachable when you suggest that modifying the opcode
>> at unreachable address 00001369 would change the behavior.
>
> That isn't proof that I don't know what unreachable code is (as I do);


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<xfSdnfQ56Oo32jv_nZ2dnUU7_83NnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21971&group=comp.lang.c#21971

  copy link   Newsgroups: 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 12 Jun 2022 15:08:10 -0500
Date: Sun, 12 Jun 2022 15:08:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<877d5loecp.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <877d5loecp.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <xfSdnfQ56Oo32jv_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 32
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-t6JGemnM9r1epZdGuIZXVDFmm2JivIYXlfdj4wVWXodvDryx2yfz+S7SDgIG6VXJdfBTVqjaL+3tslE!hqMwVWpMIJXEb4JXRQY/KSHtB9dpDZ0MiQW0owj1XR1062/rV/pWDCMsy8n0mWmQFu/9y6umkypA
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: 3223
 by: olcott - Sun, 12 Jun 2022 20:08 UTC

On 6/12/2022 2:45 PM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc> writes:
>> On Sun, 12 Jun 2022 13:26:18 -0400
>> Richard Damon <Richard@Damon-Family.org> wrote:
> <cut>
>
>> Is there any point trying to continue to debate with a pathological
>> liar?
>
> Can I urge anyone who still wants to reply to add
>
> Followup-To: comp.theory
>
> to the header (as I have done here) or, ideally, simply ignore PO's
> off-topic posts here? The same context is posted in several other
> groups so I am not suggesting you don't reply if you feel the need.
>
> And, since I am already posting, were all 390 lines of quoted material
> really germane to your (or Richard's) point?
>

This discussion is confined to the software engineering aspects of a
pair of C functions. It is confined to these two forums because the
people in other other forums have proven to not have sufficient
technical competence in software engineering.

--
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: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<20220612212345.0000633e@reddwarf.jmc>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21972&group=comp.lang.c#21972

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx02.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Message-ID: <20220612212345.0000633e@reddwarf.jmc>
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad>
<20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 499
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 12 Jun 2022 20:23:45 UTC
Date: Sun, 12 Jun 2022 21:23:45 +0100
X-Received-Bytes: 25392
 by: Mr Flibble - Sun, 12 Jun 2022 20:23 UTC

On Sun, 12 Jun 2022 15:04:09 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/12/2022 2:45 PM, Mr Flibble wrote:
> > On Sun, 12 Jun 2022 14:17:08 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/12/2022 12:28 PM, Mr Flibble wrote:
> >>> On Sun, 12 Jun 2022 13:26:18 -0400
> >>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>
> >>>> On 6/12/22 10:53 AM, olcott wrote:
> >>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
> >>>>>>
> >>>>>> On 6/11/22 11:52 PM, olcott wrote:
> >>>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
> >>>>>>>> On 6/11/22 8:03 PM, olcott wrote:
> >>>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
> >>>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
> >>>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
> >>>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
> >>>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
> >>>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
> >>>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
> >>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
> >>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or incompetent.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yourself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validation is axiomatic.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or leeway for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interpretation of their meaning.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001317](02)  8bec
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131b](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c](01) c3
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have taken the form of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop if the infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when anyone disagrees
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> detecting infinite loops;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be doing naive
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> set more than once.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> but smoke and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
> >>>>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
> >>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
> >>>>>>>>>>>>>>>>>>>>>>>>>>> from the following
> >>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
> >>>>>>>>>>>>>>>>>>>>>>>>>>> proves your
> >>>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
> >>>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec mov
> >>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [00001345][00212333][00212337]
> >>>>>>>>>>>>>>>>>>>>>>>>>>> ebfe jmp 00001345
> >>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal
> >>>>>>>>>>>>>>>>>>>>>>>>>> more about your
> >>>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
> >>>>>>>>>>>>>>>>>>>>>>>>> that every competent
> >>>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine
> >>>>>>>>>>>>>>>>>>>>>>>>> the trivial algorithm
> >>>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
> >>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
> >>>>>>>>>>>>>>>>>>>>>>>> size) different ways
> >>>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
> >>>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
> >>>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected
> >>>>>>>>>>>>>>>>>>>>>>>> however you are not
> >>>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general*
> >>>>>>>>>>>>>>>>>>>>>>>> case.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can
> >>>>>>>>>>>>>>>>>>>>>>> be easily detected
> >>>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind
> >>>>>>>>>>>>>>>>>>>>>>> of infinite loop at
> >>>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
> >>>>>>>>>>>>>>>>>>>>>>> correctly detect one
> >>>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested
> >>>>>>>>>>>>>>>>>>>>>>> simulation. I threw in some
> >>>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion
> >>>>>>>>>>>>>>>>>>>>>>> just to make my code a
> >>>>>>>>>>>>>>>>>>>>>>> little more robust.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
> >>>>>>>>>>>>>>>>>>>>> project thus I am the
> >>>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance
> >>>>>>>>>>>>>>>>>>>>> of an H and P having
> >>>>>>>>>>>>>>>>>>>>> the following relationship is correctly decided
> >>>>>>>>>>>>>>>>>>>>> as non-halting.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>        For any program H that might determine
> >>>>>>>>>>>>>>>>>>>>> if programs halt, a
> >>>>>>>>>>>>>>>>>>>>> "pathological"
> >>>>>>>>>>>>>>>>>>>>>        program P, called with some input, can
> >>>>>>>>>>>>>>>>>>>>> pass its own source and
> >>>>>>>>>>>>>>>>>>>>> its input to
> >>>>>>>>>>>>>>>>>>>>>        H and then specifically do the
> >>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P
> >>>>>>>>>>>>>>>>>>>>> will do. No H
> >>>>>>>>>>>>>>>>>>>>>        can exist that handles this case.
> >>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
> >>>>>>>>>>>>>>>>>>>> halted so your H is not
> >>>>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
> >>>>>>>>>>>>>>>>>>>> according to what
> >>>>>>>>>>>>>>>>>>>> is in scope of your "research project".
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
> >>>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P)
> >>>>>>>>>>>>>>>>>>> would never stop running.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
> >>>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
> >>>>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
> >>>>>>>>>>>>>>>>> You already admitted this thus proving that you are
> >>>>>>>>>>>>>>>>> lying now.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Your missing words.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input,
> >>>>>>>>>>>>>>>> then THAT P, when properly simulated will reach its
> >>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The you believe a terminated process continues to
> >>>>>>>>>>>>>>> execute after it has been terminated is nuts. No one
> >>>>>>>>>>>>>>> here believes that a terminated process keeps running.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
> >>>>>>>>>>>>>> partially simulated machine and not the machine
> >>>>>>>>>>>>>> itself.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> When the behavior of the complete and correct x86
> >>>>>>>>>>>>> emulation of an input is correctly predicted to never
> >>>>>>>>>>>>> stop running then H(P,P)==0 is necessarily correct.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it
> >>>>>>>>>>>> is still wrong.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> With my latest update H correctly predicts that its
> >>>>>>>>>>> complete x86 emulation of P would never stop running
> >>>>>>>>>>> before the second emulation even begins.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Saying it doesn't make it true.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> This proves that it is true.
> >>>>>>>>>
> >>>>>>>>> void P(u32 x)
> >>>>>>>>> {
> >>>>>>>>>    if (H(x, x))
> >>>>>>>>>      HERE: goto HERE;
> >>>>>>>>>    return;
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> int main()
> >>>>>>>>> {
> >>>>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> _P()
> >>>>>>>>> [00001352](01)  55              push ebp
> >>>>>>>>> [00001353](02)  8bec            mov ebp,esp
> >>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
> >>>>>>>>> [00001358](01)  50              push eax      // push P
> >>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> >>>>>>>>> [0000135c](01)  51              push ecx      // push P
> >>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
> >>>>>>>>> [00001362](03)  83c408          add esp,+08
> >>>>>>>>> [00001365](02)  85c0            test eax,eax
> >>>>>>>>> [00001367](02)  7402            jz 0000136b
> >>>>>>>>> [00001369](02)  ebfe            jmp 00001369
> >>>>>>>>> [0000136b](01)  5d              pop ebp
> >>>>>>>>> [0000136c](01)  c3              ret
> >>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>
> >>>>>>>>> It is completely obvious that when H(P,P) correctly emulates
> >>>>>>>>> its input that it must emulate the first seven instructions
> >>>>>>>>> of P. Because the seventh instruction of P repeats this
> >>>>>>>>> process we can know with complete certainty that the
> >>>>>>>>> emulated P never reaches its final “ret” instruction, thus
> >>>>>>>>> never halts.
> >>>>>>>
> >>>>>>> The above is a sufficient summation of the algorithm to
> >>>>>>> evaluate the correctness of H(P,P)==0. H uses an x86 emulator
> >>>>>>> to simulate its input.
> >>>>>>
> >>>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
> >>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Except that the correct emulation needs to emulate that
> >>>>>>>> emulation, not just start it again.
> >>>>>>>>
> >>>>>>>
> >>>>>>> The updated version correctly aborts its x86 emulation of P as
> >>>>>>> soon as P calls H(P,P), thus there are zero nested
> >>>>>>> emulations.
> >>>>>>
> >>>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
> >>>>>> non-halting.
> >>>>>>
> >>>>>> What PROOF do you have that it is correct? It is just another
> >>>>>> of your FALSE presumptions.
> >>>>>>
> >>>>>> You can prove all sorts of stuff if you are allowed false
> >>>>>> premises.
> >>>>>>>
> >>>>>>> To provide context for other reviewers I created the x86utm
> >>>>>>> operating system so that I could show a simulating halt
> >>>>>>> decider halt decider C function that correctly decides the
> >>>>>>> halt status of another C function P where H and P have the
> >>>>>>> halting problem relationship as shown in the next paragraph.
> >>>>>>>
> >>>>>>>       For any program H that might determine if programs
> >>>>>>> halt, a "pathological"
> >>>>>>>       program P, called with some input, can pass its own
> >>>>>>> source and its input to
> >>>>>>>       H and then specifically do the opposite of what H
> >>>>>>> predicts P will do. No H
> >>>>>>>       can exist that handles this case.
> >>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>
> >>>>>>>
> >>>>>>> Halting problem undecidability and infinitely nested
> >>>>>>> simulation (V5)
> >>>>>>>
> >>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
> >>>>>>
> >>>>>
> >>>>> That something is beyond your intellectual capacity is zero
> >>>>> evidence what-so-ever that it is false. Only competent software
> >>>>> engineers can validate my claim.
> >>>>
> >>>> What, do you deny that when P(P) calls H(P,P) and it returns the
> >>>> 0 to it that P hatis? If so, then you have lied that you built P
> >>>> correctly.
> >>>>
> >>>> IF H(P,P) doesn't return the 0, then you have lied about what H
> >>>> does, or that it is actually the needed computation.
> >>>>
> >>>> The ONLY case where P(P) calling H(P,P) is actually non-halting
> >>>> is the case where H(P,P) never aborts its simulation, EVER, and
> >>>> such an H can't return 0 for H(P,P), so you lie that H is correct
> >>>> returning a value it never returns.
> >>>>
> >>>> Which LIE will you admit to? Or are there more than one of them?
> >>>>
> >>>> FAIL.
> >>>
> >>> I agree Olcott is a liar: he keeps repeating the lie that I don't
> >>> know what unreachable code is.
> >> I saved a copy of this in case it ever comes up again.
> >>
> >> Below proves that you do not know that every instruction after
> >> [0000135d] is unreachable when you suggest that modifying the
> >> opcode at unreachable address 00001369 would change the behavior.
> >
> > That isn't proof that I don't know what unreachable code is (as I
> > do);
>
> It is proof that you are unable to correctly assess one instance of
> unreachable code thus do not understand the concept of unreachable
> code sufficiently well.


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<mc6dnVrXxey8zzv_nZ2dnUU7_8zNnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21973&group=comp.lang.c#21973

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.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: Sun, 12 Jun 2022 15:52:49 -0500
Date: Sun, 12 Jun 2022 15:52:47 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612212345.0000633e@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220612212345.0000633e@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <mc6dnVrXxey8zzv_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 484
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ErPAdcywZ0CqaOyrL9v2PL4bhHcptLcnN3HxXEQDYp6mfEXYHjxb9oOH7AxDZbOUrogm9pMjjaHk6GU!k1ad1XuQbhIEZJJOqiD6zuLWSwKplrr/iN+d192dP7aOEO70Jd8m1UQfhI+2wah4jGCCYBPTmJSp
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: 25753
X-Received-Bytes: 25846
 by: olcott - Sun, 12 Jun 2022 20:52 UTC

On 6/12/2022 3:23 PM, Mr Flibble wrote:
> On Sun, 12 Jun 2022 15:04:09 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/12/2022 2:45 PM, Mr Flibble wrote:
>>> On Sun, 12 Jun 2022 14:17:08 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/12/2022 12:28 PM, Mr Flibble wrote:
>>>>> On Sun, 12 Jun 2022 13:26:18 -0400
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 6/12/22 10:53 AM, olcott wrote:
>>>>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 6/11/22 11:52 PM, olcott wrote:
>>>>>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>>>>>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validation is axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interpretation of their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001317](02)  8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131b](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c](01) c3
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop if the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> detecting infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> set more than once.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but smoke and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the following
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proves your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec mov
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [00001345][00212333][00212337]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebfe jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal
>>>>>>>>>>>>>>>>>>>>>>>>>>>> more about your
>>>>>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
>>>>>>>>>>>>>>>>>>>>>>>>>>> that every competent
>>>>>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine
>>>>>>>>>>>>>>>>>>>>>>>>>>> the trivial algorithm
>>>>>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
>>>>>>>>>>>>>>>>>>>>>>>>>> size) different ways
>>>>>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
>>>>>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected
>>>>>>>>>>>>>>>>>>>>>>>>>> however you are not
>>>>>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general*
>>>>>>>>>>>>>>>>>>>>>>>>>> case.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can
>>>>>>>>>>>>>>>>>>>>>>>>> be easily detected
>>>>>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind
>>>>>>>>>>>>>>>>>>>>>>>>> of infinite loop at
>>>>>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
>>>>>>>>>>>>>>>>>>>>>>>>> correctly detect one
>>>>>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested
>>>>>>>>>>>>>>>>>>>>>>>>> simulation. I threw in some
>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion
>>>>>>>>>>>>>>>>>>>>>>>>> just to make my code a
>>>>>>>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
>>>>>>>>>>>>>>>>>>>>>>> project thus I am the
>>>>>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance
>>>>>>>>>>>>>>>>>>>>>>> of an H and P having
>>>>>>>>>>>>>>>>>>>>>>> the following relationship is correctly decided
>>>>>>>>>>>>>>>>>>>>>>> as non-halting.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>        For any program H that might determine
>>>>>>>>>>>>>>>>>>>>>>> if programs halt, a
>>>>>>>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>>>>>>>        program P, called with some input, can
>>>>>>>>>>>>>>>>>>>>>>> pass its own source and
>>>>>>>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>>>>>>>        H and then specifically do the
>>>>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P
>>>>>>>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>>>>>>>        can exist that handles this case.
>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
>>>>>>>>>>>>>>>>>>>>>> halted so your H is not
>>>>>>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
>>>>>>>>>>>>>>>>>>>>>> according to what
>>>>>>>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>> would never stop running.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
>>>>>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
>>>>>>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
>>>>>>>>>>>>>>>>>>> You already admitted this thus proving that you are
>>>>>>>>>>>>>>>>>>> lying now.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input,
>>>>>>>>>>>>>>>>>> then THAT P, when properly simulated will reach its
>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The you believe a terminated process continues to
>>>>>>>>>>>>>>>>> execute after it has been terminated is nuts. No one
>>>>>>>>>>>>>>>>> here believes that a terminated process keeps running.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>>>>>>>> partially simulated machine and not the machine
>>>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When the behavior of the complete and correct x86
>>>>>>>>>>>>>>> emulation of an input is correctly predicted to never
>>>>>>>>>>>>>>> stop running then H(P,P)==0 is necessarily correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it
>>>>>>>>>>>>>> is still wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> With my latest update H correctly predicts that its
>>>>>>>>>>>>> complete x86 emulation of P would never stop running
>>>>>>>>>>>>> before the second emulation even begins.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Saying it doesn't make it true.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This proves that it is true.
>>>>>>>>>>>
>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [00001352](01)  55              push ebp
>>>>>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>>>>>> [0000136c](01)  c3              ret
>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>
>>>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>>>>>> its input that it must emulate the first seven instructions
>>>>>>>>>>> of P. Because the seventh instruction of P repeats this
>>>>>>>>>>> process we can know with complete certainty that the
>>>>>>>>>>> emulated P never reaches its final “ret” instruction, thus
>>>>>>>>>>> never halts.
>>>>>>>>>
>>>>>>>>> The above is a sufficient summation of the algorithm to
>>>>>>>>> evaluate the correctness of H(P,P)==0. H uses an x86 emulator
>>>>>>>>> to simulate its input.
>>>>>>>>
>>>>>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except that the correct emulation needs to emulate that
>>>>>>>>>> emulation, not just start it again.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The updated version correctly aborts its x86 emulation of P as
>>>>>>>>> soon as P calls H(P,P), thus there are zero nested
>>>>>>>>> emulations.
>>>>>>>>
>>>>>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
>>>>>>>> non-halting.
>>>>>>>>
>>>>>>>> What PROOF do you have that it is correct? It is just another
>>>>>>>> of your FALSE presumptions.
>>>>>>>>
>>>>>>>> You can prove all sorts of stuff if you are allowed false
>>>>>>>> premises.
>>>>>>>>>
>>>>>>>>> To provide context for other reviewers I created the x86utm
>>>>>>>>> operating system so that I could show a simulating halt
>>>>>>>>> decider halt decider C function that correctly decides the
>>>>>>>>> halt status of another C function P where H and P have the
>>>>>>>>> halting problem relationship as shown in the next paragraph.
>>>>>>>>>
>>>>>>>>>       For any program H that might determine if programs
>>>>>>>>> halt, a "pathological"
>>>>>>>>>       program P, called with some input, can pass its own
>>>>>>>>> source and its input to
>>>>>>>>>       H and then specifically do the opposite of what H
>>>>>>>>> predicts P will do. No H
>>>>>>>>>       can exist that handles this case.
>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>> simulation (V5)
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>>>>>
>>>>>>>
>>>>>>> That something is beyond your intellectual capacity is zero
>>>>>>> evidence what-so-ever that it is false. Only competent software
>>>>>>> engineers can validate my claim.
>>>>>>
>>>>>> What, do you deny that when P(P) calls H(P,P) and it returns the
>>>>>> 0 to it that P hatis? If so, then you have lied that you built P
>>>>>> correctly.
>>>>>>
>>>>>> IF H(P,P) doesn't return the 0, then you have lied about what H
>>>>>> does, or that it is actually the needed computation.
>>>>>>
>>>>>> The ONLY case where P(P) calling H(P,P) is actually non-halting
>>>>>> is the case where H(P,P) never aborts its simulation, EVER, and
>>>>>> such an H can't return 0 for H(P,P), so you lie that H is correct
>>>>>> returning a value it never returns.
>>>>>>
>>>>>> Which LIE will you admit to? Or are there more than one of them?
>>>>>>
>>>>>> FAIL.
>>>>>
>>>>> I agree Olcott is a liar: he keeps repeating the lie that I don't
>>>>> know what unreachable code is.
>>>> I saved a copy of this in case it ever comes up again.
>>>>
>>>> Below proves that you do not know that every instruction after
>>>> [0000135d] is unreachable when you suggest that modifying the
>>>> opcode at unreachable address 00001369 would change the behavior.
>>>
>>> That isn't proof that I don't know what unreachable code is (as I
>>> do);
>>
>> It is proof that you are unable to correctly assess one instance of
>> unreachable code thus do not understand the concept of unreachable
>> code sufficiently well.
>
> No, I fully understand what unreachable code is, the problem is your
> inability to comprehend English, to follow a simple argument and not
> to pathologically lie when you have exhausted all other avenues of
> reasonable (or in your case unreasonable) debate.
>


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<20220612215951.00003ea0@reddwarf.jmc>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21974&group=comp.lang.c#21974

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx02.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Message-ID: <20220612215951.00003ea0@reddwarf.jmc>
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad>
<20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612212345.0000633e@reddwarf.jmc>
<mc6dnVrXxey8zzv_nZ2dnUU7_8zNnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 526
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Sun, 12 Jun 2022 20:59:51 UTC
Date: Sun, 12 Jun 2022 21:59:51 +0100
X-Received-Bytes: 27887
 by: Mr Flibble - Sun, 12 Jun 2022 20:59 UTC

On Sun, 12 Jun 2022 15:52:47 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/12/2022 3:23 PM, Mr Flibble wrote:
> > On Sun, 12 Jun 2022 15:04:09 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/12/2022 2:45 PM, Mr Flibble wrote:
> >>> On Sun, 12 Jun 2022 14:17:08 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/12/2022 12:28 PM, Mr Flibble wrote:
> >>>>> On Sun, 12 Jun 2022 13:26:18 -0400
> >>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>
> >>>>>> On 6/12/22 10:53 AM, olcott wrote:
> >>>>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
> >>>>>>>>
> >>>>>>>> On 6/11/22 11:52 PM, olcott wrote:
> >>>>>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
> >>>>>>>>>> On 6/11/22 8:03 PM, olcott wrote:
> >>>>>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
> >>>>>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
> >>>>>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
> >>>>>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
> >>>>>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
> >>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -0500 olcott <NoOne@NoWhere.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> facts prove that I am
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or incompetent.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yourself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validation is axiomatic.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ambiguity or leeway for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interpretation of their meaning.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and infinite loop anyone
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> objectively incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001317](02)  8bec
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131b](01) 5d pop ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c](01) c3
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have taken the form of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is unreachable in P so
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the above function is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop if the infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point are you trying to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when anyone disagrees
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> detecting infinite loops;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above infinite loop is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> software engineers.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could be doing naive
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> set more than once.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> acknowledge that you are
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what a correct infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nothing but smoke and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> can easily determine the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop from the following
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> this proves your
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 55 push ebp
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec mov
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [00001345][00212333][00212337]
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebfe jmp 00001345
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Detected Simulation Stopped
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> more about your
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable
> >>>>>>>>>>>>>>>>>>>>>>>>>>> fact that every competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the trivial algorithm
> >>>>>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
> >>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine
> >>>>>>>>>>>>>>>>>>>>>>>>>> RAM size) different ways
> >>>>>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
> >>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
> >>>>>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected
> >>>>>>>>>>>>>>>>>>>>>>>>>> however you are not
> >>>>>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general*
> >>>>>>>>>>>>>>>>>>>>>>>>>> case.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can
> >>>>>>>>>>>>>>>>>>>>>>>>> be easily detected
> >>>>>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any
> >>>>>>>>>>>>>>>>>>>>>>>>> kind of infinite loop at
> >>>>>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs
> >>>>>>>>>>>>>>>>>>>>>>>>> to correctly detect one
> >>>>>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested
> >>>>>>>>>>>>>>>>>>>>>>>>> simulation. I threw in some
> >>>>>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion
> >>>>>>>>>>>>>>>>>>>>>>>>> just to make my code a
> >>>>>>>>>>>>>>>>>>>>>>>>> little more robust.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project
> >>>>>>>>>>>>>>>>>>>>>>> (my project thus I am the
> >>>>>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one
> >>>>>>>>>>>>>>>>>>>>>>> instance of an H and P having
> >>>>>>>>>>>>>>>>>>>>>>> the following relationship is correctly
> >>>>>>>>>>>>>>>>>>>>>>> decided as non-halting.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>        For any program H that might
> >>>>>>>>>>>>>>>>>>>>>>> determine if programs halt, a
> >>>>>>>>>>>>>>>>>>>>>>> "pathological"
> >>>>>>>>>>>>>>>>>>>>>>>        program P, called with some input,
> >>>>>>>>>>>>>>>>>>>>>>> can pass its own source and
> >>>>>>>>>>>>>>>>>>>>>>> its input to
> >>>>>>>>>>>>>>>>>>>>>>>        H and then specifically do the
> >>>>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P
> >>>>>>>>>>>>>>>>>>>>>>> will do. No H
> >>>>>>>>>>>>>>>>>>>>>>>        can exist that handles this case.
> >>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
> >>>>>>>>>>>>>>>>>>>>>> halted so your H is not
> >>>>>>>>>>>>>>>>>>>>>> a program "that might determine if programs
> >>>>>>>>>>>>>>>>>>>>>> halt" according to what
> >>>>>>>>>>>>>>>>>>>>>> is in scope of your "research project".
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct
> >>>>>>>>>>>>>>>>>>>>> and complete x86 emulation of the input to
> >>>>>>>>>>>>>>>>>>>>> H(P,P) would never stop running.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
> >>>>>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of
> >>>>>>>>>>>>>>>>>>>> the input to H(P,P) that halts when H(P,,P)
> >>>>>>>>>>>>>>>>>>>> returns 0.
> >>>>>>>>>>>>>>>>>>> The simulated P never ever reaches its final
> >>>>>>>>>>>>>>>>>>> state. You already admitted this thus proving
> >>>>>>>>>>>>>>>>>>> that you are lying now.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Your missing words.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input,
> >>>>>>>>>>>>>>>>>> then THAT P, when properly simulated will reach its
> >>>>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The you believe a terminated process continues to
> >>>>>>>>>>>>>>>>> execute after it has been terminated is nuts. No one
> >>>>>>>>>>>>>>>>> here believes that a terminated process keeps
> >>>>>>>>>>>>>>>>> running.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
> >>>>>>>>>>>>>>>> partially simulated machine and not the machine
> >>>>>>>>>>>>>>>> itself.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> When the behavior of the complete and correct x86
> >>>>>>>>>>>>>>> emulation of an input is correctly predicted to never
> >>>>>>>>>>>>>>> stop running then H(P,P)==0 is necessarily correct.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it
> >>>>>>>>>>>>>> is still wrong.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> With my latest update H correctly predicts that its
> >>>>>>>>>>>>> complete x86 emulation of P would never stop running
> >>>>>>>>>>>>> before the second emulation even begins.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Saying it doesn't make it true.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> This proves that it is true.
> >>>>>>>>>>>
> >>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>> {
> >>>>>>>>>>>    if (H(x, x))
> >>>>>>>>>>>      HERE: goto HERE;
> >>>>>>>>>>>    return;
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> int main()
> >>>>>>>>>>> {
> >>>>>>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
> >>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> _P()
> >>>>>>>>>>> [00001352](01)  55              push ebp
> >>>>>>>>>>> [00001353](02)  8bec            mov ebp,esp
> >>>>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
> >>>>>>>>>>> [00001358](01)  50              push eax      // push P
> >>>>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> >>>>>>>>>>> [0000135c](01)  51              push ecx      // push P
> >>>>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
> >>>>>>>>>>> [00001362](03)  83c408          add esp,+08
> >>>>>>>>>>> [00001365](02)  85c0            test eax,eax
> >>>>>>>>>>> [00001367](02)  7402            jz 0000136b
> >>>>>>>>>>> [00001369](02)  ebfe            jmp 00001369
> >>>>>>>>>>> [0000136b](01)  5d              pop ebp
> >>>>>>>>>>> [0000136c](01)  c3              ret
> >>>>>>>>>>> Size in bytes:(0027) [0000136c]
> >>>>>>>>>>>
> >>>>>>>>>>> It is completely obvious that when H(P,P) correctly
> >>>>>>>>>>> emulates its input that it must emulate the first seven
> >>>>>>>>>>> instructions of P. Because the seventh instruction of P
> >>>>>>>>>>> repeats this process we can know with complete certainty
> >>>>>>>>>>> that the emulated P never reaches its final “ret”
> >>>>>>>>>>> instruction, thus never halts.
> >>>>>>>>>
> >>>>>>>>> The above is a sufficient summation of the algorithm to
> >>>>>>>>> evaluate the correctness of H(P,P)==0. H uses an x86
> >>>>>>>>> emulator to simulate its input.
> >>>>>>>>
> >>>>>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
> >>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Except that the correct emulation needs to emulate that
> >>>>>>>>>> emulation, not just start it again.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The updated version correctly aborts its x86 emulation of P
> >>>>>>>>> as soon as P calls H(P,P), thus there are zero nested
> >>>>>>>>> emulations.
> >>>>>>>>
> >>>>>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
> >>>>>>>> non-halting.
> >>>>>>>>
> >>>>>>>> What PROOF do you have that it is correct? It is just another
> >>>>>>>> of your FALSE presumptions.
> >>>>>>>>
> >>>>>>>> You can prove all sorts of stuff if you are allowed false
> >>>>>>>> premises.
> >>>>>>>>>
> >>>>>>>>> To provide context for other reviewers I created the x86utm
> >>>>>>>>> operating system so that I could show a simulating halt
> >>>>>>>>> decider halt decider C function that correctly decides the
> >>>>>>>>> halt status of another C function P where H and P have the
> >>>>>>>>> halting problem relationship as shown in the next paragraph.
> >>>>>>>>>
> >>>>>>>>>       For any program H that might determine if programs
> >>>>>>>>> halt, a "pathological"
> >>>>>>>>>       program P, called with some input, can pass its own
> >>>>>>>>> source and its input to
> >>>>>>>>>       H and then specifically do the opposite of what H
> >>>>>>>>> predicts P will do. No H
> >>>>>>>>>       can exist that handles this case.
> >>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Halting problem undecidability and infinitely nested
> >>>>>>>>> simulation (V5)
> >>>>>>>>>
> >>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
> >>>>>>>>
> >>>>>>>
> >>>>>>> That something is beyond your intellectual capacity is zero
> >>>>>>> evidence what-so-ever that it is false. Only competent
> >>>>>>> software engineers can validate my claim.
> >>>>>>
> >>>>>> What, do you deny that when P(P) calls H(P,P) and it returns
> >>>>>> the 0 to it that P hatis? If so, then you have lied that you
> >>>>>> built P correctly.
> >>>>>>
> >>>>>> IF H(P,P) doesn't return the 0, then you have lied about what H
> >>>>>> does, or that it is actually the needed computation.
> >>>>>>
> >>>>>> The ONLY case where P(P) calling H(P,P) is actually non-halting
> >>>>>> is the case where H(P,P) never aborts its simulation, EVER, and
> >>>>>> such an H can't return 0 for H(P,P), so you lie that H is
> >>>>>> correct returning a value it never returns.
> >>>>>>
> >>>>>> Which LIE will you admit to? Or are there more than one of
> >>>>>> them?
> >>>>>>
> >>>>>> FAIL.
> >>>>>
> >>>>> I agree Olcott is a liar: he keeps repeating the lie that I
> >>>>> don't know what unreachable code is.
> >>>> I saved a copy of this in case it ever comes up again.
> >>>>
> >>>> Below proves that you do not know that every instruction after
> >>>> [0000135d] is unreachable when you suggest that modifying the
> >>>> opcode at unreachable address 00001369 would change the
> >>>> behavior.
> >>>
> >>> That isn't proof that I don't know what unreachable code is (as I
> >>> do);
> >>
> >> It is proof that you are unable to correctly assess one instance of
> >> unreachable code thus do not understand the concept of unreachable
> >> code sufficiently well.
> >
> > No, I fully understand what unreachable code is, the problem is your
> > inability to comprehend English, to follow a simple argument and not
> > to pathologically lie when you have exhausted all other avenues of
> > reasonable (or in your case unreasonable) debate.
> >
>
> It is a very common dishonest tactic to change the subject for the
> purpose of fake rebuttal.
>
> Do you now understand that every address after [0000135d] is
> unreachable by the correctly emulated input to H(P,P)?
>
> (You did not understand this previously)
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> It is completely obvious that when H(P,P) correctly emulates its
> input that it must emulate the first seven instructions of P. Because
> the seventh instruction of P repeats this process we can know with
> complete certainty that the emulated P never reaches its final “ret”
> instruction, thus never halts.

Click here to read the complete article

Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<fv6dnUH4x56vyDv_nZ2dnUU7_8xh4p2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21975&group=comp.lang.c#21975

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.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: Sun, 12 Jun 2022 16:05:54 -0500
Date: Sun, 12 Jun 2022 16:05:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612212345.0000633e@reddwarf.jmc>
<mc6dnVrXxey8zzv_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220612215951.00003ea0@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220612215951.00003ea0@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <fv6dnUH4x56vyDv_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 512
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Cd6GnBKp/b0CnyK240u0aeSlK7+dQ5A3B2vEP70oRTVa/CVgDK6zCzriCSDHn3CbwBWyxiGHHseOf5g!NPVFwbIWJgIoXlexJCPFywzOq5hcGZNz5Wd89h0/J62Ue/GfvbFdMFsAc8kU6dN3pmEtBxTX47xU
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: 27484
X-Received-Bytes: 27577
 by: olcott - Sun, 12 Jun 2022 21:05 UTC

On 6/12/2022 3:59 PM, Mr Flibble wrote:
> On Sun, 12 Jun 2022 15:52:47 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/12/2022 3:23 PM, Mr Flibble wrote:
>>> On Sun, 12 Jun 2022 15:04:09 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/12/2022 2:45 PM, Mr Flibble wrote:
>>>>> On Sun, 12 Jun 2022 14:17:08 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/12/2022 12:28 PM, Mr Flibble wrote:
>>>>>>> On Sun, 12 Jun 2022 13:26:18 -0400
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 6/12/22 10:53 AM, olcott wrote:
>>>>>>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 6/11/22 11:52 PM, olcott wrote:
>>>>>>>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>>>>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -0500 olcott <NoOne@NoWhere.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> facts prove that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validation is axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ambiguity or leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interpretation of their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> objectively incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001317](02)  8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>       jmp 00001319
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131b](01) 5d pop ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c](01) c3
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ret Size in bytes:(0007)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the above function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop if the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point are you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> detecting infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> software engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could be doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> set more than once.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> acknowledge that you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what a correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nothing but smoke and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can easily determine the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop from the following
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this proves your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 55 push ebp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec mov
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp,esp [00001345][00212333][00212337]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebfe jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Detected Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more about your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fact that every competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the trivial algorithm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>> RAM size) different ways
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected
>>>>>>>>>>>>>>>>>>>>>>>>>>>> however you are not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general*
>>>>>>>>>>>>>>>>>>>>>>>>>>>> case.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can
>>>>>>>>>>>>>>>>>>>>>>>>>>> be easily detected
>>>>>>>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any
>>>>>>>>>>>>>>>>>>>>>>>>>>> kind of infinite loop at
>>>>>>>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs
>>>>>>>>>>>>>>>>>>>>>>>>>>> to correctly detect one
>>>>>>>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation. I threw in some
>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion
>>>>>>>>>>>>>>>>>>>>>>>>>>> just to make my code a
>>>>>>>>>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project
>>>>>>>>>>>>>>>>>>>>>>>>> (my project thus I am the
>>>>>>>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one
>>>>>>>>>>>>>>>>>>>>>>>>> instance of an H and P having
>>>>>>>>>>>>>>>>>>>>>>>>> the following relationship is correctly
>>>>>>>>>>>>>>>>>>>>>>>>> decided as non-halting.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>        For any program H that might
>>>>>>>>>>>>>>>>>>>>>>>>> determine if programs halt, a
>>>>>>>>>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>>>>>>>>>        program P, called with some input,
>>>>>>>>>>>>>>>>>>>>>>>>> can pass its own source and
>>>>>>>>>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>>>>>>>>>        H and then specifically do the
>>>>>>>>>>>>>>>>>>>>>>>>> opposite of what H predicts P
>>>>>>>>>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>>>>>>>>>        can exist that handles this case.
>>>>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
>>>>>>>>>>>>>>>>>>>>>>>> halted so your H is not
>>>>>>>>>>>>>>>>>>>>>>>> a program "that might determine if programs
>>>>>>>>>>>>>>>>>>>>>>>> halt" according to what
>>>>>>>>>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct
>>>>>>>>>>>>>>>>>>>>>>> and complete x86 emulation of the input to
>>>>>>>>>>>>>>>>>>>>>>> H(P,P) would never stop running.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
>>>>>>>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of
>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) that halts when H(P,,P)
>>>>>>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>>>>> The simulated P never ever reaches its final
>>>>>>>>>>>>>>>>>>>>> state. You already admitted this thus proving
>>>>>>>>>>>>>>>>>>>>> that you are lying now.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input,
>>>>>>>>>>>>>>>>>>>> then THAT P, when properly simulated will reach its
>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The you believe a terminated process continues to
>>>>>>>>>>>>>>>>>>> execute after it has been terminated is nuts. No one
>>>>>>>>>>>>>>>>>>> here believes that a terminated process keeps
>>>>>>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>>>>>>>>>> partially simulated machine and not the machine
>>>>>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When the behavior of the complete and correct x86
>>>>>>>>>>>>>>>>> emulation of an input is correctly predicted to never
>>>>>>>>>>>>>>>>> stop running then H(P,P)==0 is necessarily correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it
>>>>>>>>>>>>>>>> is still wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With my latest update H correctly predicts that its
>>>>>>>>>>>>>>> complete x86 emulation of P would never stop running
>>>>>>>>>>>>>>> before the second emulation even begins.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Saying it doesn't make it true.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This proves that it is true.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>    return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _P()
>>>>>>>>>>>>> [00001352](01)  55              push ebp
>>>>>>>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>>>>>>>> [0000136c](01)  c3              ret
>>>>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>> emulates its input that it must emulate the first seven
>>>>>>>>>>>>> instructions of P. Because the seventh instruction of P
>>>>>>>>>>>>> repeats this process we can know with complete certainty
>>>>>>>>>>>>> that the emulated P never reaches its final “ret”
>>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>
>>>>>>>>>>> The above is a sufficient summation of the algorithm to
>>>>>>>>>>> evaluate the correctness of H(P,P)==0. H uses an x86
>>>>>>>>>>> emulator to simulate its input.
>>>>>>>>>>
>>>>>>>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except that the correct emulation needs to emulate that
>>>>>>>>>>>> emulation, not just start it again.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The updated version correctly aborts its x86 emulation of P
>>>>>>>>>>> as soon as P calls H(P,P), thus there are zero nested
>>>>>>>>>>> emulations.
>>>>>>>>>>
>>>>>>>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
>>>>>>>>>> non-halting.
>>>>>>>>>>
>>>>>>>>>> What PROOF do you have that it is correct? It is just another
>>>>>>>>>> of your FALSE presumptions.
>>>>>>>>>>
>>>>>>>>>> You can prove all sorts of stuff if you are allowed false
>>>>>>>>>> premises.
>>>>>>>>>>>
>>>>>>>>>>> To provide context for other reviewers I created the x86utm
>>>>>>>>>>> operating system so that I could show a simulating halt
>>>>>>>>>>> decider halt decider C function that correctly decides the
>>>>>>>>>>> halt status of another C function P where H and P have the
>>>>>>>>>>> halting problem relationship as shown in the next paragraph.
>>>>>>>>>>>
>>>>>>>>>>>       For any program H that might determine if programs
>>>>>>>>>>> halt, a "pathological"
>>>>>>>>>>>       program P, called with some input, can pass its own
>>>>>>>>>>> source and its input to
>>>>>>>>>>>       H and then specifically do the opposite of what H
>>>>>>>>>>> predicts P will do. No H
>>>>>>>>>>>       can exist that handles this case.
>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>
>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That something is beyond your intellectual capacity is zero
>>>>>>>>> evidence what-so-ever that it is false. Only competent
>>>>>>>>> software engineers can validate my claim.
>>>>>>>>
>>>>>>>> What, do you deny that when P(P) calls H(P,P) and it returns
>>>>>>>> the 0 to it that P hatis? If so, then you have lied that you
>>>>>>>> built P correctly.
>>>>>>>>
>>>>>>>> IF H(P,P) doesn't return the 0, then you have lied about what H
>>>>>>>> does, or that it is actually the needed computation.
>>>>>>>>
>>>>>>>> The ONLY case where P(P) calling H(P,P) is actually non-halting
>>>>>>>> is the case where H(P,P) never aborts its simulation, EVER, and
>>>>>>>> such an H can't return 0 for H(P,P), so you lie that H is
>>>>>>>> correct returning a value it never returns.
>>>>>>>>
>>>>>>>> Which LIE will you admit to? Or are there more than one of
>>>>>>>> them?
>>>>>>>>
>>>>>>>> FAIL.
>>>>>>>
>>>>>>> I agree Olcott is a liar: he keeps repeating the lie that I
>>>>>>> don't know what unreachable code is.
>>>>>> I saved a copy of this in case it ever comes up again.
>>>>>>
>>>>>> Below proves that you do not know that every instruction after
>>>>>> [0000135d] is unreachable when you suggest that modifying the
>>>>>> opcode at unreachable address 00001369 would change the
>>>>>> behavior.
>>>>>
>>>>> That isn't proof that I don't know what unreachable code is (as I
>>>>> do);
>>>>
>>>> It is proof that you are unable to correctly assess one instance of
>>>> unreachable code thus do not understand the concept of unreachable
>>>> code sufficiently well.
>>>
>>> No, I fully understand what unreachable code is, the problem is your
>>> inability to comprehend English, to follow a simple argument and not
>>> to pathologically lie when you have exhausted all other avenues of
>>> reasonable (or in your case unreasonable) debate.
>>>
>>
>> It is a very common dishonest tactic to change the subject for the
>> purpose of fake rebuttal.
>>
>> Do you now understand that every address after [0000135d] is
>> unreachable by the correctly emulated input to H(P,P)?
>>
>> (You did not understand this previously)
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> It is completely obvious that when H(P,P) correctly emulates its
>> input that it must emulate the first seven instructions of P. Because
>> the seventh instruction of P repeats this process we can know with
>> complete certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>
> I did understand it previously; I understood that your H when called
> from P never returns a value to P so:
>
> a) the goto statement is never reached;


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<lNwpK.161106$JVi.141815@fx17.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21976&group=comp.lang.c#21976

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx17.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 486
Message-ID: <lNwpK.161106$JVi.141815@fx17.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, 12 Jun 2022 21:54:25 -0400
X-Received-Bytes: 25944
 by: Richard Damon - Mon, 13 Jun 2022 01:54 UTC

On 6/12/22 4:04 PM, olcott wrote:
> On 6/12/2022 2:45 PM, Mr Flibble wrote:
>> On Sun, 12 Jun 2022 14:17:08 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/12/2022 12:28 PM, Mr Flibble wrote:
>>>> On Sun, 12 Jun 2022 13:26:18 -0400
>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>> On 6/12/22 10:53 AM, olcott wrote:
>>>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 6/11/22 11:52 PM, olcott wrote:
>>>>>>>> On 6/11/2022 7:43 PM, Richard Damon wrote:
>>>>>>>>> On 6/11/22 8:03 PM, olcott wrote:
>>>>>>>>>> On 6/11/2022 6:39 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/11/22 7:19 PM, olcott wrote:
>>>>>>>>>>>> On 6/11/2022 6:12 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/11/22 6:13 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/11/2022 5:02 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/11/22 5:55 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 6/11/2022 4:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 6/11/22 3:48 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 6/11/2022 2:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 6/11/22 3:25 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 6/11/2022 2:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 14:04:32 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:58 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 2:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:47 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:28:24 -0500
>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:23 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:21:25 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:16:17 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 1:11 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 13:01:28 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:53 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:39:14 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 12:28 PM, Mr Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, 11 Jun 2022 12:06:44 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/2022 11:07 AM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 6/11/22 10:04 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue is that verified facts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prove that I am
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct yet my reviewers
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistently disagree with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verified facts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I need honest and competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer here to verify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the software engineering of my
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> claims. My prior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers are either dishonest or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetent.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, you need to honest with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Verified" normally means by an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> independent source,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not yourself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When dealing with objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> verifiable facts and not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subjective judgement calls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validation is axiomatic.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The x86 language is a formal
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematical language in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the semantics specified by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> programs written in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this language have zero ambiguity or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leeway for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different subjective interpretation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of their meaning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When I say that this specifies and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop anyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that disagrees simply objectively
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001316](01)  55              push
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ebp [00001317](02)  8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mov ebp,esp [00001319](02)  ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>         jmp 00001319 [0000131b](01)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5d pop ebp [0000131c](01)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> c3              ret Size in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes:(0007) [0000131c]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All recent rebuttals of my work have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> taken the form of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreeing with the x86 language.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But you assert the infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> unreachable in P so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what is the point of posting its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disassembly here?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Did you notice that the name of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> above function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not P?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Why post the trace of an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if the infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop in P isn't reachable? What point
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are you trying to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The point that I just made is that when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone disagrees
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the x86 language then they are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The concrete example above shown an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop thus
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anyone that disagrees that it is an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have already refused
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to divulge your algorithm for detecting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loops;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The algorithm for detecting the above
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self-evident to all competent software
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> engineers.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It isn't self-evident at all. You could
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be doing naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern matching looking for the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opcodes "EB FE" or you could be doing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> something less naive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> such as detecting the same machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (CPU/RAM) state when the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same instruction pointer register is set
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more than once.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you expressly acknowledge
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> woefully incompetent to determine what a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loop detector would do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The mask is slipping. You've got nothing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but smoke and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mirrors.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer here can
>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily determine the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> algorithm for recognizing an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the following
>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern. That you cannot do this
>>>>>>>>>>>>>>>>>>>>>>>>>>>> proves your
>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompetence.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored
>>>>>>>>>>>>>>>>>>>>>>>>>>>> at:212343 [00001342][00212333][00212337] 55
>>>>>>>>>>>>>>>>>>>>>>>>>>>> push ebp [00001343][00212333][00212337] 8bec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>        mov ebp,esp
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe
>>>>>>>>>>>>>>>>>>>>>>>>>>>> jmp 00001345
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Simulation Stopped
>>>>>>>>>>>>>>>>>>>>>>>>>>> Your vacuous meaningless insults reveal more
>>>>>>>>>>>>>>>>>>>>>>>>>>> about your
>>>>>>>>>>>>>>>>>>>>>>>>>>> character than anything else.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> It is an easily objectively verifiable fact
>>>>>>>>>>>>>>>>>>>>>>>>>> that every competent
>>>>>>>>>>>>>>>>>>>>>>>>>> software engineer can correctly determine the
>>>>>>>>>>>>>>>>>>>>>>>>>> trivial algorithm
>>>>>>>>>>>>>>>>>>>>>>>>>> required to recognize the above infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> There are 2^n (n proportional to machine RAM
>>>>>>>>>>>>>>>>>>>>>>>>> size) different ways
>>>>>>>>>>>>>>>>>>>>>>>>> of expressing an infinite loop; the above
>>>>>>>>>>>>>>>>>>>>>>>>> infinite loop is the
>>>>>>>>>>>>>>>>>>>>>>>>> most trivial case and is easily detected
>>>>>>>>>>>>>>>>>>>>>>>>> however you are not
>>>>>>>>>>>>>>>>>>>>>>>>> telling us how you detect the *general* case.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If you know that the above infinite loop can be
>>>>>>>>>>>>>>>>>>>>>>>> easily detected
>>>>>>>>>>>>>>>>>>>>>>>> then everything else is out-of-scope. Any kind
>>>>>>>>>>>>>>>>>>>>>>>> of infinite loop at
>>>>>>>>>>>>>>>>>>>>>>>> all is actually out-of-scope, H only needs to
>>>>>>>>>>>>>>>>>>>>>>>> correctly detect one
>>>>>>>>>>>>>>>>>>>>>>>> specific case of infinitely nested simulation. I
>>>>>>>>>>>>>>>>>>>>>>>> threw in some
>>>>>>>>>>>>>>>>>>>>>>>> infinite loops and some infinite recursion just
>>>>>>>>>>>>>>>>>>>>>>>> to make my code a
>>>>>>>>>>>>>>>>>>>>>>>> little more robust.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> YOU don't get to define scope.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sure I do, the scope of my research project (my
>>>>>>>>>>>>>>>>>>>>>> project thus I am the
>>>>>>>>>>>>>>>>>>>>>> king of its scope) is to show that one instance of
>>>>>>>>>>>>>>>>>>>>>> an H and P having
>>>>>>>>>>>>>>>>>>>>>> the following relationship is correctly decided as
>>>>>>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>          For any program H that might determine if
>>>>>>>>>>>>>>>>>>>>>> programs halt, a
>>>>>>>>>>>>>>>>>>>>>> "pathological"
>>>>>>>>>>>>>>>>>>>>>>          program P, called with some input, can
>>>>>>>>>>>>>>>>>>>>>> pass its own source and
>>>>>>>>>>>>>>>>>>>>>> its input to
>>>>>>>>>>>>>>>>>>>>>>          H and then specifically do the opposite of
>>>>>>>>>>>>>>>>>>>>>> what H predicts P
>>>>>>>>>>>>>>>>>>>>>> will do. No H
>>>>>>>>>>>>>>>>>>>>>>          can exist that handles this case.
>>>>>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Your H returns the wrong answer if P would have
>>>>>>>>>>>>>>>>>>>>> halted so your H is not
>>>>>>>>>>>>>>>>>>>>> a program "that might determine if programs halt"
>>>>>>>>>>>>>>>>>>>>> according to what
>>>>>>>>>>>>>>>>>>>>> is in scope of your "research project".
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct and
>>>>>>>>>>>>>>>>>>>> complete x86 emulation of the input to H(P,P) would
>>>>>>>>>>>>>>>>>>>> never stop running.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope, it has been shown to you, and you have even
>>>>>>>>>>>>>>>>>>> posted yourself, the trace of the simulation of the
>>>>>>>>>>>>>>>>>>> input to H(P,P) that halts when H(P,,P) returns 0.
>>>>>>>>>>>>>>>>>> The simulated P never ever reaches its final state.
>>>>>>>>>>>>>>>>>> You already admitted this thus proving that you are
>>>>>>>>>>>>>>>>>> lying now.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Your missing words.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The simulation BY H, can't reach the final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If H aborts its simulation, and rejects the input, then
>>>>>>>>>>>>>>>>> THAT P, when properly simulated will reach its final
>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The you believe a terminated process continues to
>>>>>>>>>>>>>>>> execute after it has been terminated is nuts. No one
>>>>>>>>>>>>>>>> here believes that a terminated process keeps running.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And you seem to be mistaken that Halting is about the
>>>>>>>>>>>>>>> partially simulated machine and not the machine itself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When the behavior of the complete and correct x86
>>>>>>>>>>>>>> emulation of an input is correctly predicted to never
>>>>>>>>>>>>>> stop running then H(P,P)==0 is necessarily correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, and if H does that, it never returns that 0, so it is
>>>>>>>>>>>>> still wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> With my latest update H correctly predicts that its complete
>>>>>>>>>>>> x86 emulation of P would never stop running before the
>>>>>>>>>>>> second emulation even begins.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Saying it doesn't make it true.
>>>>>>>>>>
>>>>>>>>>> This proves that it is true.
>>>>>>>>>>
>>>>>>>>>> void P(u32 x)
>>>>>>>>>> {
>>>>>>>>>>      if (H(x, x))
>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>      return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>      Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [00001352](01)  55              push ebp
>>>>>>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>>>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>> [00001358](01)  50              push eax      // push P
>>>>>>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>> [0000135c](01)  51              push ecx      // push P
>>>>>>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>>>>>>> [00001362](03)  83c408          add esp,+08
>>>>>>>>>> [00001365](02)  85c0            test eax,eax
>>>>>>>>>> [00001367](02)  7402            jz 0000136b
>>>>>>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>>>>>>> [0000136b](01)  5d              pop ebp
>>>>>>>>>> [0000136c](01)  c3              ret
>>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>>>
>>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>>>>> its input that it must emulate the first seven instructions of
>>>>>>>>>> P. Because the seventh instruction of P repeats this process
>>>>>>>>>> we can know with complete certainty that the emulated P never
>>>>>>>>>> reaches its final “ret” instruction, thus never halts.
>>>>>>>>
>>>>>>>> The above is a sufficient summation of the algorithm to evaluate
>>>>>>>> the correctness of H(P,P)==0. H uses an x86 emulator to simulate
>>>>>>>> its input.
>>>>>>>
>>>>>>> HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that the correct emulation needs to emulate that
>>>>>>>>> emulation, not just start it again.
>>>>>>>>
>>>>>>>> The updated version correctly aborts its x86 emulation of P as
>>>>>>>> soon as P calls H(P,P), thus there are zero nested emulations.
>>>>>>>
>>>>>>> BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of
>>>>>>> non-halting.
>>>>>>>
>>>>>>> What PROOF do you have that it is correct? It is just another of
>>>>>>> your FALSE presumptions.
>>>>>>>
>>>>>>> You can prove all sorts of stuff if you are allowed false
>>>>>>> premises.
>>>>>>>>
>>>>>>>> To provide context for other reviewers I created the x86utm
>>>>>>>> operating system so that I could show a simulating halt decider
>>>>>>>> halt decider C function that correctly decides the halt status
>>>>>>>> of another C function P where H and P have the halting problem
>>>>>>>> relationship as shown in the next paragraph.
>>>>>>>>
>>>>>>>>         For any program H that might determine if programs halt,
>>>>>>>> a "pathological"
>>>>>>>>         program P, called with some input, can pass its own
>>>>>>>> source and its input to
>>>>>>>>         H and then specifically do the opposite of what H
>>>>>>>> predicts P will do. No H
>>>>>>>>         can exist that handles this case.
>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>
>>>>>>>>
>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>> (V5)
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>>>
>>>>>> That something is beyond your intellectual capacity is zero
>>>>>> evidence what-so-ever that it is false. Only competent software
>>>>>> engineers can validate my claim.
>>>>>
>>>>> What, do you deny that when P(P) calls H(P,P) and it returns the 0
>>>>> to it that P hatis? If so, then you have lied that you built P
>>>>> correctly.
>>>>>
>>>>> IF H(P,P) doesn't return the 0, then you have lied about what H
>>>>> does, or that it is actually the needed computation.
>>>>>
>>>>> The ONLY case where P(P) calling H(P,P) is actually non-halting is
>>>>> the case where H(P,P) never aborts its simulation, EVER, and such
>>>>> an H can't return 0 for H(P,P), so you lie that H is correct
>>>>> returning a value it never returns.
>>>>>
>>>>> Which LIE will you admit to? Or are there more than one of them?
>>>>>
>>>>> FAIL.
>>>>
>>>> I agree Olcott is a liar: he keeps repeating the lie that I don't
>>>> know what unreachable code is.
>>> I saved a copy of this in case it ever comes up again.
>>>
>>> Below proves that you do not know that every instruction after
>>> [0000135d] is unreachable when you suggest that modifying the opcode
>>> at unreachable address 00001369 would change the behavior.
>>
>> That isn't proof that I don't know what unreachable code is (as I do);
>
> It is proof that you are unable to correctly assess one instance of
> unreachable code thus do not understand the concept of unreachable code
> sufficiently well.


Click here to read the complete article
Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<VzxpK.12914$CBlb.9025@fx42.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21978&group=comp.lang.c#21978

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Followup: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx42.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<20220612175516.000007e1@reddwarf.jmc>
<TJidncDGmaeShjv_nZ2dnUU7_81g4p2d@giganews.com>
<6sppK.16491$gjlb.9044@fx44.iad>
<y8SdnWcbvoftszv_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
Followup-To: comp.theory
In-Reply-To: <y8SdnWcbvoftszv_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 82
Message-ID: <VzxpK.12914$CBlb.9025@fx42.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, 12 Jun 2022 22:48:18 -0400
X-Received-Bytes: 5195
 by: Richard Damon - Mon, 13 Jun 2022 02:48 UTC

On 6/12/22 2:20 PM, olcott wrote:
> On 6/12/2022 12:33 PM, Richard Damon wrote:
>>
>> On 6/12/22 12:57 PM, olcott wrote:
>>> On 6/12/2022 11:55 AM, Mr Flibble wrote:
>>>> On Sun, 12 Jun 2022 09:53:25 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>>
>>>>>>
>>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>>
>>>>> That something is beyond your intellectual capacity is zero evidence
>>>>> what-so-ever that it is false. Only competent software engineers can
>>>>> validate my claim.
>>>>
>>>> Everybody else is stupid and you are correct. Mate, you are a tool.
>>>>
>>>> /Flibble
>>>>
>>>
>>> Only you and Richard.
>>>
>>
>> So, everyone else who says you are wrong is right, and you admit to
>> being actually wrong?
>
> Everyone else is sufficiently competent to explain their reasoning and
> not directly contradict verifiable facts except for this one issue:
>
> A halt decider must compute the mapping from its input finite strings to
> an accept or reject state based on the actual behavior that is actually
> specified by this input.

Which IS the behavior of P(P) unless your H isn't a Halt decider or P
wasn't built to the instructions.

Remember, P is given a representation of itself, and is to ask H to
decide on the machine that its was given a representation of (that would
be P) when applied to the description it was given, that would result in
P(P).

If this can't be given to H, then H just fails to be the needed decider,
since this is a valid input to ask H, if this isn't the right way to ask
it, then P was designed wrong.

>
> The problem where is that although I have proved that the correct and
> complete x86 emulation of the inputs to H(P,P) would never stop running
> they still believe that H should report that its input halts on the
> basis of an entirely different sequence of instructions specified by the
> execution of P(P).
>

No, you haven't. You have only proved that when H actually does the
complete and correct emulation itself, that this happens, but then H
never stops its emulation, and thus can never give the answer to the
call in main.

If you change H to abort and then return the answer, you now have a
different H, and since H is part of P, a different P, so you previous
analysis is not valid. The fact that you claim they are the same string
of bytes, just shows the flaw in your design. You string doesn't
actually define the behavior of the program.

When we look at the behavior of the P based on the H that does abort,
and thus doesn't do a complete and correct emulation of its input, when
we do that complete and correct emulation of the input (without changing
the H that the P uses) we see that P(P) Halts as it calls H(P,P) which
emulates for awhile, then aborts its emualtion and returns the answer to
the P that called it which halts.

I have explained this to you MANY times, and you still don't understand
it. You are either a pathological liar or have a mental deficiency.

Note, you have NEVER showed an actual error in this, only claimes of
impossibvle behaviors that you have yet to show how they can happen, so
are just more lies until they can be proven.

YOU FAIL.

Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<VFxpK.62214$Rvub.58416@fx35.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21979&group=comp.lang.c#21979

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Followup: 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.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c,comp.lang.c++
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<rB5pK.91631$wIO9.36299@fx12.iad>
<UsydnRCy4dbcejn_nZ2dnUU7_83NnZ2d@giganews.com>
<20220611202313.0000122e@reddwarf.jmc>
<UeidnfdI7rLbcTn_nZ2dnUU7_8xh4p2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<20220612175516.000007e1@reddwarf.jmc>
<TJidncDGmaeShjv_nZ2dnUU7_81g4p2d@giganews.com>
<6sppK.16491$gjlb.9044@fx44.iad>
<y8SdnWEbvodosjv_nZ2dnUU7_8xh4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
Followup-To: comp.theory
In-Reply-To: <y8SdnWEbvodosjv_nZ2dnUU7_8xh4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 61
Message-ID: <VFxpK.62214$Rvub.58416@fx35.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 12 Jun 2022 22:54:45 -0400
X-Received-Bytes: 4119
 by: Richard Damon - Mon, 13 Jun 2022 02:54 UTC

On 6/12/22 2:27 PM, olcott wrote:
> On 6/12/2022 12:33 PM, Richard Damon wrote:
>>
>> On 6/12/22 12:57 PM, olcott wrote:
>>> On 6/12/2022 11:55 AM, Mr Flibble wrote:
>>>> On Sun, 12 Jun 2022 09:53:25 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>>
>>>>>>
>>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>>
>>>>> That something is beyond your intellectual capacity is zero evidence
>>>>> what-so-ever that it is false. Only competent software engineers can
>>>>> validate my claim.
>>>>
>>>> Everybody else is stupid and you are correct. Mate, you are a tool.
>>>>
>>>> /Flibble
>>>>
>>>
>>> Only you and Richard.
>>>
>>
>> So, everyone else who says you are wrong is right, and you admit to
>> being actually wrong?
>>
>> You can't stand what I say, because I apparently can detect the core
>> flaws in your arguments and directly challenge them.
>>
>> Your whole strategy is based on flawed logic, in part because you just
>> won't admit that there IS a core logic you need to follow.
>>
>
> This is the core logic:
>
> The criterion measure for a simulating halt decider (SHD)
> When the correct partial x86 emulation of the input matches a
> non-halting behavior pattern such that it correctly determines that a
> complete emulation of the input would never stop running, or reach its
> “ret” instruction then the SHD aborts its emulation and correctly
> returns 0.
>
Except that this can't happen in the emulation of P(P), since any
pattern that the SHD might detect in this emulation that it decides is a
correct non-halting pattern, if it does abort its simulation and returns
0, then the actual correct and complete emulation of this input will
emulate that call to H(,P) which will emulate its input until it sees
the pattern, stop its emulation and return to its calling P which will
then halt, showing that the pattern was not actually correct.

This is a common fault with many of your arguments, you don't know how
to test if something actually exists.

>
>> This is because your basic idea about what is Truth is flawed an
>> inconsistent, but you just can't hear that.
>
>

Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<87leu1royc.fsf@nosuchdomain.example.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21980&group=comp.lang.c#21980

  copy link   Newsgroups: comp.lang.c comp.lang.c++
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith.S....@gmail.com (Keith Thompson)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)
Followup-To: comp.theory
Date: Mon, 13 Jun 2022 00:40:27 -0700
Organization: None to speak of
Lines: 12
Message-ID: <87leu1royc.fsf@nosuchdomain.example.com>
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad>
<20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
<lNwpK.161106$JVi.141815@fx17.iad>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="b77db74be8eb5809cf46d8636a40ad70";
logging-data="3089"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+EMGHaV7b5HmIw5QWp+cWW"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:WKnfRKJ+5PpLv/Ue+brkYJt9AKk=
sha1:hDcJP34/pba5Na9jhpU3/uzjwiU=
 by: Keith Thompson - Mon, 13 Jun 2022 07:40 UTC

Richard Damon <Richard@Damon-Family.org> writes:
> On 6/12/22 4:04 PM, olcott wrote:
[479 lines deleted]

Richard, olcott has already taken over comp.theory. Please don't
help him take over comp.lang.c and comp.lang.c++. Please remove
them from the Newsgroups: header line when you post a followup.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Re: Proving that P(P) != the correct x86 emulation of the input to H(P,P)

<MoydnThSWoFyzDr_nZ2dnUU7_8xh4p2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21981&group=comp.lang.c#21981

  copy link   Newsgroups: 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 13 Jun 2022 10:04:15 -0500
Date: Mon, 13 Jun 2022 10:04:15 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: Proving that P(P) != the correct x86 emulation of the input to
H(P,P)
Content-Language: en-US
Newsgroups: comp.lang.c
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
<lNwpK.161106$JVi.141815@fx17.iad> <87leu1royc.fsf@nosuchdomain.example.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87leu1royc.fsf@nosuchdomain.example.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <MoydnThSWoFyzDr_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 133
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-P010of9BqfhpPrhXjwH5VgZJ4VPFOS4/sB2qVrdSiQjfMa8T3fF0nrjxohVb7oAR4A6qa4EYPqQDwOG!sNerVcpALMrVwhBE4B9vMW15WTV9W3MWs20R/Gi0cv4yKWDAIoDF1DdN3QbDwdEIjkEKJNDJDOuC
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: 7888
 by: olcott - Mon, 13 Jun 2022 15:04 UTC

On 6/13/2022 2:40 AM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 6/12/22 4:04 PM, olcott wrote:
> [479 lines deleted]
>
> Richard, olcott has already taken over comp.theory. Please don't
> help him take over comp.lang.c and comp.lang.c++. Please remove
> them from the Newsgroups: header line when you post a followup.
>

If the people in comp.theory were not so incompetent at software
engineering I would not be here. As soon as the software engineering
aspects of H(P,P)==0 are fully addressed I will have no need to be here.

The people in comp.theory are so utterly incompetent at software
engineering that many dozens of them could never begin to understand
this simple execution trace. I have spent a year talking to dozens of
people about this and none of them can do the simple software
engineering correctly.

Richard was so woefully incompetent that he still keeps saying that when
H(P,P) aborts the x86 emulation of its input and returns 0 that this
aborted input continues to execute until it reaches its "ret" instruction.

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

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

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

// H emulates the first seven instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000000] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(15892) = 237 pages

The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete emulation of the input would never stop running, or reach its
“ret” instruction then the SHD aborts its emulation and correctly
returns 0.

--
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: the correct x86 emulation of the input to H(P,P)==0

<_ridnVHF34I4yTr_nZ2dnUU7_8zNnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21982&group=comp.lang.c#21982

  copy link   Newsgroups: 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: Mon, 13 Jun 2022 10:15:49 -0500
Date: Mon, 13 Jun 2022 10:15:49 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: the correct x86 emulation of the input to H(P,P)==0
Content-Language: en-US
Newsgroups: comp.lang.c++,comp.lang.c
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<1d6pK.18052$cq8.3526@fx03.iad>
<Ms-dnQIp9vgCbDn_nZ2dnUU7_81g4p2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
<lNwpK.161106$JVi.141815@fx17.iad> <87leu1royc.fsf@nosuchdomain.example.com>
<d_Odndun-e9g1jr_nZ2dnUU7_8zNnZ2d@giganews.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <d_Odndun-e9g1jr_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <_ridnVHF34I4yTr_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 141
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-HCyeUfddhcExdPuJn5sSHt05U5/L1utxrFuyRDV6V22fLnJcIUywErI07uhxb+07nUsNJdWchQOcaVx!8yfuVjOtiifeH7MgsfgwohuUCm7/QtYwMxBZuzpZVnJo2jmD3xJ5MRjw0LAJcIaVutdb3GWs2f0m
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: 8921
 by: olcott - Mon, 13 Jun 2022 15:15 UTC

On 6/13/2022 9:38 AM, olcott wrote:
> this On 6/13/2022 2:40 AM, Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 6/12/22 4:04 PM, olcott wrote:
>> [479 lines deleted]
>>
>> Richard, olcott has already taken over comp.theory.  Please don't
>> help him take over comp.lang.c and comp.lang.c++.  Please remove
>> them from the Newsgroups: header line when you post a followup.
>>
>
> If the people in comp.theory were not so incompetent at software
> engineering I would not be here. As soon as the software engineering
> aspects of H(P,P)==0 are fully addressed I will have no need to be here.
>
> The people in comp.theory are so utterly incompetent at software
> engineering that many dozens of them could never begin to understand
> this simple execution trace. I have spent a year talking to dozens of
> people about this and none of them can do the simple software
> engineering correctly.
>
> Richard was so woefully incompetent that he still keeps saying that when
> H(P,P) aborts the x86 emulation of its input and returns 0 that this
> aborted input continues to execute until it reaches its "ret" instruction.
>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efeffff      call 000011a2 // call H
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>
> // H emulates the first seven instructions of P
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> // The emulated H emulates the first seven instructions of P
> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>
> ...[00001384][0010229e][00000000] 83c408     add esp,+08
> ...[00001387][0010229a][00000000] 50         push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408     add esp,+08
> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
> ...[00001397][001022a2][00100000] 5d         pop ebp
> ...[00001398][001022a6][00000004] c3         ret
> Number_of_User_Instructions(1)
> Number of Instructions Executed(15892) = 237 pages
>
> The criterion measure for a simulating halt decider (SHD)
> When the correct partial x86 emulation of the input matches a
> non-halting behavior pattern such that it correctly determines that a
> complete emulation of the input would never stop running, or reach its
> “ret” instruction then the SHD aborts its emulation and correctly
> returns 0.

I only need software engineers to confirm that H(P,P)==0 on the basis
that the correctly emulated P meets the above criteria.

Once this is done I will have no need for feedback from
comp.lang.c++ or comp.lang.c

--
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: the correct x86 emulation of the input to H(P,P)==0

<20220613171223.000065a9@reddwarf.jmc>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21983&group=comp.lang.c#21983

  copy link   Newsgroups: comp.lang.c++ comp.lang.c
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!npeer.as286.net!npeer-ng0.as286.net!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx09.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: the correct x86 emulation of the input to H(P,P)==0
Message-ID: <20220613171223.000065a9@reddwarf.jmc>
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad>
<20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
<lNwpK.161106$JVi.141815@fx17.iad>
<87leu1royc.fsf@nosuchdomain.example.com>
<d_Odndun-e9g1jr_nZ2dnUU7_8zNnZ2d@giganews.com>
<_ridnVHF34I4yTr_nZ2dnUU7_8zNnZ2d@giganews.com>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 199
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Mon, 13 Jun 2022 16:12:23 UTC
Date: Mon, 13 Jun 2022 17:12:23 +0100
X-Received-Bytes: 11076
 by: Mr Flibble - Mon, 13 Jun 2022 16:12 UTC

On Mon, 13 Jun 2022 10:15:49 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/13/2022 9:38 AM, olcott wrote:
> > this On 6/13/2022 2:40 AM, Keith Thompson wrote:
> >> Richard Damon <Richard@Damon-Family.org> writes:
> >>> On 6/12/22 4:04 PM, olcott wrote:
> >> [479 lines deleted]
> >>
> >> Richard, olcott has already taken over comp.theory.  Please don't
> >> help him take over comp.lang.c and comp.lang.c++.  Please remove
> >> them from the Newsgroups: header line when you post a followup.
> >>
> >
> > If the people in comp.theory were not so incompetent at software
> > engineering I would not be here. As soon as the software
> > engineering aspects of H(P,P)==0 are fully addressed I will have no
> > need to be here.
> >
> > The people in comp.theory are so utterly incompetent at software
> > engineering that many dozens of them could never begin to
> > understand this simple execution trace. I have spent a year talking
> > to dozens of people about this and none of them can do the simple
> > software engineering correctly.
> >
> > Richard was so woefully incompetent that he still keeps saying that
> > when H(P,P) aborts the x86 emulation of its input and returns 0
> > that this aborted input continues to execute until it reaches its
> > "ret" instruction.
> >
> > #include <stdint.h>
> > #define u32 uint32_t
> >
> > void P(u32 x)
> > {
> >   if (H(x, x))
> >     HERE: goto HERE;
> >   return;
> > }
> >
> > int main()
> > {
> >   Output("Input_Halts = ", H((u32)P, (u32)P));
> > }
> >
> > _P()
> > [00001352](01)  55              push ebp
> > [00001353](02)  8bec            mov ebp,esp
> > [00001355](03)  8b4508          mov eax,[ebp+08]
> > [00001358](01)  50              push eax      // push P
> > [00001359](03)  8b4d08          mov ecx,[ebp+08]
> > [0000135c](01)  51              push ecx      // push P
> > [0000135d](05)  e840feffff      call 000011a2 // call H
> > [00001362](03)  83c408          add esp,+08
> > [00001365](02)  85c0            test eax,eax
> > [00001367](02)  7402            jz 0000136b
> > [00001369](02)  ebfe            jmp 00001369
> > [0000136b](01)  5d              pop ebp
> > [0000136c](01)  c3              ret
> > Size in bytes:(0027) [0000136c]
> >
> > _main()
> > [00001372](01)  55              push ebp
> > [00001373](02)  8bec            mov ebp,esp
> > [00001375](05)  6852130000      push 00001352 // push P
> > [0000137a](05)  6852130000      push 00001352 // push P
> > [0000137f](05)  e81efeffff      call 000011a2 // call H
> > [00001384](03)  83c408          add esp,+08
> > [00001387](01)  50              push eax
> > [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> > [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> > [00001392](03)  83c408          add esp,+08
> > [00001395](02)  33c0            xor eax,eax
> > [00001397](01)  5d              pop ebp
> > [00001398](01)  c3              ret
> > Size in bytes:(0039) [00001398]
> >
> >     machine   stack     stack     machine    assembly
> >     address   address   data      code       language
> >     ========  ========  ========  =========  ============> > ...[00001372][0010229e][00000000] 55         push ebp
> > ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> > ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> > ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> > ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
> >
> > Begin Local Halt Decider Simulation   Execution Trace Stored
> > at:212352
> >
> > // H emulates the first seven instructions of P
> > ...[00001352][0021233e][00212342] 55         push ebp      // enter
> > P ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> > ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> > ...[00001358][0021233a][00001352] 50         push eax      // push P
> > ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> > ...[0000135c][00212336][00001352] 51         push ecx      // push P
> > ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
> >
> > // The emulated H emulates the first seven instructions of P
> > ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter
> > P ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> > ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> > ...[00001358][0025cd62][00001352] 50         push eax      // push P
> > ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> > ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> > ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> > Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >
> > It is completely obvious that when H(P,P) correctly emulates its
> > input that it must emulate the first seven instructions of P.
> > Because the seventh instruction of P repeats this process we can
> > know with complete certainty that the emulated P never reaches its
> > final “ret” instruction, thus never halts.
> >
> > ...[00001384][0010229e][00000000] 83c408     add esp,+08
> > ...[00001387][0010229a][00000000] 50         push eax
> > ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> > "Input_Halts = "
> > ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
> > Output Input_Halts = 0
> > ...[00001392][0010229e][00000000] 83c408     add esp,+08
> > ...[00001395][0010229e][00000000] 33c0       xor eax,eax
> > ...[00001397][001022a2][00100000] 5d         pop ebp
> > ...[00001398][001022a6][00000004] c3         ret
> > Number_of_User_Instructions(1)
> > Number of Instructions Executed(15892) = 237 pages
> >
> > The criterion measure for a simulating halt decider (SHD)
> > When the correct partial x86 emulation of the input matches a
> > non-halting behavior pattern such that it correctly determines that
> > a complete emulation of the input would never stop running, or
> > reach its “ret” instruction then the SHD aborts its emulation and
> > correctly returns 0.
>
> I only need software engineers to confirm that H(P,P)==0 on the basis
> that the correctly emulated P meets the above criteria.
>
> Once this is done I will have no need for feedback from
> comp.lang.c++ or comp.lang.c

We can all agree on S(P,P)==0 where S is a simulation detector (not a
halt decider).

/Flibble

Re: the correct x86 emulation of the input to H(P,P)==0

<7N6dndxSA9WT9zr_nZ2dnUU7_81g4p2d@giganews.com>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=21984&group=comp.lang.c#21984

  copy link   Newsgroups: 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 13 Jun 2022 11:47:10 -0500
Date: Mon, 13 Jun 2022 11:47:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.10.0
Subject: Re: the correct x86 emulation of the input to H(P,P)==0
Content-Language: en-US
Newsgroups: comp.lang.c++,comp.lang.c
References: <N8GdnUDJ0IRRxjz_nZ2dnUU7_8zNnZ2d@giganews.com>
<V28pK.155800$JVi.43906@fx17.iad>
<ndqdnf363pWlkjj_nZ2dnUU7_8xh4p2d@giganews.com>
<Oh8pK.26934$vFlb.15179@fx34.iad>
<2_mdnUc4m-8djjj_nZ2dnUU7_8zNnZ2d@giganews.com>
<oj9pK.84572$ntj.72837@fx15.iad>
<t-qdnZ_AJt14vzj_nZ2dnUU7_83NnZ2d@giganews.com>
<XI9pK.68165$X_i.61117@fx18.iad>
<UZ-dnZ4bM8P9sDj_nZ2dnUU7_8zNnZ2d@giganews.com>
<iFapK.68167$X_i.30978@fx18.iad>
<jZ6dnWCIHa9r_zj_nZ2dnUU7_8zNnZ2d@giganews.com>
<LBkpK.14991$_T.13908@fx40.iad>
<It-dndfMeod6YDj_nZ2dnUU7_81g4p2d@giganews.com>
<_kppK.37416$W3d4.20202@fx05.iad> <20220612182842.00006d41@reddwarf.jmc>
<IYudnYjWHJUrpjv_nZ2dnUU7_83NnZ2d@giganews.com>
<20220612204551.00006b65@reddwarf.jmc>
<cM2dnfnIOasm2zv_nZ2dnUU7_83NnZ2d@giganews.com>
<lNwpK.161106$JVi.141815@fx17.iad> <87leu1royc.fsf@nosuchdomain.example.com>
<d_Odndun-e9g1jr_nZ2dnUU7_8zNnZ2d@giganews.com>
<_ridnVHF34I4yTr_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220613171223.000065a9@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220613171223.000065a9@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <7N6dndxSA9WT9zr_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 157
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ETO2LVRrhyloprNHxFk3NBtsBlkeEbv+i1vIw0t4FEyEg1UeaLhbZ1HZ/tW9p60GPbwHzeYhH3x7c2U!Hv7ZV0aBOC2+0on7HB9qkRZkaxrNkIlGxjtYm08jWFVY6GDaZ3ZSTWzQ20nB47v1VUj9HyEsbpmW
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: 9582
 by: olcott - Mon, 13 Jun 2022 16:47 UTC

On 6/13/2022 11:12 AM, Mr Flibble wrote:
> On Mon, 13 Jun 2022 10:15:49 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/13/2022 9:38 AM, olcott wrote:
>>> this On 6/13/2022 2:40 AM, Keith Thompson wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>> On 6/12/22 4:04 PM, olcott wrote:
>>>> [479 lines deleted]
>>>>
>>>> Richard, olcott has already taken over comp.theory.  Please don't
>>>> help him take over comp.lang.c and comp.lang.c++.  Please remove
>>>> them from the Newsgroups: header line when you post a followup.
>>>>
>>>
>>> If the people in comp.theory were not so incompetent at software
>>> engineering I would not be here. As soon as the software
>>> engineering aspects of H(P,P)==0 are fully addressed I will have no
>>> need to be here.
>>>
>>> The people in comp.theory are so utterly incompetent at software
>>> engineering that many dozens of them could never begin to
>>> understand this simple execution trace. I have spent a year talking
>>> to dozens of people about this and none of them can do the simple
>>> software engineering correctly.
>>>
>>> Richard was so woefully incompetent that he still keeps saying that
>>> when H(P,P) aborts the x86 emulation of its input and returns 0
>>> that this aborted input continues to execute until it reaches its
>>> "ret" instruction.
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>>   if (H(x, x))
>>>     HERE: goto HERE;
>>>   return;
>>> }
>>>
>>> int main()
>>> {
>>>   Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> _main()
>>> [00001372](01)  55              push ebp
>>> [00001373](02)  8bec            mov ebp,esp
>>> [00001375](05)  6852130000      push 00001352 // push P
>>> [0000137a](05)  6852130000      push 00001352 // push P
>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>> [00001384](03)  83c408          add esp,+08
>>> [00001387](01)  50              push eax
>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>> [00001392](03)  83c408          add esp,+08
>>> [00001395](02)  33c0            xor eax,eax
>>> [00001397](01)  5d              pop ebp
>>> [00001398](01)  c3              ret
>>> Size in bytes:(0039) [00001398]
>>>
>>>     machine   stack     stack     machine    assembly
>>>     address   address   data      code       language
>>>     ========  ========  ========  =========  =============
>>> ...[00001372][0010229e][00000000] 55         push ebp
>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>> at:212352
>>>
>>> // H emulates the first seven instructions of P
>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter
>>> P ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> // The emulated H emulates the first seven instructions of P
>>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter
>>> P ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> It is completely obvious that when H(P,P) correctly emulates its
>>> input that it must emulate the first seven instructions of P.
>>> Because the seventh instruction of P repeats this process we can
>>> know with complete certainty that the emulated P never reaches its
>>> final “ret” instruction, thus never halts.
>>>
>>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>>> ...[00001387][0010229a][00000000] 50         push eax
>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>>> "Input_Halts ="
>>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
>>> Output Input_Halts = 0
>>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>>> ...[00001397][001022a2][00100000] 5d         pop ebp
>>> ...[00001398][001022a6][00000004] c3         ret
>>> Number_of_User_Instructions(1)
>>> Number of Instructions Executed(15892) = 237 pages
>>>
>>> The criterion measure for a simulating halt decider (SHD)
>>> When the correct partial x86 emulation of the input matches a
>>> non-halting behavior pattern such that it correctly determines that
>>> a complete emulation of the input would never stop running, or
>>> reach its “ret” instruction then the SHD aborts its emulation and
>>> correctly returns 0.
>>
>> I only need software engineers to confirm that H(P,P)==0 on the basis
>> that the correctly emulated P meets the above criteria.
>>
>> Once this is done I will have no need for feedback from
>> comp.lang.c++ or comp.lang.c
>
> We can all agree on S(P,P)==0 where S is a simulation detector (not a
> halt decider).
>
> /Flibble
>

No, Richard still believes that the correctly emulated input to H(P,P)
reaches its "ret" instruction as soon as its emulation has been aborted
and H returns 0.

--
Copyright 2022 Pete Olcott

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

Pages:123
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor