Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

This dungeon is owned and operated by Frobozz Magic Co., Ltd.


devel / comp.theory / Re: Halting problem proofs refuted on the basis of software engineering [thanks Mike]

SubjectAuthor
* Halting problem proofs refuted on the basis of software engineeringolcott
+* Halting problem proofs refuted on the basis of softwareMr Flibble
|`* Halting problem proofs refuted on the basis of softwareolcott
| +* Halting problem proofs refuted on the basis of softwareMr Flibble
| |`* Halting problem proofs refuted on the basis of softwareolcott
| | `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |  `* Halting problem proofs refuted on the basis of softwareolcott
| |   `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |    `* Halting problem proofs refuted on the basis of softwareolcott
| |     `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |      `* Halting problem proofs refuted on the basis of softwareolcott
| |       +* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |`* Halting problem proofs refuted on the basis of softwareolcott
| |       | `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |  `* Halting problem proofs refuted on the basis of softwareolcott
| |       |   +* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |   |`* Halting problem proofs refuted on the basis of softwareolcott
| |       |   | `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |   |  `* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |   `* Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |   |    `* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |     +- Halting problem proofs refuted on the basis of softwareMr Flibble
| |       |   |     `* Halting problem proofs refuted on the basis of software engineeringdklei...@gmail.com
| |       |   |      +* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |      |`- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |      `* Halting problem proofs refuted on the basis of software engineeringdklei...@gmail.com
| |       |   |       +* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |       |+- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |       |`* Halting problem proofs refuted on the basis of software engineeringMikko
| |       |   |       | `* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |       |  +- Halting problem proofs refuted on the basis of software engineeringolcott
| |       |   |       |  `- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |       `* Halting problem proofs refuted on the basis of software engineeringdklei...@gmail.com
| |       |   |        +* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |        |`- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |        `* Halting problem proofs refuted on the basis of software engineeringdklei...@gmail.com
| |       |   |         +* Halting problem proofs refuted on the basis of softwareolcott
| |       |   |         |`- Halting problem proofs refuted on the basis of softwareolcott
| |       |   |         +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |         `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |          +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |          +* _Halting_problem_proofs_refuted_on_the_basis_of_softAndré G. Isaak
| |       |   |          |`* _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |          | `- _Halting_problem_proofs_refuted_on_the_basis_of_softRichard Damon
| |       |   |          +* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |          |`* _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |          | `- _Halting_problem_proofs_refuted_on_the_basis_of_softRichard Damon
| |       |   |          `* Halting problem proofs refuted on the basis of softwareBen Bacarisse
| |       |   |           +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |           +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |           `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |            +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |            `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |             +* _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |             |`* _Halting_problem_proofs_refuted_on_the_basis_of_software_engineering_[_Curry–Howolcott
| |       |   |             | +* _Halting_problem_proofs_refuted_on_the_basis_of_software_engineering_[_Curry–Howolcott
| |       |   |             | |`- _Halting_problem_proofs_refuted_on_the_basis_of_software_engineering_[_Curry–Howolcott
| |       |   |             | `- _Halting_problem_proofs_refuted_on_the_basis_of_softRichard Damon
| |       |   |             `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |              `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |               `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |                `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |                 +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |                 `* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |                  +- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |                  +* _Halting_problem_proofs_refuted_on_the_basis_of_sdklei...@gmail.com
| |       |   |                  |`- _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |                  `* _Halting_problem_proofs_refuted_on_the_basis_of_softolcott
| |       |   |                   +* Halting problem proofs refuted on the basis of software engineering [ Irrefutablolcott
| |       |   |                   |`- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   |                   `* Halting problem proofs refuted on the basis of softwaredklei...@gmail.com
| |       |   |                    `* Halting problem proofs refuted on the basis of software engineering [ Irrefutablolcott
| |       |   |                     `- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       |   `- Halting problem proofs refuted on the basis of softwareRichard Damon
| |       `- Halting problem proofs refuted on the basis of softwareRichard Damon
| `- Halting problem proofs refuted on the basis of softwareRichard Damon
+- Halting problem proofs refuted on the basis of software engineeringolcott
+* Halting problem proofs refuted on the basis of softwareRichard Damon
|`* Halting problem proofs refuted on the basis of softwareolcott
| `- Halting problem proofs refuted on the basis of softwareRichard Damon
+- Halting problem proofs refuted on the basis of softwareHenrietta Stinkbottom
`* Halting problem proofs refuted on the basis of software engineeringwij
 `* Halting problem proofs refuted on the basis of softwareolcott
  +- Halting problem proofs refuted on the basis of softwareRichard Damon
  `* Halting problem proofs refuted on the basis of software engineeringPaul N
   `* Halting problem proofs refuted on the basis of softwareolcott
    `* Halting problem proofs refuted on the basis of software engineeringPaul N
     `* Halting problem proofs refuted on the basis of softwareolcott
      +* Halting problem proofs refuted on the basis of software engineeringwij
      |`* Halting problem proofs refuted on the basis of softwareolcott
      | `* Halting problem proofs refuted on the basis of software engineeringwij
      |  `* Halting problem proofs refuted on the basis of softwareolcott
      |   +- Halting problem proofs refuted on the basis of softwareRichard Damon
      |   `* Halting problem proofs refuted on the basis of software engineeringwij
      |    `* Halting problem proofs refuted on the basis of software engineeringolcott
      |     +* Halting problem proofs refuted on the basis of software engineeringwij
      |     |`* Halting problem proofs refuted on the basis of softwareolcott
      |     | `- Halting problem proofs refuted on the basis of software engineeringwij
      |     `- Halting problem proofs refuted on the basis of softwareRichard Damon
      +- Halting problem proofs refuted on the basis of softwareRichard Damon
      `* Halting problem proofs refuted on the basis of software engineeringPaul N

Pages:12345
Re: Halting problem proofs refuted on the basis of software engineering

<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 15 Jul 2022 09:35:40 -0500
Date: Fri, 15 Jul 2022 09:35:39 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 208
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ynMZyWyPiYfsXLwy61B2EZrk9qhrl2jSuCMFHR9neFq4WEUKqrrJJz69QlyaXJG+wjp9ViFuKF05Ky0!AMcOT0suNHoZmYjxlTra+F2hwycKKE5EnxkFa3ZBDYZlOUlGyTYgEPSuqO/7w55Y3x/yNGxIz3f8!sg==
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: 13599
 by: olcott - Fri, 15 Jul 2022 14:35 UTC

On 7/15/2022 7:34 AM, Paul N wrote:
> On Thursday, July 14, 2022 at 8:56:21 PM UTC+1, olcott wrote:
>> On 7/14/2022 6:42 AM, Paul N wrote:
>>> On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:
>>>> On 7/13/2022 1:03 PM, Paul N wrote:
>>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
>
> I see you have now started a new thread on this very subject in both comp.lang.c and comp.lang.c++. You clearly are very rude.
>
>>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>>>
>>>>>>>> I rewrote this question so that a software engineer of ordinary skill
>>>>>>>> can easily verify that the simulated P does call H in what is
>>>>>>>> essentially infinite recursion. **This simplification is the result of
>>>>>>>> an extensive review (23 emails) by a leading computer scientist over the
>>>>>>>> weekend.**
>>>>>>>
>>>>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
>>>>>>>> pathological input?
>>>>>>>
>>>>>>>> The following H and P have the above specified pathological relationship
>>>>>>>> to each other.
>>>>>>>>
>>>>>>>> typedef void (*ptr)();
>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
>>>>>>>> this basis and rejects this input as non-halting.
>>>>>>>
>>>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>>>
>>>>>>>> *Once this halt deciding principle is accepted*
>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>> specified by these inputs.
>>>>>>>
>>>>>>> Again, emphasis on "actual behaviour".
>>>>>>>
>>>>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>>>>> Every simulating halt decider that correctly simulates its input until
>>>>>>>> it correctly predicts that this simulated input would never terminate
>>>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>>
>>>>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
>>>>>>>
>>>>>>>> *The execution trace of function P() simulated by function H() shows*
>>>>>>>> (1) Function H() is called from P().
>>>>>>>> (2) With the same parameters to H().
>>>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>>>> infinitely recursive simulation.
>>>>>>>
>>>>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
>>>>>>>
>>>>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
>>>>>>>> input would never terminate normally.
>>>>>>>
>>>>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
>>>>>> Welcome back.
>>>>>>
>>>>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>>>>> of the actual behavior specified by this input.
>>>>>
>>>>> No, the actual behaviour is the actual behaviour! If H correctly simulates this behaviour then it too will also be the same, but you have said numerous times that it does not correctly simulate the behaviour.
>>>>>
>>>> It is an easily verified fact that H(P,P) correctly simulates its input
>>>> to everyone having sufficient knowledge of the x86 assembly language
>>>> which currently seems to be hardy no one besides me. Back in the 1986
>>>> when I began my career about 10% of all programmers had familiarity
>>>> with the x86 language. This is the language that MSDOS and versions
>>>> of MS Windows prior to Windows NT were written in. Windows NT switched
>>>> to mostly C/C++.
>>>
>>> No it is not. Firstly, you have never posted the code to H so of course we can't verify it.
>> The latest rewrite of my paper (initially written as a reply to you) can
>> be fully understood at the C level with no need to have any access to
>> the source-code of H. I will publish all the the source-code very soon,
>> yet not until after my work has been validated.
>>
>> The source-code is correct and complete yet must be refactored to clean
>> it up before publication.
>> *Halting problem proofs refuted on the basis of software engineering*
>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>> Furthermore, you yourself claim that the simulation gives different results from the actual code (you even describe this as "provably" on occasion) so you yourself do not believe that H(P,P) correctly simulates its input.
>> This is also much more clearly shown in the rewrite of my paper that I
>> did a few minutes ago. It can now be seen at the C level that the
>> simulation of the input to H(P,P) is correct.
>>
>> It was very easy to see that the simulation of the input to H(P,P) is
>> correct by simply matching the execution trace of the simulated P to its
>> x86 source code. I annotated the x86 source-code to make this much
>> easier for C programmers. I explain line-by-line exactly how the x86
>> code corresponds to its C source.
>>>
>>>> The 23 emails that I had with a leading computer scientist made that
>>>> very clear. Because of this I re-framed my explanation so that any
>>>> expert C programmer that totally understands infinite recursion would be
>>>> able to see that infinitely nested simulation is essentially the same
>>>> thing.
>>>
>>> It might move the conversation on if you showed us what the computer scientist said - most helpfully if you quoted verbatim, but you could paraphrase if you're worried about confidentiality or the like. I take it there was more to it than them saying why you were wrong, and you saying that they didn't understand?
>> This would be disrespecting his privacy. The point is that I now have an
>> excellent measure that I have improved my words so much that my work is
>> not simply rejected out-of-hand without review even by leading computer
>> scientists.
>>>> The next important point that requires one to have top software
>>>> engineering skills that allowed me to transform H into a pure thus
>>>> computable function: Infinitely nested simulation can be detected the
>>>> first time that the simulated input calls the simulator with its same
>>>> arguments. Infinite recursion requires seeing two such calls in a row.
>>>> This change allowed me to discard the need for static local memory and
>>>> do everything in local memory.
>>>>>> A security guard at the front door is only required to validate people
>>>>>> coming in the front door the actual behavior of the actual input to H(P,P).
>>>>>>
>>>>>> This same security guard is not required to validate people coming in
>>>>>> the back door the direct execution of P(P). Unless a computation is
>>>>>> specified as an actual input to H it is not in the domain of the
>>>>>> computable function that H implements.
>>>>>
>>>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
>>>
>>>> No this a very long standing misconception. H is required to determine
>>>> whether or not its correct simulation of its input would ever reach the
>>>> normal termination of this input.
>>>
>>> No, what I have said is right. You are the one bringing in ideas about simulation.
>>>
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>> It is common knowledge that a correct simulation of a program is a
>> correct measure of the behavior of this program.
>>
>> If we accept that the behavior of the executed P(P) is the behavior that
>> H must report on then we are saying that H must report on the behavior
>> that is not the actual behavior of its actual input.
>>>> Since no one ever bothered to think through the application of a
>>>> simulating halt decider to the HP's impossible inputs they always stated
>>>> the requirements incorrectly never realizing their mistake.
>>>
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>
>>> Yes.
>>>
>>>> In the H/P concrete example it is easily proven that the actual behavior
>>>> of the actual input to H(P,P) is not the behavior of the directly
>>>> executed P(P). The best proof of this is the x86 execution trace of each
>>>> that precisely corresponds to what the x86 source code of P specifies.
>>>
>>> You've included the word "actual" twice in that sentence and yet you still seem to think that the actual behaviour is not what really happens. How many "actual"s do you need?
>>>
>>>> From this is is obvious that the correctly simulated P cannot possibly
>>>> terminate normally and the executed P(P) halts.
>>>
>>> If P(P) halts then a correct simulation of it will also halt.
>> In the latest revision to my paper it is much more obvious that that
>> actual behavior of the actual input is not the same as the behavior of
>> the directly executed P(P).
>
> Did your expert in any way agree that the "actual behaviour" is different from the behaviour when P(P) is directly executed? Have you found anyone at all who agrees with you on this point?


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ad4:5c8c:0:b0:473:874c:dd71 with SMTP id o12-20020ad45c8c000000b00473874cdd71mr12683178qvh.3.1657901821252;
Fri, 15 Jul 2022 09:17:01 -0700 (PDT)
X-Received: by 2002:a25:bb42:0:b0:66e:9d65:80f4 with SMTP id
b2-20020a25bb42000000b0066e9d6580f4mr15129847ybk.84.1657901820950; Fri, 15
Jul 2022 09:17:00 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 15 Jul 2022 09:17:00 -0700 (PDT)
In-Reply-To: <Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=89.240.151.96; posting-account=0B-afgoAAABP6274zLUJKa8ZpdIdhsYx
NNTP-Posting-Host: 89.240.151.96
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com> <H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com> <YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com> <A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com> <BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com> <Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
Subject: Re: Halting problem proofs refuted on the basis of software engineering
From: gw7...@aol.com (Paul N)
Injection-Date: Fri, 15 Jul 2022 16:17:01 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 295
 by: Paul N - Fri, 15 Jul 2022 16:17 UTC

On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
> On 7/15/2022 7:34 AM, Paul N wrote:
> > On Thursday, July 14, 2022 at 8:56:21 PM UTC+1, olcott wrote:
> >> On 7/14/2022 6:42 AM, Paul N wrote:
> >>> On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:
> >>>> On 7/13/2022 1:03 PM, Paul N wrote:
> >>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
> >>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
> >>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
> >
> > I see you have now started a new thread on this very subject in both comp.lang.c and comp.lang.c++. You clearly are very rude.
> >
> >>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> >>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
> >>>>>>>>
> >>>>>>>> I rewrote this question so that a software engineer of ordinary skill
> >>>>>>>> can easily verify that the simulated P does call H in what is
> >>>>>>>> essentially infinite recursion. **This simplification is the result of
> >>>>>>>> an extensive review (23 emails) by a leading computer scientist over the
> >>>>>>>> weekend.**
> >>>>>>>
> >>>>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
> >>>>>>>> pathological input?
> >>>>>>>
> >>>>>>>> The following H and P have the above specified pathological relationship
> >>>>>>>> to each other.
> >>>>>>>>
> >>>>>>>> typedef void (*ptr)();
> >>>>>>>> int H(ptr p, ptr i);
> >>>>>>>>
> >>>>>>>> void P(ptr x)
> >>>>>>>> {
> >>>>>>>> if (H(x, x))
> >>>>>>>> HERE: goto HERE;
> >>>>>>>> return;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> int main()
> >>>>>>>> {
> >>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> Simulating halt decider H detects that its simulated input is
> >>>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
> >>>>>>>> this basis and rejects this input as non-halting.
> >>>>>>>
> >>>>>>> Thus it is an incorrect assessment, as we'll see below.
> >>>>>>>
> >>>>>>>> *Once this halt deciding principle is accepted*
> >>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>>>>>> reject state on the basis of the actual behavior that is actually
> >>>>>>>> specified by these inputs.
> >>>>>>>
> >>>>>>> Again, emphasis on "actual behaviour".
> >>>>>>>
> >>>>>>>> *Then (by logical necessity) this is understood to implement that*
> >>>>>>>> Every simulating halt decider that correctly simulates its input until
> >>>>>>>> it correctly predicts that this simulated input would never terminate
> >>>>>>>> normally, correctly rejects this input as non-halting.
> >>>>>>>
> >>>>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
> >>>>>>>
> >>>>>>>> *The execution trace of function P() simulated by function H() shows*
> >>>>>>>> (1) Function H() is called from P().
> >>>>>>>> (2) With the same parameters to H().
> >>>>>>>> (3) With no instructions in P() that could possibly escape this
> >>>>>>>> infinitely recursive simulation.
> >>>>>>>
> >>>>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
> >>>>>>>
> >>>>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
> >>>>>>>> input would never terminate normally.
> >>>>>>>
> >>>>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
> >>>>>> Welcome back.
> >>>>>>
> >>>>>> When H(P,P) correctly simulates its input this is the ultimate measure
> >>>>>> of the actual behavior specified by this input.
> >>>>>
> >>>>> No, the actual behaviour is the actual behaviour! If H correctly simulates this behaviour then it too will also be the same, but you have said numerous times that it does not correctly simulate the behaviour.
> >>>>>
> >>>> It is an easily verified fact that H(P,P) correctly simulates its input
> >>>> to everyone having sufficient knowledge of the x86 assembly language
> >>>> which currently seems to be hardy no one besides me. Back in the 1986
> >>>> when I began my career about 10% of all programmers had familiarity
> >>>> with the x86 language. This is the language that MSDOS and versions
> >>>> of MS Windows prior to Windows NT were written in. Windows NT switched
> >>>> to mostly C/C++.
> >>>
> >>> No it is not. Firstly, you have never posted the code to H so of course we can't verify it.
> >> The latest rewrite of my paper (initially written as a reply to you) can
> >> be fully understood at the C level with no need to have any access to
> >> the source-code of H. I will publish all the the source-code very soon,
> >> yet not until after my work has been validated.
> >>
> >> The source-code is correct and complete yet must be refactored to clean
> >> it up before publication.
> >> *Halting problem proofs refuted on the basis of software engineering*
> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>> Furthermore, you yourself claim that the simulation gives different results from the actual code (you even describe this as "provably" on occasion) so you yourself do not believe that H(P,P) correctly simulates its input.
> >> This is also much more clearly shown in the rewrite of my paper that I
> >> did a few minutes ago. It can now be seen at the C level that the
> >> simulation of the input to H(P,P) is correct.
> >>
> >> It was very easy to see that the simulation of the input to H(P,P) is
> >> correct by simply matching the execution trace of the simulated P to its
> >> x86 source code. I annotated the x86 source-code to make this much
> >> easier for C programmers. I explain line-by-line exactly how the x86
> >> code corresponds to its C source.
> >>>
> >>>> The 23 emails that I had with a leading computer scientist made that
> >>>> very clear. Because of this I re-framed my explanation so that any
> >>>> expert C programmer that totally understands infinite recursion would be
> >>>> able to see that infinitely nested simulation is essentially the same
> >>>> thing.
> >>>
> >>> It might move the conversation on if you showed us what the computer scientist said - most helpfully if you quoted verbatim, but you could paraphrase if you're worried about confidentiality or the like. I take it there was more to it than them saying why you were wrong, and you saying that they didn't understand?
> >> This would be disrespecting his privacy. The point is that I now have an
> >> excellent measure that I have improved my words so much that my work is
> >> not simply rejected out-of-hand without review even by leading computer
> >> scientists.
> >>>> The next important point that requires one to have top software
> >>>> engineering skills that allowed me to transform H into a pure thus
> >>>> computable function: Infinitely nested simulation can be detected the
> >>>> first time that the simulated input calls the simulator with its same
> >>>> arguments. Infinite recursion requires seeing two such calls in a row.
> >>>> This change allowed me to discard the need for static local memory and
> >>>> do everything in local memory.
> >>>>>> A security guard at the front door is only required to validate people
> >>>>>> coming in the front door the actual behavior of the actual input to H(P,P).
> >>>>>>
> >>>>>> This same security guard is not required to validate people coming in
> >>>>>> the back door the direct execution of P(P). Unless a computation is
> >>>>>> specified as an actual input to H it is not in the domain of the
> >>>>>> computable function that H implements.
> >>>>>
> >>>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
> >>>
> >>>> No this a very long standing misconception. H is required to determine
> >>>> whether or not its correct simulation of its input would ever reach the
> >>>> normal termination of this input.
> >>>
> >>> No, what I have said is right. You are the one bringing in ideas about simulation.
> >>>
> >> A halt decider must compute the mapping from its inputs to an accept or
> >> reject state on the basis of the actual behavior that is actually
> >> specified by these inputs.
> >> It is common knowledge that a correct simulation of a program is a
> >> correct measure of the behavior of this program.
> >>
> >> If we accept that the behavior of the executed P(P) is the behavior that
> >> H must report on then we are saying that H must report on the behavior
> >> that is not the actual behavior of its actual input.
> >>>> Since no one ever bothered to think through the application of a
> >>>> simulating halt decider to the HP's impossible inputs they always stated
> >>>> the requirements incorrectly never realizing their mistake.
> >>>
> >>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>> reject state on the basis of the actual behavior that is actually
> >>>> specified by these inputs.
> >>>
> >>> Yes.
> >>>
> >>>> In the H/P concrete example it is easily proven that the actual behavior
> >>>> of the actual input to H(P,P) is not the behavior of the directly
> >>>> executed P(P). The best proof of this is the x86 execution trace of each
> >>>> that precisely corresponds to what the x86 source code of P specifies.
> >>>
> >>> You've included the word "actual" twice in that sentence and yet you still seem to think that the actual behaviour is not what really happens. How many "actual"s do you need?
> >>>
> >>>> From this is is obvious that the correctly simulated P cannot possibly
> >>>> terminate normally and the executed P(P) halts.
> >>>
> >>> If P(P) halts then a correct simulation of it will also halt.
> >> In the latest revision to my paper it is much more obvious that that
> >> actual behavior of the actual input is not the same as the behavior of
> >> the directly executed P(P).
> >
> > Did your expert in any way agree that the "actual behaviour" is different from the behaviour when P(P) is directly executed? Have you found anyone at all who agrees with you on this point?
> At the time my proof was only written in x86 assembly language and he
> had no knowledge of x86 assembly language Now it can be understood in C.
> >
> >> If H is required to report on the behavior of the direct execution of
> >> P(P) this forces H to report on something besides the actual behavior of
> >> its actual input.
> >
> > Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?
> That would require H to be a mind reader and report on something other
> than the actual behavior of its actual input.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
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: Fri, 15 Jul 2022 11:26:42 -0500
Date: Fri, 15 Jul 2022 11:26:41 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 226
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-p83XJHKj9jX6Cwx716Rp72LNy2/FKo6DTUyUCOs1BV9vnb/P0ZdrRIlcKmDgmHvm+dtZcV9CFgnBVWz!+fWitwcOjaRUYKABgQWKktI8OOz0zeUvSfaIJTb0eXY9PQkZMNCzGL7YYtsJ48kzy7tnimV48O9W!WA==
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: 15132
 by: olcott - Fri, 15 Jul 2022 16:26 UTC

On 7/15/2022 11:17 AM, Paul N wrote:
> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>> On 7/15/2022 7:34 AM, Paul N wrote:
>>> On Thursday, July 14, 2022 at 8:56:21 PM UTC+1, olcott wrote:
>>>> On 7/14/2022 6:42 AM, Paul N wrote:
>>>>> On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, olcott wrote:
>>>>>> On 7/13/2022 1:03 PM, Paul N wrote:
>>>>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
>>>
>>> I see you have now started a new thread on this very subject in both comp.lang.c and comp.lang.c++. You clearly are very rude.
>>>
>>>>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>>>>>
>>>>>>>>>> I rewrote this question so that a software engineer of ordinary skill
>>>>>>>>>> can easily verify that the simulated P does call H in what is
>>>>>>>>>> essentially infinite recursion. **This simplification is the result of
>>>>>>>>>> an extensive review (23 emails) by a leading computer scientist over the
>>>>>>>>>> weekend.**
>>>>>>>>>
>>>>>>>>>> Does H(P,P) correctly determine the halt status of the halting problem's
>>>>>>>>>> pathological input?
>>>>>>>>>
>>>>>>>>>> The following H and P have the above specified pathological relationship
>>>>>>>>>> to each other.
>>>>>>>>>>
>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> if (H(x, x))
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>>>>> essentially calling H in infinite recursion. H aborts its simulation on
>>>>>>>>>> this basis and rejects this input as non-halting.
>>>>>>>>>
>>>>>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>>>>>
>>>>>>>>>> *Once this halt deciding principle is accepted*
>>>>>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>>>>> specified by these inputs.
>>>>>>>>>
>>>>>>>>> Again, emphasis on "actual behaviour".
>>>>>>>>>
>>>>>>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>>>>>>> Every simulating halt decider that correctly simulates its input until
>>>>>>>>>> it correctly predicts that this simulated input would never terminate
>>>>>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>>>>
>>>>>>>>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
>>>>>>>>>
>>>>>>>>>> *The execution trace of function P() simulated by function H() shows*
>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>>>>>> infinitely recursive simulation.
>>>>>>>>>
>>>>>>>>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
>>>>>>>>>
>>>>>>>>>> This proves that H(P,P) correctly predicts that its correctly simulated
>>>>>>>>>> input would never terminate normally.
>>>>>>>>>
>>>>>>>>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
>>>>>>>> Welcome back.
>>>>>>>>
>>>>>>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>>>>>>> of the actual behavior specified by this input.
>>>>>>>
>>>>>>> No, the actual behaviour is the actual behaviour! If H correctly simulates this behaviour then it too will also be the same, but you have said numerous times that it does not correctly simulate the behaviour.
>>>>>>>
>>>>>> It is an easily verified fact that H(P,P) correctly simulates its input
>>>>>> to everyone having sufficient knowledge of the x86 assembly language
>>>>>> which currently seems to be hardy no one besides me. Back in the 1986
>>>>>> when I began my career about 10% of all programmers had familiarity
>>>>>> with the x86 language. This is the language that MSDOS and versions
>>>>>> of MS Windows prior to Windows NT were written in. Windows NT switched
>>>>>> to mostly C/C++.
>>>>>
>>>>> No it is not. Firstly, you have never posted the code to H so of course we can't verify it.
>>>> The latest rewrite of my paper (initially written as a reply to you) can
>>>> be fully understood at the C level with no need to have any access to
>>>> the source-code of H. I will publish all the the source-code very soon,
>>>> yet not until after my work has been validated.
>>>>
>>>> The source-code is correct and complete yet must be refactored to clean
>>>> it up before publication.
>>>> *Halting problem proofs refuted on the basis of software engineering*
>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>> Furthermore, you yourself claim that the simulation gives different results from the actual code (you even describe this as "provably" on occasion) so you yourself do not believe that H(P,P) correctly simulates its input.
>>>> This is also much more clearly shown in the rewrite of my paper that I
>>>> did a few minutes ago. It can now be seen at the C level that the
>>>> simulation of the input to H(P,P) is correct.
>>>>
>>>> It was very easy to see that the simulation of the input to H(P,P) is
>>>> correct by simply matching the execution trace of the simulated P to its
>>>> x86 source code. I annotated the x86 source-code to make this much
>>>> easier for C programmers. I explain line-by-line exactly how the x86
>>>> code corresponds to its C source.
>>>>>
>>>>>> The 23 emails that I had with a leading computer scientist made that
>>>>>> very clear. Because of this I re-framed my explanation so that any
>>>>>> expert C programmer that totally understands infinite recursion would be
>>>>>> able to see that infinitely nested simulation is essentially the same
>>>>>> thing.
>>>>>
>>>>> It might move the conversation on if you showed us what the computer scientist said - most helpfully if you quoted verbatim, but you could paraphrase if you're worried about confidentiality or the like. I take it there was more to it than them saying why you were wrong, and you saying that they didn't understand?
>>>> This would be disrespecting his privacy. The point is that I now have an
>>>> excellent measure that I have improved my words so much that my work is
>>>> not simply rejected out-of-hand without review even by leading computer
>>>> scientists.
>>>>>> The next important point that requires one to have top software
>>>>>> engineering skills that allowed me to transform H into a pure thus
>>>>>> computable function: Infinitely nested simulation can be detected the
>>>>>> first time that the simulated input calls the simulator with its same
>>>>>> arguments. Infinite recursion requires seeing two such calls in a row.
>>>>>> This change allowed me to discard the need for static local memory and
>>>>>> do everything in local memory.
>>>>>>>> A security guard at the front door is only required to validate people
>>>>>>>> coming in the front door the actual behavior of the actual input to H(P,P).
>>>>>>>>
>>>>>>>> This same security guard is not required to validate people coming in
>>>>>>>> the back door the direct execution of P(P). Unless a computation is
>>>>>>>> specified as an actual input to H it is not in the domain of the
>>>>>>>> computable function that H implements.
>>>>>>>
>>>>>>> H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
>>>>>
>>>>>> No this a very long standing misconception. H is required to determine
>>>>>> whether or not its correct simulation of its input would ever reach the
>>>>>> normal termination of this input.
>>>>>
>>>>> No, what I have said is right. You are the one bringing in ideas about simulation.
>>>>>
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>> It is common knowledge that a correct simulation of a program is a
>>>> correct measure of the behavior of this program.
>>>>
>>>> If we accept that the behavior of the executed P(P) is the behavior that
>>>> H must report on then we are saying that H must report on the behavior
>>>> that is not the actual behavior of its actual input.
>>>>>> Since no one ever bothered to think through the application of a
>>>>>> simulating halt decider to the HP's impossible inputs they always stated
>>>>>> the requirements incorrectly never realizing their mistake.
>>>>>
>>>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>> specified by these inputs.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> In the H/P concrete example it is easily proven that the actual behavior
>>>>>> of the actual input to H(P,P) is not the behavior of the directly
>>>>>> executed P(P). The best proof of this is the x86 execution trace of each
>>>>>> that precisely corresponds to what the x86 source code of P specifies.
>>>>>
>>>>> You've included the word "actual" twice in that sentence and yet you still seem to think that the actual behaviour is not what really happens. How many "actual"s do you need?
>>>>>
>>>>>> From this is is obvious that the correctly simulated P cannot possibly
>>>>>> terminate normally and the executed P(P) halts.
>>>>>
>>>>> If P(P) halts then a correct simulation of it will also halt.
>>>> In the latest revision to my paper it is much more obvious that that
>>>> actual behavior of the actual input is not the same as the behavior of
>>>> the directly executed P(P).
>>>
>>> Did your expert in any way agree that the "actual behaviour" is different from the behaviour when P(P) is directly executed? Have you found anyone at all who agrees with you on this point?
>> At the time my proof was only written in x86 assembly language and he
>> had no knowledge of x86 assembly language Now it can be understood in C.
>>>
>>>> If H is required to report on the behavior of the direct execution of
>>>> P(P) this forces H to report on something besides the actual behavior of
>>>> its actual input.
>>>
>>> Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?
>> That would require H to be a mind reader and report on something other
>> than the actual behavior of its actual input.
>
> There's no mind involved. If P is a computer program then P(P) is perfectly well defined. Either H can work out what it will do, or it can't.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<6f300c6b-c38f-4eee-986b-cc9b7fabc5c4n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a37:6c5:0:b0:6b5:ba8e:6673 with SMTP id 188-20020a3706c5000000b006b5ba8e6673mr9255510qkg.774.1657905957406;
Fri, 15 Jul 2022 10:25:57 -0700 (PDT)
X-Received: by 2002:a0d:e254:0:b0:31c:e4ae:3df6 with SMTP id
l81-20020a0de254000000b0031ce4ae3df6mr17223642ywe.238.1657905957203; Fri, 15
Jul 2022 10:25:57 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 15 Jul 2022 10:25:56 -0700 (PDT)
In-Reply-To: <esudnY8OB8GQ5Ez_nZ2dnUU7_81j4p2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=A1PyIwoAAACCahK0CVYFlDZG8JWzz_Go
NNTP-Posting-Host: 124.218.76.41
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com> <H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com> <YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com> <A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<85340e35-0bea-4938-9528-8c65fef8698cn@googlegroups.com> <WJKdnfsH_drbrVL_nZ2dnUU7_8xg4p2d@giganews.com>
<24817776-4ebc-427b-a4fa-3db6d9a40e03n@googlegroups.com> <NfWdnRnCHveUwlL_nZ2dnUU7_8zNnZ2d@giganews.com>
<76f3d5c1-ae9c-4d25-8d48-bf0b0c8f1b2en@googlegroups.com> <esudnY8OB8GQ5Ez_nZ2dnUU7_81j4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6f300c6b-c38f-4eee-986b-cc9b7fabc5c4n@googlegroups.com>
Subject: Re: Halting problem proofs refuted on the basis of software engineering
From: wynii...@gmail.com (wij)
Injection-Date: Fri, 15 Jul 2022 17:25:57 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 21
 by: wij - Fri, 15 Jul 2022 17:25 UTC

On Friday, 15 July 2022 at 22:26:30 UTC+8, olcott wrote:
> ...
> P(P) is not the actual behavior of the actual input to H(P,P).
>

Halting problem https://en.wikipedia.org/wiki/Halting_problem
....the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever...

The HP asks the property of P(P).
H(P,P)=1 iff P(P) halts
H(P,P)=0 iff P(P) does not halts

If "P(P) is not the actual behavior of the actual input to H(P,P)." (seemingly
your English is worse than mine), your H is simply, terribly wrong.
No one cares your POOH.

> --
> Copyright 2022 Pete Olcott
>
> "Idiot hits a target no one else can hit;
> Nut hits a target no one else can see."
> ME

Re: Halting problem proofs refuted on the basis of software engineering

<FZidncjlmIMVOUz_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic
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!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 15 Jul 2022 12:31:52 -0500
Date: Fri, 15 Jul 2022 12:31:51 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<85340e35-0bea-4938-9528-8c65fef8698cn@googlegroups.com>
<WJKdnfsH_drbrVL_nZ2dnUU7_8xg4p2d@giganews.com>
<24817776-4ebc-427b-a4fa-3db6d9a40e03n@googlegroups.com>
<NfWdnRnCHveUwlL_nZ2dnUU7_8zNnZ2d@giganews.com>
<76f3d5c1-ae9c-4d25-8d48-bf0b0c8f1b2en@googlegroups.com>
<esudnY8OB8GQ5Ez_nZ2dnUU7_81j4p2d@giganews.com>
<6f300c6b-c38f-4eee-986b-cc9b7fabc5c4n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <6f300c6b-c38f-4eee-986b-cc9b7fabc5c4n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <FZidncjlmIMVOUz_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 71
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LRu4ES51ki5j6TP5UVhFu+qBOsR7xGbXrbuqnzb3+/qoPzyaJgXjYFFBGlr0RpTx46/1K111+YfLIbs!/Ru8MsQHCAHW4mZ/Z1u6jAD89gRSs9o7wzpGl56q7lxjUR3LkymlOKBq1Dj7F1pDO/0gCkMiRisq!Vw==
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: 4381
X-Received-Bytes: 4503
 by: olcott - Fri, 15 Jul 2022 17:31 UTC

On 7/15/2022 12:25 PM, wij wrote:
> On Friday, 15 July 2022 at 22:26:30 UTC+8, olcott wrote:
>> ...
>> P(P) is not the actual behavior of the actual input to H(P,P).
>>
>
> Halting problem https://en.wikipedia.org/wiki/Halting_problem
> ...the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever...
>
> The HP asks the property of P(P).
> H(P,P)=1 iff P(P) halts
> H(P,P)=0 iff P(P) does not halts
>
> If "P(P) is not the actual behavior of the actual input to H(P,P)." (seemingly
> your English is worse than mine), your H is simply, terribly wrong.
> No one cares your POOH.
>

If you simply pay close attention to the software engineering of what I
say it is proven that I am correct.

If you ignore the software engineering of what I say and simply assume
that I must be wrong you are dishonest.

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

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

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

When simulating halt decider H(P,P) simulates its input we can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P).

The above shows that the simulated P cannot possibly terminate normally.
H(P,P) simulates its input then P calls H(P,P) to simulate itself again.

Because H sees the same (1)(2)(3) that we see H can see that this
otherwise infinitely nested simulation would never end. H aborts its
simulation of P and rejects P as non-halting.

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

It is common knowledge that a correct simulation of a program is a
correct measure of the behavior of this program.

If we accept that the behavior of the executed P(P) is the behavior that
H must report on then we are saying that H must report on the behavior
that is not the actual behavior of its actual input.

--
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: Halting problem proofs refuted on the basis of software engineering

<f4683534-071c-4d4f-b446-cacc6291c31bn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ad4:5c8c:0:b0:473:874c:dd71 with SMTP id o12-20020ad45c8c000000b00473874cdd71mr13192944qvh.3.1657910889207;
Fri, 15 Jul 2022 11:48:09 -0700 (PDT)
X-Received: by 2002:a81:ac13:0:b0:31d:fa03:b084 with SMTP id
k19-20020a81ac13000000b0031dfa03b084mr4444561ywh.172.1657910888972; Fri, 15
Jul 2022 11:48:08 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 15 Jul 2022 11:48:08 -0700 (PDT)
In-Reply-To: <FZidncjlmIMVOUz_nZ2dnUU7_83NnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=A1PyIwoAAACCahK0CVYFlDZG8JWzz_Go
NNTP-Posting-Host: 124.218.76.41
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com> <H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com> <YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com> <A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<85340e35-0bea-4938-9528-8c65fef8698cn@googlegroups.com> <WJKdnfsH_drbrVL_nZ2dnUU7_8xg4p2d@giganews.com>
<24817776-4ebc-427b-a4fa-3db6d9a40e03n@googlegroups.com> <NfWdnRnCHveUwlL_nZ2dnUU7_8zNnZ2d@giganews.com>
<76f3d5c1-ae9c-4d25-8d48-bf0b0c8f1b2en@googlegroups.com> <esudnY8OB8GQ5Ez_nZ2dnUU7_81j4p2d@giganews.com>
<6f300c6b-c38f-4eee-986b-cc9b7fabc5c4n@googlegroups.com> <FZidncjlmIMVOUz_nZ2dnUU7_83NnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f4683534-071c-4d4f-b446-cacc6291c31bn@googlegroups.com>
Subject: Re: Halting problem proofs refuted on the basis of software engineering
From: wynii...@gmail.com (wij)
Injection-Date: Fri, 15 Jul 2022 18:48:09 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 125
 by: wij - Fri, 15 Jul 2022 18:48 UTC

On Saturday, 16 July 2022 at 01:32:00 UTC+8, olcott wrote:
> On 7/15/2022 12:25 PM, wij wrote:
> > On Friday, 15 July 2022 at 22:26:30 UTC+8, olcott wrote:
> >> ...
> >> P(P) is not the actual behavior of the actual input to H(P,P).
> >>
> >
> > Halting problem https://en.wikipedia.org/wiki/Halting_problem
> > ...the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever...
> >
> > The HP asks the property of P(P).
> > H(P,P)=1 iff P(P) halts
> > H(P,P)=0 iff P(P) does not halts
> >
> > If "P(P) is not the actual behavior of the actual input to H(P,P)." (seemingly
> > your English is worse than mine), your H is simply, terribly wrong.
> > No one cares your POOH.
> >
> If you simply pay close attention to the software engineering of what I
> say it is proven that I am correct.
>
> If you ignore the software engineering of what I say and simply assume
> that I must be wrong you are dishonest.
Many have paid enough attention, some might even pay attention deeper trying
replicate your talk/response with LISP, because you are such a perfect model (idiot)
for a programing excise.
Like the POOH, you are absolutely correct on your own, no one can refute. But no
one cares about POOH.

You seem not to know nearly every one answering to you is many times capable
than you are, beyond your imagination. You may be excellent on other non-technicals, though.

> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
> When simulating halt decider H(P,P) simulates its input we can see that:
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P).
>
> The above shows that the simulated P cannot possibly terminate normally.
> H(P,P) simulates its input then P calls H(P,P) to simulate itself again.
>
> Because H sees the same (1)(2)(3) that we see H can see that this
> otherwise infinitely nested simulation would never end. H aborts its
> simulation of P and rejects P as non-halting.
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> It is common knowledge that a correct simulation of a program is a
> correct measure of the behavior of this program.
>
> If we accept that the behavior of the executed P(P) is the behavior that
> H must report on then we are saying that H must report on the behavior
> that is not the actual behavior of its actual input.

If you don't get the basic logic right, answering your these questions is in vain
(this is a snippet from your 'revised' version):

| // original definition of valid (same as P → C)
| | Material conditional
| p q p → q
| T T T
| T F F
| F T T
| F F T
| | Transforming the above to become truth preserving:
| | The definition of valid is changed to:
| p q p [PROVES] q
| T T T
| T F F
| F T F
| F F F
| | A deductive argument is said to be valid if and only if it takes a form
| that the conclusion is only true if and only if the premises are true.
| | All of the above is summed up as
| P [PROVES] C if and only if (True(P) ⊢ True(C) ∧ False(P) ⊢ False(C))
| | modal operators are most often interpreted
| "□" for "Necessarily" and "◇" for "Possibly".
| https://en.wikipedia.org/wiki/Modal_logic
| (P [PROVES] C) ↔ (P ↔ □C)
| | H(P,P)==0 is proven to be true on the basis that truth preserving
| operations are applied to premises that are verified as true: (P ↔ □C)

> --
"Idiot sees a target no one else can see;
Nut hits a target no one else can hit."
ME

Re: Halting problem proofs refuted on the basis of software engineering

<UHmAK.80403$dh2.21223@fx46.iad>

 copy mid

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

 copy link   Newsgroups: 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!fx46.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<85340e35-0bea-4938-9528-8c65fef8698cn@googlegroups.com>
<WJKdnfsH_drbrVL_nZ2dnUU7_8xg4p2d@giganews.com>
<24817776-4ebc-427b-a4fa-3db6d9a40e03n@googlegroups.com>
<NfWdnRnCHveUwlL_nZ2dnUU7_8zNnZ2d@giganews.com>
<76f3d5c1-ae9c-4d25-8d48-bf0b0c8f1b2en@googlegroups.com>
<esudnY8OB8GQ5Ez_nZ2dnUU7_81j4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <esudnY8OB8GQ5Ez_nZ2dnUU7_81j4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 340
Message-ID: <UHmAK.80403$dh2.21223@fx46.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: Fri, 15 Jul 2022 19:25:40 -0400
X-Received-Bytes: 16740
 by: Richard Damon - Fri, 15 Jul 2022 23:25 UTC

On 7/15/22 10:26 AM, olcott wrote:
> On 7/15/2022 4:20 AM, wij wrote:
>> On Thursday, 14 July 2022 at 08:10:56 UTC+8, olcott wrote:
>>> On 7/13/2022 4:11 PM, wij wrote:
>>>> On Thursday, 14 July 2022 at 04:51:25 UTC+8, olcott wrote:
>>>>> On 7/13/2022 3:47 PM, wij wrote:
>>>>>> On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
>>>>>>> On 7/13/2022 1:03 PM, Paul N wrote:
>>>>>>>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>>>>>>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>>>>>>>> Firstly, this subject matter is not relevant in comp.lang.c or
>>>>>>>>>> comp.lang.c++, so please stop posting any of it there. If I
>>>>>>>>>> see any more posts of this sort in either of those newsgroups
>>>>>>>>>> I shall assume that, regardless of the merits of your
>>>>>>>>>> argument, you are very rude.
>>>>>>>>>>
>>>>>>>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>>>>>>>
>>>>>>>>>>> I rewrote this question so that a software engineer of
>>>>>>>>>>> ordinary skill
>>>>>>>>>>> can easily verify that the simulated P does call H in what is
>>>>>>>>>>> essentially infinite recursion. **This simplification is the
>>>>>>>>>>> result of
>>>>>>>>>>> an extensive review (23 emails) by a leading computer
>>>>>>>>>>> scientist over the
>>>>>>>>>>> weekend.**
>>>>>>>>>>
>>>>>>>>>>> Does H(P,P) correctly determine the halt status of the
>>>>>>>>>>> halting problem's
>>>>>>>>>>> pathological input?
>>>>>>>>>>
>>>>>>>>>>> The following H and P have the above specified pathological
>>>>>>>>>>> relationship
>>>>>>>>>>> to each other.
>>>>>>>>>>>
>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>> if (H(x, x))
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>>>>>> essentially calling H in infinite recursion. H aborts its
>>>>>>>>>>> simulation on
>>>>>>>>>>> this basis and rejects this input as non-halting.
>>>>>>>>>>
>>>>>>>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>>>>>>>
>>>>>>>>>>> *Once this halt deciding principle is accepted*
>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>> accept or
>>>>>>>>>>> reject state on the basis of the actual behavior that is
>>>>>>>>>>> actually
>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>
>>>>>>>>>> Again, emphasis on "actual behaviour".
>>>>>>>>>>
>>>>>>>>>>> *Then (by logical necessity) this is understood to implement
>>>>>>>>>>> that*
>>>>>>>>>>> Every simulating halt decider that correctly simulates its
>>>>>>>>>>> input until
>>>>>>>>>>> it correctly predicts that this simulated input would never
>>>>>>>>>>> terminate
>>>>>>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>>>>>
>>>>>>>>>> You have stated numerous times that a program that "correctly
>>>>>>>>>> simulates its input" can have different results. Thus it is
>>>>>>>>>> not clear what you mean by the phrase. There is no logical
>>>>>>>>>> necessity to accept anything about a correct simulation which
>>>>>>>>>> does not simulate correctly.
>>>>>>>>>>
>>>>>>>>>>> *The execution trace of function P() simulated by function
>>>>>>>>>>> H() shows*
>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>> (3) With no instructions in P() that could possibly escape this
>>>>>>>>>>> infinitely recursive simulation.
>>>>>>>>>>
>>>>>>>>>> Ah, but there are instructions in H which escape from the
>>>>>>>>>> infinite recursion. You've said numerous times that there are.
>>>>>>>>>> See only a few lines up. If you pretend that they are somehow
>>>>>>>>>> not there, you are not correctly simulating H and hence not
>>>>>>>>>> correctly simulating P which calls it.
>>>>>>>>>>
>>>>>>>>>>> This proves that H(P,P) correctly predicts that its correctly
>>>>>>>>>>> simulated
>>>>>>>>>>> input would never terminate normally.
>>>>>>>>>>
>>>>>>>>>> As you've said above, in capitals and with asterisks, changing
>>>>>>>>>> the subject is not a rebuttal. You're trying to change the
>>>>>>>>>> subject from the actual behaviour of P(P) to some sort of
>>>>>>>>>> "simulated" behaviour of P(P) which you have said yourself is
>>>>>>>>>> different.
>>>>>>>>> Welcome back.
>>>>>>>>>
>>>>>>>>> When H(P,P) correctly simulates its input this is the ultimate
>>>>>>>>> measure
>>>>>>>>> of the actual behavior specified by this input.
>>>>>>>>
>>>>>>>> No, the actual behaviour is the actual behaviour! If H
>>>>>>>> correctlky simulates this behaviour then it too will also be the
>>>>>>>> same, but you have siad numerous times that it does not
>>>>>>>> correctly simulate the behavoutr.
>>>>>>>>
>>>>>>> It is an easily verified fact that H(P,P) correctly simulates its
>>>>>>> input
>>>>>>> to everyone having sufficient knowledge of the x86 assembly language
>>>>>>> which currently seems to be hardy no one besides me. Back in the
>>>>>>> 1986
>>>>>>> when I began my career about 10% of all programmers had familiarity
>>>>>>> with the x86 language. This is the language that MSDOS and versions
>>>>>>> of MS Windows prior to Windows NT were written in. Windows NT
>>>>>>> switched
>>>>>>> to mostly C/C++.
>>>>>>>
>>>>>>> The 23 emails that I had with a leading computer scientist made that
>>>>>>> very clear. Because of this I re-framed my explanation so that any
>>>>>>> expert C programmer that totally understands infinite recursion
>>>>>>> would be
>>>>>>> able to see that infinitely nested simulation is essentially the
>>>>>>> same
>>>>>>> thing.
>>>>>>>
>>>>>>> The next important point that requires one to have top software
>>>>>>> engineering skills that allowed me to transform H into a pure thus
>>>>>>> computable function: Infinitely nested simulation can be detected
>>>>>>> the
>>>>>>> first time that the simulated input calls the simulator with its
>>>>>>> same
>>>>>>> arguments. Infinite recursion requires seeing two such calls in a
>>>>>>> row.
>>>>>>> This change allowed me to discard the need for static local
>>>>>>> memory and
>>>>>>> do everything in local memory.
>>>>>>>>> A security guard at the front door is only required to validate
>>>>>>>>> people
>>>>>>>>> coming in the front door the actual behavior of the actual
>>>>>>>>> input to H(P,P).
>>>>>>>>>
>>>>>>>>> This same security guard is not required to validate people
>>>>>>>>> coming in
>>>>>>>>> the back door the direct execution of P(P). Unless a
>>>>>>>>> computation is
>>>>>>>>> specified as an actual input to H it is not in the domain of the
>>>>>>>>> computable function that H implements.
>>>>>>>>
>>>>>>>> H takes two arguments. The first is a program to be considered
>>>>>>>> and the second is the input that could be supplied to that
>>>>>>>> program. H is required to decide, correctly, whether the program
>>>>>>>> would halt given that input, ie whether M(X) would halt.
>>>>>>> No this a very long standing misconception. H is required to
>>>>>>> determine
>>>>>>> whether or not its correct simulation of its input would ever
>>>>>>> reach the
>>>>>>> normal termination of this input.
>>>>>>>
>>>>>>> Since no one ever bothered to think through the application of a
>>>>>>> simulating halt decider to the HP's impossible inputs they always
>>>>>>> stated
>>>>>>> the requirements incorrectly never realizing their mistake.
>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>> accept or
>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>> specified by these inputs.
>>>>>>> In the H/P concrete example it is easily proven that the actual
>>>>>>> behavior
>>>>>>> of the actual input to H(P,P) is not the behavior of the directly
>>>>>>> executed P(P). The best proof of this is the x86 execution trace
>>>>>>> of each
>>>>>>> that precisely corresponds to what the x86 source code of P
>>>>>>> specifies.
>>>>>>>
>>>>>>>  From this is is obvious that the correctly simulated P cannot
>>>>>>> possibly
>>>>>>> terminate normally and the executed P(P) halts.
>>>>>>>
>>>>>>> Those lacking knowledge of the x86 language can understand that this
>>>>>>> first halt deciding principle is necessarily correct:
>>>>>>>
>>>>>>> *When this halt deciding principle understood to be correct*
>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>> accept or
>>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>>> specified by these inputs.
>>>>>>> And this second halt deciding principle follows from the first
>>>>>>> one by
>>>>>>> logical necessity.
>>>>>>>
>>>>>>> *Then (by logical necessity) this implements that principle*
>>>>>>> Every simulating halt decider that correctly simulates its input
>>>>>>> until
>>>>>>> it correctly predicts that this simulated input would never
>>>>>>> terminate
>>>>>>> normally, correctly rejects this input as non-halting.
>>>>>>>
>>>>>>>>
>>>>>>>> If a program M would halt given input X, then H(M, X) is
>>>>>>>> required to be non-zero.
>>>>>>>> If a program M would not halt given input X, then H(M, X) is
>>>>>>>> required to be zero.
>>>>>>>>
>>>>>>> This is a misconception that can only be true if the halt decider is
>>>>>>> required to report on something besides the actual behavior of its
>>>>>>> actual input.
>>>>>>>
>>>>>>> The ultimate measure of the actual behavior of the actual input
>>>>>>> is the
>>>>>>> provable correct simulation of this input by the simulating halt
>>>>>>> decider.
>>>>>>>
>>>>>>> To assume that this behavior must be the same as the directly
>>>>>>> executed
>>>>>>> P(P) after it has been conclusively proven to not be that same as an
>>>>>>> established fact is at least a little nutty.
>>>>>>>
>>>>>>> That people unequivocally state that I must be wrong entirely on the
>>>>>>> basis that they lack sufficient understanding of the x86 language to
>>>>>>> understand my proof is a worst case example of the ad ignorantiam
>>>>>>> logic
>>>>>>> error.
>>>>>>>> If for some combination M, X the function H(M, X) gives the
>>>>>>>> wrong answer, then it is not a halt decider. If particular, if
>>>>>>>> H(M, X) = 0 but M(X) does halt, then the answer is wrong. You
>>>>>>>> can't get out of it by arguing that M(X) is "direct" and H(M, X)
>>>>>>>> is a "correct simulation", whatever that might mean. The answer
>>>>>>>> needs to relate to the actual behaviour, as you yourself have
>>>>>>>> said numerous times.
>>>>>>>>
>>>>>>>> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P)
>>>>>>>> does not halt, H(P, P) is required to be zero. Anything else is
>>>>>>>> the wrong answer.
>>>>>>>>
>>>>>>>> When we calculate H(P, P), we are supplying P as the first
>>>>>>>> argument and so P is specified as an actual input to H. And we
>>>>>>>> are interested in the actual behaviour of P, the actual input.
>>>>>>>> There is no "back door" by which you can say that P(P) is not
>>>>>>>> the function and input we are talking about.
>>>>>>>>
>>>>>>>>>> To summarise, if H(P, P) terminates (which you have never
>>>>>>>>>> denied), then there are at most four possibilities:
>>>>>>>>>>
>>>>>>>>>> A) H(P, P) returns 0 and P(P) terminates.
>>>>>>>>>> B) H(P, P) returns non-zero and P(P) terminates.
>>>>>>>>>> C) H(P, P) returns 0 and P(P) does not terminate.
>>>>>>>>>> D) H(P, P) returns non-zero and P(P) does not terminate.
>>>>>>>>>>
>>>>>>>>>> B and C are clearly not possible from the definition of P. In
>>>>>>>>>> A and D, H produces the wrong answer.
>>>>>>>>
>>>>>>>>> A1) H(P, P) returns 0 because it correctly determines that the
>>>>>>>>> input
>>>>>>>>> that it correctly simulates would never terminate normally.
>>>>>>>>
>>>>>>>> No, that is not a correct answer. You have said numerous times
>>>>>>>> that P(P) terminates.
>>>>>>>>
>>>>>>>>> A2) Directly executed P(P) halts because of (A)
>>>>>>> --
>>>>>>> Copyright 2022 Pete Olcott
>>>>>>>
>>>>>>> "Talent hits a target no one else can hit;
>>>>>>> Genius hits a target no one else can see."
>>>>>>> Arthur Schopenhauer
>>>>>>
>>>>>> Halting problem https://en.wikipedia.org/wiki/Halting_problem
>>>>>> ...the halting problem is the problem of determining, from a
>>>>>> description of an arbitrary
>>>>>> computer program and an input, whether the program will finish
>>>>>> running, or continue to run forever.
>>>>>>
>>>>>> The property that an arbitrary program P will finish running or
>>>>>> not is determined by
>>>>>> running P as an independent program
>>>>> Because that would require that a halt decider must sometimes make its
>>>>> halt status decision on a basis other than the actual behavior of its
>>>>> actual input that long standing misconception has been refuted.
>>>>> --
>>>>> Copyright 2022 Pete Olcott
>>>>>
>>>>> "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see."
>>>>> Arthur Schopenhauer
>>>>
>>>> Because we often encountered a problem to know whether a
>>>> 'independent' running
>>>> program P will halt or not, therefore, this is an interested problem.
>>>> We don't have such a problem asking H(P,P), the P 'simulated' by H
>>>> halt or not.
>>>>
>>>
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>> Everyone's rebuttal to this is that the halt decider must be a mind
>>> reader and report on the behavior of a computation that only exists in
>>> the minds of the readers and its not the same computation that is
>>> specified by its inputs.
>>>
>>> That is goofy and nutty and crazy.
>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>>
>> So, you are perfect aware you are not talking about the HP. But we are
>> only
>> interested in such a halt decider H (and GUR) that:
>> H(P,P)=1 iff P(P) halts.
>> H(P,P)=0 iff P(P) does not halts.
>>
>> No one care about your POOH.
>>
>> If you like to reason, sorry, you are an idiot, incapable of logic
>> reasoning.
>> Most of all,  extremely cheeky, spit-able, stone-able.
>
> P(P) is not the actual behavior of the actual input to H(P,P).
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:c8a:b0:473:26f:59e0 with SMTP id r10-20020a0562140c8a00b00473026f59e0mr14876045qvr.63.1657970592460;
Sat, 16 Jul 2022 04:23:12 -0700 (PDT)
X-Received: by 2002:a25:2e50:0:b0:669:9a76:beb with SMTP id
b16-20020a252e50000000b006699a760bebmr18498777ybn.597.1657970592219; Sat, 16
Jul 2022 04:23:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Sat, 16 Jul 2022 04:23:12 -0700 (PDT)
In-Reply-To: <QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=89.240.151.96; posting-account=0B-afgoAAABP6274zLUJKa8ZpdIdhsYx
NNTP-Posting-Host: 89.240.151.96
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com> <H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com> <YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com> <A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com> <BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com> <Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com> <QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
Subject: Re: Halting problem proofs refuted on the basis of software engineering
From: gw7...@aol.com (Paul N)
Injection-Date: Sat, 16 Jul 2022 11:23:12 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 53
 by: Paul N - Sat, 16 Jul 2022 11:23 UTC

On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
> On 7/15/2022 11:17 AM, Paul N wrote:
> > On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
> >> On 7/15/2022 7:34 AM, Paul N wrote:
> >>> Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?
> >> That would require H to be a mind reader and report on something other
> >> than the actual behavior of its actual input.
> >
> > There's no mind involved. If P is a computer program then P(P) is perfectly well defined. Either H can work out what it will do, or it can't.

You haven't said in what way a "mind" is involved in the direct execution of P(P).

> It is like you ask your wife to go to the store and buy "a dozen eggs"
> fully expecting her to understand that what you mean by "a dozen eggs"
> is {a half gallon of grape juice}. When she gets back with the eggs you
> ask her where is the grape juice?

No, you are the one who is twisting the meaning of words. When I talk about the actual behaviour of P(P) I mean what actually happens when P(P) is executed. That's what the words "actual" and "behaviour" mean.

You are using the words "actual behavior" to mean something else which is clearly different. It seems to relate to some sort of simulator, which you simultaneously claim to be correct while acknowledging it produces different results from executing P(P) directly.

Can you tell us if that "actual behavior" does actually happen in any circumstances, or is it (despite the name) just a theoretical thing?

> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.

Yes, where the actual behaviour is the behaviour that actually happens.

> It is common knowledge that a correct simulation of a program is a
> correct measure of the behavior of this program.

Yes, if the simulation is correct. You've insisted numerous times that your own simulator is incorrect.

> If we accept that the behavior of the executed P(P) is the behavior that
> H must report on then we are saying that H must report on the behavior
> that is not the actual behavior of its actual input.

No, the two things are the same.

Re: Halting problem proofs refuted on the basis of software engineering

<kbudndVL3-N9IE__nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 16 Jul 2022 08:32:16 -0500
Date: Sat, 16 Jul 2022 08:32:15 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <kbudndVL3-N9IE__nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 70
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-asriVcpz4wGmC0M0epySrl+SsAbDrN/a74WIREbu/unoNT2bEcaL0jiMHSQ9wYimNA17BfnEDje2egd!GGL/gk1tuYzEMwsXONp4p7gLSOXzUNnAcX3gbD9ohMCxj//UMvyWNMYLIV9mNFOHoBY69bYlI8+Z!pQ==
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: 5273
 by: olcott - Sat, 16 Jul 2022 13:32 UTC

On 7/16/2022 6:23 AM, Paul N wrote:
> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>> On 7/15/2022 11:17 AM, Paul N wrote:
>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>> Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?
>>>> That would require H to be a mind reader and report on something other
>>>> than the actual behavior of its actual input.
>>>
>>> There's no mind involved. If P is a computer program then P(P) is perfectly well defined. Either H can work out what it will do, or it can't.
>
> You haven't said in what way a "mind" is involved in the direct execution of P(P).
> >> It is like you ask your wife to go to the store and buy "a dozen eggs"
>> fully expecting her to understand that what you mean by "a dozen eggs"
>> is {a half gallon of grape juice}. When she gets back with the eggs you
>> ask her where is the grape juice?
>
> No, you are the one who is twisting the meaning of words. When I talk about the actual behaviour of P(P) I mean what actually happens when P(P) is executed. That's what the words "actual" and "behaviour" mean.

Those words are only in your mind and not specified as input so they
don't count.

>
> You are using the words "actual behavior" to mean something else which is clearly different. It seems to relate to some sort of simulator, which you simultaneously claim to be correct while acknowledging it produces different results from executing P(P) directly.

If you knew the x86 language you could verify that the simulator only
simulates the x86 source-code that is specified by P, line-by-line.
This can not be seen at the C level.

The lines of x86 source-code are simulated in exactly the same way that
they are specified.

> Can you tell us if that "actual behavior" does actually happen in any circumstances, or is it (despite the name) just a theoretical thing?

If C source-code says printf("hello"); and it prints "hello" then it
does what is specifies.

>
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> Yes, where the actual behaviour is the behaviour that actually happens.
>
>> It is common knowledge that a correct simulation of a program is a
>> correct measure of the behavior of this program.
>
> Yes, if the simulation is correct.

I HAVE NEVER SAID THAT ONCE IN A MILLION YEARS
You've insisted numerous times that your own simulator is incorrect.

>
>> If we accept that the behavior of the executed P(P) is the behavior that
>> H must report on then we are saying that H must report on the behavior
>> that is not the actual behavior of its actual input.
>
> No, the two things are the same.

It is a verifiable fact that they are not the same.
You cannot truthfully say that they are the same when you know that you
lack the technical knowledge of the x86 language proving that they are
not the same.

--
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: Halting problem proofs refuted on the basis of software engineering

<sSzAK.55785$iR.25305@fx44.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<kbudndVL3-N9IE__nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <kbudndVL3-N9IE__nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 127
Message-ID: <sSzAK.55785$iR.25305@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: Sat, 16 Jul 2022 10:24:24 -0400
X-Received-Bytes: 6586
 by: Richard Damon - Sat, 16 Jul 2022 14:24 UTC

On 7/16/22 9:32 AM, olcott wrote:
> On 7/16/2022 6:23 AM, Paul N wrote:
>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>> Do you accept that if H were required to report on the behaviour
>>>>>> of the direct execution of P(P) then it would not be possible to
>>>>>> write such an H?
>>>>> That would require H to be a mind reader and report on something other
>>>>> than the actual behavior of its actual input.
>>>>
>>>> There's no mind involved. If P is a computer program then P(P) is
>>>> perfectly well defined. Either H can work out what it will do, or it
>>>> can't.
>>
>> You haven't said in what way a "mind" is involved in the direct
>> execution of P(P).
>>  >> It is like you ask your wife to go to the store and buy "a dozen
>> eggs"
>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>> is {a half gallon of grape juice}. When she gets back with the eggs you
>>> ask her where is the grape juice?
>>
>> No, you are the one who is twisting the meaning of words. When I talk
>> about the actual behaviour of P(P) I mean what actually happens when
>> P(P) is executed. That's what the words "actual" and "behaviour" mean.
>
> Those words are only in your mind and not specified as input so they
> don't count.

But they ARE specified, at least if H claims to be a Halt Decider.
Remember you definitions:

H(M,x) accepts (returns 1) if M(x) will halt, and
H(M,x) rejects (returns 0) if M(x) will NEVER halt after an unbounded
number of steps.

Thus the behavior of M(x), which in this case is P(P), IS specified to
be the MEANING of the input to H.

>
>>
>> You are using the words "actual behavior" to mean something else which
>> is clearly different. It seems to relate to some sort of simulator,
>> which you simultaneously claim to be correct while acknowledging it
>> produces different results from executing P(P) directly.
>
> If you knew the x86 language you could verify that the simulator only
> simulates the x86 source-code that is specified by P, line-by-line.
> This can not be seen at the C level.

And here is part of your problem.

The x86 assembly lanague of JUST the function P is NOT an actual program
that specifies any behavior at all.

Only when you include the code for H, does it actually specify behavior.

When you include that code, P(P) specifies halting behavior of H(P,P)
returns 0

>
> The lines of x86 source-code are simulated in exactly the same way that
> they are specified.

Nope. To properly simulate the call to H you need to simulate the code
IN H to get the actual behavior.

>
>> Can you tell us if that "actual behavior" does actually happen in any
>> circumstances, or is it (despite the name) just a theoretical thing?
>
> If C source-code says printf("hello"); and it prints "hello" then it
> does what is specifies.

And that is because the C language specifes the behavior of printf, and
printf actually behaves according to its specification.

You H doesn't meet its specification, because it doesn't properly prove
that its input will not halt with H behaving the way it behaves, so your
system in incorrect.

>
>>
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> Yes, where the actual behaviour is the behaviour that actually happens.
>>
>>> It is common knowledge that a correct simulation of a program is a
>>> correct measure of the behavior of this program.
>>
>> Yes, if the simulation is correct.
>
> I HAVE NEVER SAID THAT ONCE IN A MILLION YEARS
> You've insisted numerous times that your own simulator is incorrect.

Are you saying you never said that H does a correct simulation of its
input? If H is allowed to be based on an INCORRECT simulstion, does its
answer actually mean anything?

>
>>
>>> If we accept that the behavior of the executed P(P) is the behavior that
>>> H must report on then we are saying that H must report on the behavior
>>> that is not the actual behavior of its actual input.
>>
>> No, the two things are the same.
>
> It is a verifiable fact that they are not the same.
> You cannot truthfully say that they are the same when you know that you
> lack the technical knowledge of the x86 language proving that they are
> not the same.
>

Then P is not the requried machine and you whole proof is worthless. PERIOD.

P MUST call H in a way to ask about P with its input. Since you have
defined P(x) to call H(x,x), and that P(P) is the "impossible program",
if H(P,P) doesn't refer to P(P), your setup is just incorrect and shows
nothing.

FAIL.

Re: Halting problem proofs refuted on the basis of software engineering

<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 16 Jul 2022 10:54:12 -0500
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
From: news.dea...@darjeeling.plus.com (Mike Terry)
Date: Sat, 16 Jul 2022 16:54:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.8
MIME-Version: 1.0
In-Reply-To: <37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
Lines: 53
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-b0YPpjrwcRg6DW83hVQcnALChBZ2ybUBZZafmDXXTwLphd9QgZYlr7AoAR8OdTRsyBW0Hl0fFbXuGa1!aCGOzFIozmynMsli2sYdPtkyWRWQzhPfp7TZDrEyfvN/bJg5yVUQnJ6WublNhUqdLEbUp+5Uejhq!/G1/hFjfiIPx/jDXkxVipXDYzAE=
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: 4854
 by: Mike Terry - Sat, 16 Jul 2022 15:54 UTC

On 16/07/2022 12:23, Paul N wrote:
> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>> On 7/15/2022 11:17 AM, Paul N wrote:
>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>> Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?
>>>> That would require H to be a mind reader and report on something other
>>>> than the actual behavior of its actual input.
>>>
>>> There's no mind involved. If P is a computer program then P(P) is perfectly well defined. Either H can work out what it will do, or it can't.
>
> You haven't said in what way a "mind" is involved in the direct execution of P(P).
>
>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>> fully expecting her to understand that what you mean by "a dozen eggs"
>> is {a half gallon of grape juice}. When she gets back with the eggs you
>> ask her where is the grape juice?
>
> No, you are the one who is twisting the meaning of words. When I talk about the actual behaviour of P(P) I mean what actually happens when P(P) is executed. That's what the words "actual" and "behaviour" mean.
>
> You are using the words "actual behavior" to mean something else which is clearly different. It seems to relate to some sort of simulator, which you simultaneously claim to be correct while acknowledging it produces different results from executing P(P) directly.
>
> Can you tell us if that "actual behavior" does actually happen in any circumstances, or is it (despite the name) just a theoretical thing?
>
>> A halt decider must compute the mapping from its inputs to an accept or
>> reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> Yes, where the actual behaviour is the behaviour that actually happens.
>
>> It is common knowledge that a correct simulation of a program is a
>> correct measure of the behavior of this program.
>
> Yes, if the simulation is correct. You've insisted numerous times that your own simulator is incorrect.

PO's simulation is correct at the individual instruction level. His H steps the simulation forward
a number of steps, and each of those steps exactly matches the P(P) calculation steps. At some
point before the final P RET instruction, his H decides to stop stepping (for whatever reason), so
H's simulation is *incomplete*.

That is the only sense in which P(P) and "the simulated input to H(P,P)" differ - H simply stops
simulating before P(P) terminates.

Mike.

>
>> If we accept that the behavior of the executed P(P) is the behavior that
>> H must report on then we are saying that H must report on the behavior
>> that is not the actual behavior of its actual input.
>
> No, the two things are the same.
>

Re: Halting problem proofs refuted on the basis of software engineering

<bSBAK.186899$9j2.125246@fx33.iad>

 copy mid

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

 copy link   Newsgroups: 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!fx33.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 88
Message-ID: <bSBAK.186899$9j2.125246@fx33.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 16 Jul 2022 12:40:37 -0400
X-Received-Bytes: 5583
 by: Richard Damon - Sat, 16 Jul 2022 16:40 UTC

On 7/16/22 11:54 AM, Mike Terry wrote:
> On 16/07/2022 12:23, Paul N wrote:
>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>> Do you accept that if H were required to report on the behaviour
>>>>>> of the direct execution of P(P) then it would not be possible to
>>>>>> write such an H?
>>>>> That would require H to be a mind reader and report on something other
>>>>> than the actual behavior of its actual input.
>>>>
>>>> There's no mind involved. If P is a computer program then P(P) is
>>>> perfectly well defined. Either H can work out what it will do, or it
>>>> can't.
>>
>> You haven't said in what way a "mind" is involved in the direct
>> execution of P(P).
>>
>>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>> is {a half gallon of grape juice}. When she gets back with the eggs you
>>> ask her where is the grape juice?
>>
>> No, you are the one who is twisting the meaning of words. When I talk
>> about the actual behaviour of P(P) I mean what actually happens when
>> P(P) is executed. That's what the words "actual" and "behaviour" mean.
>>
>> You are using the words "actual behavior" to mean something else which
>> is clearly different. It seems to relate to some sort of simulator,
>> which you simultaneously claim to be correct while acknowledging it
>> produces different results from executing P(P) directly.
>>
>> Can you tell us if that "actual behavior" does actually happen in any
>> circumstances, or is it (despite the name) just a theoretical thing?
>>
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> Yes, where the actual behaviour is the behaviour that actually happens.
>>
>>> It is common knowledge that a correct simulation of a program is a
>>> correct measure of the behavior of this program.
>>
>> Yes, if the simulation is correct. You've insisted numerous times that
>> your own simulator is incorrect.
>
> PO's simulation is correct at the individual instruction level.  His H
> steps the simulation forward a number of steps, and each of those steps
> exactly matches the P(P) calculation steps.  At some point before the
> final P RET instruction, his H decides to stop stepping (for whatever
> reason), so H's simulation is *incomplete*.
>
> That is the only sense in which P(P) and "the simulated input to H(P,P)"
> differ - H simply stops simulating before P(P) terminates.

But "incomplete" is incorrect if your logic assumes that the simulation
not reaching the final state PROVES non-halting. "Simulation" as a word
by itself implies complete and correct, and "Correct Simulation" implies
Complete in normal English usage.

Yes, to be very precise we could everywhere say complete and correct
simulation, but that gets wordy.

The key point is that H stops its simulating, AND THEN PRESUMES that
this simulation, if continued correctly, would never halt.

Yes, if H itself was programmed to do that, it would never halt, but
since this H is actually programmed to abort, a COMPLETE AND CORRECT
simulation of the input (by something else) would see that happening and
P halting.

Peter confuses the hypothetical H that isn't the actual H we are dealing
with and the one that is there.

>
>
> Mike.
>
>>
>>> If we accept that the behavior of the executed P(P) is the behavior that
>>> H must report on then we are saying that H must report on the behavior
>>> that is not the actual behavior of its actual input.
>>
>> No, the two things are the same.
>>

Re: Halting problem proofs refuted on the basis of software engineering

<pvCdne0WvNtHZU__nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.lang.c++ comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 16 Jul 2022 12:43:54 -0500
Date: Sat, 16 Jul 2022 12:43:54 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,comp.lang.c++,comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <pvCdne0WvNtHZU__nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 122
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-1TE3nY+SIi+RV2pLWoDYIxNsDusi7kzTicg9SC18aO2rZDbPUC4Hgkv/5GGlrv/gVKwhK8K+sLrkAON!xjrY3Rj/CIxrT/+h/SVNI6snVB5PxwLS9kM4jihlNJVUpqbooRT/l1HeYamQbqMiA3ehSiwqcZnH!Zw==
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: 6877
 by: olcott - Sat, 16 Jul 2022 17:43 UTC

On 7/16/2022 10:54 AM, Mike Terry wrote:
> On 16/07/2022 12:23, Paul N wrote:
>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>> Do you accept that if H were required to report on the behaviour
>>>>>> of the direct execution of P(P) then it would not be possible to
>>>>>> write such an H?
>>>>> That would require H to be a mind reader and report on something other
>>>>> than the actual behavior of its actual input.
>>>>
>>>> There's no mind involved. If P is a computer program then P(P) is
>>>> perfectly well defined. Either H can work out what it will do, or it
>>>> can't.
>>
>> You haven't said in what way a "mind" is involved in the direct
>> execution of P(P).
>>
>>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>> is {a half gallon of grape juice}. When she gets back with the eggs you
>>> ask her where is the grape juice?
>>
>> No, you are the one who is twisting the meaning of words. When I talk
>> about the actual behaviour of P(P) I mean what actually happens when
>> P(P) is executed. That's what the words "actual" and "behaviour" mean.
>>
>> You are using the words "actual behavior" to mean something else which
>> is clearly different. It seems to relate to some sort of simulator,
>> which you simultaneously claim to be correct while acknowledging it
>> produces different results from executing P(P) directly.
>>
>> Can you tell us if that "actual behavior" does actually happen in any
>> circumstances, or is it (despite the name) just a theoretical thing?
>>
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> Yes, where the actual behaviour is the behaviour that actually happens.
>>
>>> It is common knowledge that a correct simulation of a program is a
>>> correct measure of the behavior of this program.
>>
>> Yes, if the simulation is correct. You've insisted numerous times that
>> your own simulator is incorrect.
>
> PO's simulation is correct at the individual instruction level.  His H
> steps the simulation forward a number of steps, and each of those steps
> exactly matches the P(P) calculation steps.  At some point before the
> final P RET instruction, his H decides to stop stepping (for whatever
> reason), so H's simulation is *incomplete*.
>

The simulation that H(P,P) performs on its input is *incomplete* in the
same way that the simulation of H0(Infinite_Loop) is incomplete.

If H0 waited until the heat death of the universe before it aborted its
simulation this simulation would still be *incomplete*

*H0 correctly determines that Infinite_Loop() never halts*

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

*H0: Begin Simulation Execution Trace Stored at:211fac*
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001102][00211f9c][00211fa0] 55 push ebp
[00001103][00211f9c][00211fa0] 8bec mov ebp,esp
[00001105][00211f9c][00211fa0] ebfe jmp 00001105
[00001105][00211f9c][00211fa0] ebfe jmp 00001105
*H0: Infinite Loop Detected Simulation Stopped*

> That is the only sense in which P(P) and "the simulated input to H(P,P)"
> differ - H simply stops simulating before P(P) terminates.
>

If you carefully study the H(P,P) code you would see that the correct
simulation that H(P,P) performs on its input could never reach the
"return" instruction of P before the heat death of the universe.

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

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

>
> Mike.
>
>>
>>> If we accept that the behavior of the executed P(P) is the behavior that
>>> H must report on then we are saying that H must report on the behavior
>>> that is not the actual behavior of its actual input.
>>
>> No, the two things are the same.
>>

--
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: Halting problem proofs refuted on the basis of software engineering

<eZCAK.62650$%e2.26946@fx40.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.lang.c++ comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx40.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,comp.lang.c++,comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
<pvCdne0WvNtHZU__nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <pvCdne0WvNtHZU__nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 161
Message-ID: <eZCAK.62650$%e2.26946@fx40.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 16 Jul 2022 13:56:25 -0400
X-Received-Bytes: 8315
 by: Richard Damon - Sat, 16 Jul 2022 17:56 UTC

On 7/16/22 1:43 PM, olcott wrote:
> On 7/16/2022 10:54 AM, Mike Terry wrote:
>> On 16/07/2022 12:23, Paul N wrote:
>>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>>> Do you accept that if H were required to report on the behaviour
>>>>>>> of the direct execution of P(P) then it would not be possible to
>>>>>>> write such an H?
>>>>>> That would require H to be a mind reader and report on something
>>>>>> other
>>>>>> than the actual behavior of its actual input.
>>>>>
>>>>> There's no mind involved. If P is a computer program then P(P) is
>>>>> perfectly well defined. Either H can work out what it will do, or
>>>>> it can't.
>>>
>>> You haven't said in what way a "mind" is involved in the direct
>>> execution of P(P).
>>>
>>>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>>> is {a half gallon of grape juice}. When she gets back with the eggs you
>>>> ask her where is the grape juice?
>>>
>>> No, you are the one who is twisting the meaning of words. When I talk
>>> about the actual behaviour of P(P) I mean what actually happens when
>>> P(P) is executed. That's what the words "actual" and "behaviour" mean.
>>>
>>> You are using the words "actual behavior" to mean something else
>>> which is clearly different. It seems to relate to some sort of
>>> simulator, which you simultaneously claim to be correct while
>>> acknowledging it produces different results from executing P(P)
>>> directly.
>>>
>>> Can you tell us if that "actual behavior" does actually happen in any
>>> circumstances, or is it (despite the name) just a theoretical thing?
>>>
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>
>>> Yes, where the actual behaviour is the behaviour that actually happens.
>>>
>>>> It is common knowledge that a correct simulation of a program is a
>>>> correct measure of the behavior of this program.
>>>
>>> Yes, if the simulation is correct. You've insisted numerous times
>>> that your own simulator is incorrect.
>>
>> PO's simulation is correct at the individual instruction level.  His H
>> steps the simulation forward a number of steps, and each of those
>> steps exactly matches the P(P) calculation steps.  At some point
>> before the final P RET instruction, his H decides to stop stepping
>> (for whatever reason), so H's simulation is *incomplete*.
>>
>
> The simulation that H(P,P) performs on its input is *incomplete* in the
> same way that the simulation of H0(Infinite_Loop) is incomplete.

No because if you give that same input to a actual complete and accurate
simulator, Simulate(P,P) will halt, while Simulate(Infinite_Loop, 0)
will not.

The problems isn't per-se that H has an incomplete simulation, but that
it bases its answer on unsound rules that makes it THINK that a complete
simulation of the input (with THIS H in it) would never end.

You H is answer the wrong question, one based on a fantasy. It is
answering, If this Halt Decider wasn't a Halt Decider but an pure
simulator, (and any reference to it in the input program refered to that
version) would the input halt.

That ISN'T the question for a Halt Decider. The question is does the
input AS IT IS, Halt or not. Since H DOES abort its simulation of its
input for H(P,P) then the simulation of the input must consider that
behavior, or it isn't simulating the input correctly.

>
> If H0 waited until the heat death of the universe before it aborted its
> simulation this simulation would still be *incomplete*
>
> *H0 correctly determines that Infinite_Loop() never halts*
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01)  55         push ebp
> [00001103](02)  8bec       mov ebp,esp
> [00001105](02)  ebfe       jmp 00001105
> [00001107](01)  5d         pop ebp
> [00001108](01)  c3         ret
> Size in bytes:(0007) [00001108]
>
>
> *H0: Begin Simulation   Execution Trace Stored at:211fac*
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001102][00211f9c][00211fa0] 55         push ebp
> [00001103][00211f9c][00211fa0] 8bec       mov ebp,esp
> [00001105][00211f9c][00211fa0] ebfe       jmp 00001105
> [00001105][00211f9c][00211fa0] ebfe       jmp 00001105
> *H0: Infinite Loop Detected Simulation Stopped*
>
>> That is the only sense in which P(P) and "the simulated input to
>> H(P,P)" differ - H simply stops simulating before P(P) terminates.
>>
>
> If you carefully study the H(P,P) code you would see that the correct
> simulation that H(P,P) performs on its input could never reach the
> "return" instruction of P before the heat death of the universe.

But is that the H that you say is correct? If H doesn't abort is
simulation when called by P, it won't when called by main, so it will
fail to answer.

You problem is it seems you don't actually have *A* H that you are
looking at but keep on playing shell games.

That is one reason you can't publish your code, if you do you need to
actually define which one you are talking about.

The H that doesn't abort and creates a non-halting P(P) but is wrong
because it fails to answer, or

The H that DOES abort and createas a HALTING P(P) that it thinks in
non-halting because it uses bad logic/incorrect simulation to decide and
gives the wrong answer.

>
> *Halting problem proofs refuted on the basis of software engineering*
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>
>>
>> Mike.
>>
>>>
>>>> If we accept that the behavior of the executed P(P) is the behavior
>>>> that
>>>> H must report on then we are saying that H must report on the behavior
>>>> that is not the actual behavior of its actual input.
>>>
>>> No, the two things are the same.
>>>
>
>

Re: Halting problem proofs refuted on the basis of software engineering

<FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!rocksolid2!i2pn.org!aioe.org!news.uzoreto.com!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 16 Jul 2022 14:28:35 -0500
Subject: Re: Halting problem proofs refuted on the basis of software engineering
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com> <405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com> <H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com> <706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com> <YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com> <ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com> <A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com> <677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com> <BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com> <2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com> <Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com> <47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com> <QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com> <37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com> <gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk> <bSBAK.186899$9j2.125246@fx33.iad>
From: news.dea...@darjeeling.plus.com (Mike Terry)
Date: Sat, 16 Jul 2022 20:28:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.8
MIME-Version: 1.0
In-Reply-To: <bSBAK.186899$9j2.125246@fx33.iad>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>
Lines: 98
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MNBggT/ZMtu1ghVlEgtiIiuC3yTNK1e/LhROQczosjG4VH/QLEnBy/xgdya/7eJtRbpdqBav8qMODUv!trRb2IFfqcMjRpE8wyAFIvZsi9L0cQ+mA/3pumyGIYT0jSgJPx97ybPkfnnwWwcpX6sdgkU6u7vO!DR0/YxYW1w56bU1MZgiKii0gTbA=
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: 7738
 by: Mike Terry - Sat, 16 Jul 2022 19:28 UTC

On 16/07/2022 17:40, Richard Damon wrote:
> On 7/16/22 11:54 AM, Mike Terry wrote:
>> On 16/07/2022 12:23, Paul N wrote:
>>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>>> Do you accept that if H were required to report on the behaviour of the direct execution of
>>>>>>> P(P) then it would not be possible to write such an H?
>>>>>> That would require H to be a mind reader and report on something other
>>>>>> than the actual behavior of its actual input.
>>>>>
>>>>> There's no mind involved. If P is a computer program then P(P) is perfectly well defined.
>>>>> Either H can work out what it will do, or it can't.
>>>
>>> You haven't said in what way a "mind" is involved in the direct execution of P(P).
>>>
>>>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>>> is {a half gallon of grape juice}. When she gets back with the eggs you
>>>> ask her where is the grape juice?
>>>
>>> No, you are the one who is twisting the meaning of words. When I talk about the actual behaviour
>>> of P(P) I mean what actually happens when P(P) is executed. That's what the words "actual" and
>>> "behaviour" mean.
>>>
>>> You are using the words "actual behavior" to mean something else which is clearly different. It
>>> seems to relate to some sort of simulator, which you simultaneously claim to be correct while
>>> acknowledging it produces different results from executing P(P) directly.
>>>
>>> Can you tell us if that "actual behavior" does actually happen in any circumstances, or is it
>>> (despite the name) just a theoretical thing?
>>>
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>
>>> Yes, where the actual behaviour is the behaviour that actually happens.
>>>
>>>> It is common knowledge that a correct simulation of a program is a
>>>> correct measure of the behavior of this program.
>>>
>>> Yes, if the simulation is correct. You've insisted numerous times that your own simulator is
>>> incorrect.
>>
>> PO's simulation is correct at the individual instruction level.  His H steps the simulation
>> forward a number of steps, and each of those steps exactly matches the P(P) calculation steps.  At
>> some point before the final P RET instruction, his H decides to stop stepping (for whatever
>> reason), so H's simulation is *incomplete*.
>>
>> That is the only sense in which P(P) and "the simulated input to H(P,P)" differ - H simply stops
>> simulating before P(P) terminates.
>
> But "incomplete" is incorrect if your logic assumes that the simulation not reaching the final state
> PROVES non-halting.

I don't believe PO thinks that, irrespective of how badly he explains things. I think he believes
that the simulation would never halt *because his never-halting-abort test matched*, NOT simply as a
consequence of aborting. E.g. he seems to understand that a simulator that steps 10 steps then
stops regardless, does not imply that the simulated computation does not halt.

Although... he doesn't properly understand what halting means, and gets hopelessly confused by
various wordings, so discussing any of this with him is quite futile. Seriously - just don't bother!!

> "Simulation" as a word by itself implies complete and correct, and "Correct
> Simulation" implies Complete in normal English usage.

That's an opinion, and it's one way to go. To me "simulating" is an /activity/ that H performs - it
means calcultating succesive steps of a given computation. (Without implied /completeness/.)
>
> Yes, to be very precise we could everywhere say complete and correct simulation, but that gets wordy.

No need - everywhere in these threads where "H simulates..." is used, the meaning is nearly always
my interpretation, not yours. I don't agree yours is the default/correct interpretation - at least
it's not the useful one. In the event that you want to refer to a complete simulation, you can just
say "full simulation" or "complete simulation", but that IMO hardly ever arises. (Or we could make
the most common scenario more wordy, by always emphasising "partial simulation".) Anyway, this
seems to be a non-issue...

>
> The key point is that H stops its simulating, AND THEN PRESUMES that this simulation, if continued
> correctly, would never halt.

Yes, all the regulars here understand this mistake, if not it's origin. BUT THERE IS NO POINT
TRYING TO EXPLAIN THE PROBLEM TO PO - HE IS INTELLECTUALLY INCAPABLE OF FOLLOWING ABSTRACT REASONING
OR UNDERSTANDING THE REQUIRED CONCEPTS. Surely you must have come to this conclusion after all this
time?

You've said in the past that you agree you won't convince PO, but you post anyway to keep your mind
sharp. Well, I hesitate in bringing this up, but you're posting the same stuff over and over and
over again - the sort of behaviour that is sometimes observed in really old people! I don't believe
it is keeping your mind sharp - have you considered playing chess/bridge/go with other people?
Doing crosswords/sudoku/other logic puzzles? Reading a new book or learning a new topic? I wonder
whether those would be better for keeping your brain active! :) [A New Scientist article I read
some time ago talked of "social interaction" being the most important factor. Dunno...]

Mike.

Re: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend)

<cNqdndVCLrUNhk7_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.lang.c comp.lang.c++ sci.logic
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!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 16 Jul 2022 15:12:00 -0500
Date: Sat, 16 Jul 2022 15:12:00 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering (Mike fails to comprehend)
Content-Language: en-US
Newsgroups: comp.theory,comp.lang.c,comp.lang.c++,sci.logic
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
<bSBAK.186899$9j2.125246@fx33.iad>
<FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <cNqdndVCLrUNhk7_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 157
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-jccpVopy/SfL4iDK+C7PK+J3WQAM4FQy7WLBYVa6tC7xBCa5d06tT9edAsGaDyMG1vagZ9yZqHoIJdQ!ViS8F0SKE9eUOQOYjV9MqddjaqkdRcGUj5kAS5ph4xkTOV13+uk72S/ay02P+IgdBa28/Zc43Qx9!Xg==
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: 9084
X-Received-Bytes: 9175
 by: olcott - Sat, 16 Jul 2022 20:12 UTC

On 7/16/2022 2:28 PM, Mike Terry wrote:
> On 16/07/2022 17:40, Richard Damon wrote:
>> On 7/16/22 11:54 AM, Mike Terry wrote:
>>> On 16/07/2022 12:23, Paul N wrote:
>>>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>>>> Do you accept that if H were required to report on the behaviour
>>>>>>>> of the direct execution of P(P) then it would not be possible to
>>>>>>>> write such an H?
>>>>>>> That would require H to be a mind reader and report on something
>>>>>>> other
>>>>>>> than the actual behavior of its actual input.
>>>>>>
>>>>>> There's no mind involved. If P is a computer program then P(P) is
>>>>>> perfectly well defined. Either H can work out what it will do, or
>>>>>> it can't.
>>>>
>>>> You haven't said in what way a "mind" is involved in the direct
>>>> execution of P(P).
>>>>
>>>>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>>>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>>>> is {a half gallon of grape juice}. When she gets back with the eggs
>>>>> you
>>>>> ask her where is the grape juice?
>>>>
>>>> No, you are the one who is twisting the meaning of words. When I
>>>> talk about the actual behaviour of P(P) I mean what actually happens
>>>> when P(P) is executed. That's what the words "actual" and
>>>> "behaviour" mean.
>>>>
>>>> You are using the words "actual behavior" to mean something else
>>>> which is clearly different. It seems to relate to some sort of
>>>> simulator, which you simultaneously claim to be correct while
>>>> acknowledging it produces different results from executing P(P)
>>>> directly.
>>>>
>>>> Can you tell us if that "actual behavior" does actually happen in
>>>> any circumstances, or is it (despite the name) just a theoretical
>>>> thing?
>>>>
>>>>> A halt decider must compute the mapping from its inputs to an
>>>>> accept or
>>>>> reject state on the basis of the actual behavior that is actually
>>>>> specified by these inputs.
>>>>
>>>> Yes, where the actual behaviour is the behaviour that actually happens.
>>>>
>>>>> It is common knowledge that a correct simulation of a program is a
>>>>> correct measure of the behavior of this program.
>>>>
>>>> Yes, if the simulation is correct. You've insisted numerous times
>>>> that your own simulator is incorrect.
>>>
>>> PO's simulation is correct at the individual instruction level.  His
>>> H steps the simulation forward a number of steps, and each of those
>>> steps exactly matches the P(P) calculation steps.  At some point
>>> before the final P RET instruction, his H decides to stop stepping
>>> (for whatever reason), so H's simulation is *incomplete*.
>>>
>>> That is the only sense in which P(P) and "the simulated input to
>>> H(P,P)" differ - H simply stops simulating before P(P) terminates.
>>
>> But "incomplete" is incorrect if your logic assumes that the
>> simulation not reaching the final state PROVES non-halting.
>
> I don't believe PO thinks that, irrespective of how badly he explains
> things.  I think he believes that the simulation would never halt
> *because his never-halting-abort test matched*, NOT simply as a
> consequence of aborting.  E.g. he seems to understand that a simulator
> that steps 10 steps then stops regardless, does not imply that the
> simulated computation does not halt.
>
> Although... he doesn't properly understand what halting means, and gets
> hopelessly confused by various wordings, so discussing any of this with
> him is quite futile.  Seriously - just don't bother!!
>
>> "Simulation" as a word by itself implies complete and correct, and
>> "Correct Simulation" implies Complete in normal English usage.
>
> That's an opinion, and it's one way to go.  To me "simulating" is an
> /activity/ that H performs - it means calcultating succesive steps of a
> given computation.  (Without implied /completeness/.)
>>
>> Yes, to be very precise we could everywhere say complete and correct
>> simulation, but that gets wordy.
>
> No need - everywhere in these threads where "H simulates..." is used,
> the meaning is nearly always my interpretation, not yours.  I don't
> agree yours is the default/correct interpretation - at least it's not
> the useful one.  In the event that you want to refer to a complete
> simulation, you can just say "full simulation" or "complete simulation",
> but that IMO hardly ever arises.  (Or we could make the most common
> scenario more wordy, by always emphasising "partial simulation".)
> Anyway, this seems to be a non-issue...
>
>>
>> The key point is that H stops its simulating, AND THEN PRESUMES that
>> this simulation, if continued correctly, would never halt.
>
> Yes, all the regulars here understand this mistake, if not it's origin.
> BUT THERE IS NO POINT TRYING TO EXPLAIN THE PROBLEM TO PO - HE IS
> INTELLECTUALLY INCAPABLE OF FOLLOWING ABSTRACT REASONING OR
> UNDERSTANDING THE REQUIRED CONCEPTS.  Surely you must have come to this
> conclusion after all this time?
>

A computation is said to terminate normally when it completes all of its
steps by reaching its last instruction. It is shown below that P
essentially calls H in infinite recursion and is rejected by H as
non-halting on that basis.

*Mike doesn't seem to comprehend this*
*Mike doesn't seem to comprehend this*
*Mike doesn't seem to comprehend this*
*Mike doesn't seem to comprehend this*

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

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

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

When simulating halt decider H(P,P) simulates its input it can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P) that
could escape repeated simulations.

The above shows that the simulated P cannot possibly (reachs it “return”
instruction and) terminate normally. H(P,P) simulates its input then P
calls H(P,P) to simulate itself again. When H sees that this otherwise
infinitely nested simulation would never end it aborts its simulation of
P and rejects P as non-halting.

Halting problem proofs refuted on the basis of software engineering

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

--
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: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend)

<OCGAK.489158$ntj.396211@fx15.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering (Mike fails to comprehend)
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
<bSBAK.186899$9j2.125246@fx33.iad>
<FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>
<cNqdndVCLrUNhk7_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <cNqdndVCLrUNhk7_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 180
Message-ID: <OCGAK.489158$ntj.396211@fx15.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 16 Jul 2022 18:05:33 -0400
X-Received-Bytes: 9453
 by: Richard Damon - Sat, 16 Jul 2022 22:05 UTC

On 7/16/22 4:12 PM, olcott wrote:
> On 7/16/2022 2:28 PM, Mike Terry wrote:
>> On 16/07/2022 17:40, Richard Damon wrote:
>>> On 7/16/22 11:54 AM, Mike Terry wrote:
>>>> On 16/07/2022 12:23, Paul N wrote:
>>>>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>>>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>>>>> Do you accept that if H were required to report on the
>>>>>>>>> behaviour of the direct execution of P(P) then it would not be
>>>>>>>>> possible to write such an H?
>>>>>>>> That would require H to be a mind reader and report on something
>>>>>>>> other
>>>>>>>> than the actual behavior of its actual input.
>>>>>>>
>>>>>>> There's no mind involved. If P is a computer program then P(P) is
>>>>>>> perfectly well defined. Either H can work out what it will do, or
>>>>>>> it can't.
>>>>>
>>>>> You haven't said in what way a "mind" is involved in the direct
>>>>> execution of P(P).
>>>>>
>>>>>> It is like you ask your wife to go to the store and buy "a dozen
>>>>>> eggs"
>>>>>> fully expecting her to understand that what you mean by "a dozen
>>>>>> eggs"
>>>>>> is {a half gallon of grape juice}. When she gets back with the
>>>>>> eggs you
>>>>>> ask her where is the grape juice?
>>>>>
>>>>> No, you are the one who is twisting the meaning of words. When I
>>>>> talk about the actual behaviour of P(P) I mean what actually
>>>>> happens when P(P) is executed. That's what the words "actual" and
>>>>> "behaviour" mean.
>>>>>
>>>>> You are using the words "actual behavior" to mean something else
>>>>> which is clearly different. It seems to relate to some sort of
>>>>> simulator, which you simultaneously claim to be correct while
>>>>> acknowledging it produces different results from executing P(P)
>>>>> directly.
>>>>>
>>>>> Can you tell us if that "actual behavior" does actually happen in
>>>>> any circumstances, or is it (despite the name) just a theoretical
>>>>> thing?
>>>>>
>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>> accept or
>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>> specified by these inputs.
>>>>>
>>>>> Yes, where the actual behaviour is the behaviour that actually
>>>>> happens.
>>>>>
>>>>>> It is common knowledge that a correct simulation of a program is a
>>>>>> correct measure of the behavior of this program.
>>>>>
>>>>> Yes, if the simulation is correct. You've insisted numerous times
>>>>> that your own simulator is incorrect.
>>>>
>>>> PO's simulation is correct at the individual instruction level.  His
>>>> H steps the simulation forward a number of steps, and each of those
>>>> steps exactly matches the P(P) calculation steps.  At some point
>>>> before the final P RET instruction, his H decides to stop stepping
>>>> (for whatever reason), so H's simulation is *incomplete*.
>>>>
>>>> That is the only sense in which P(P) and "the simulated input to
>>>> H(P,P)" differ - H simply stops simulating before P(P) terminates.
>>>
>>> But "incomplete" is incorrect if your logic assumes that the
>>> simulation not reaching the final state PROVES non-halting.
>>
>> I don't believe PO thinks that, irrespective of how badly he explains
>> things.  I think he believes that the simulation would never halt
>> *because his never-halting-abort test matched*, NOT simply as a
>> consequence of aborting.  E.g. he seems to understand that a simulator
>> that steps 10 steps then stops regardless, does not imply that the
>> simulated computation does not halt.
>>
>> Although... he doesn't properly understand what halting means, and
>> gets hopelessly confused by various wordings, so discussing any of
>> this with him is quite futile.  Seriously - just don't bother!!
>>
>>> "Simulation" as a word by itself implies complete and correct, and
>>> "Correct Simulation" implies Complete in normal English usage.
>>
>> That's an opinion, and it's one way to go.  To me "simulating" is an
>> /activity/ that H performs - it means calcultating succesive steps of
>> a given computation.  (Without implied /completeness/.)
>>>
>>> Yes, to be very precise we could everywhere say complete and correct
>>> simulation, but that gets wordy.
>>
>> No need - everywhere in these threads where "H simulates..." is used,
>> the meaning is nearly always my interpretation, not yours.  I don't
>> agree yours is the default/correct interpretation - at least it's not
>> the useful one.  In the event that you want to refer to a complete
>> simulation, you can just say "full simulation" or "complete
>> simulation", but that IMO hardly ever arises.  (Or we could make the
>> most common scenario more wordy, by always emphasising "partial
>> simulation".) Anyway, this seems to be a non-issue...
>>
>>>
>>> The key point is that H stops its simulating, AND THEN PRESUMES that
>>> this simulation, if continued correctly, would never halt.
>>
>> Yes, all the regulars here understand this mistake, if not it's
>> origin. BUT THERE IS NO POINT TRYING TO EXPLAIN THE PROBLEM TO PO - HE
>> IS INTELLECTUALLY INCAPABLE OF FOLLOWING ABSTRACT REASONING OR
>> UNDERSTANDING THE REQUIRED CONCEPTS.  Surely you must have come to
>> this conclusion after all this time?
>>
>
> A computation is said to terminate normally when it completes all of its
> steps by reaching its last instruction. It is shown below that P
> essentially calls H in infinite recursion and is rejected by H as
> non-halting on that basis.

Except that it ISN'T infinite recursion if H has code that allows it to
stop its simulation

>
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*

OLCOTT doesn't understand this

Remember, if main calls H(P,P) and H(P,P) returns 0, then when P(P)
calls H(P,P) then H WILL Return 0 (or H is PROVED not to be the needed
pure function), and when H returns 0 to P, it will Halt.

If P(P) Halts, then H(P,P) returning 0 is NOT the correct answer.

>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> When simulating halt decider H(P,P) simulates its input it can see that:
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.

Your repeating this PROVES you are a pathological liar as this rule is
HOT true as you use it.

FAIL

>
> The above shows that the simulated P cannot possibly (reachs it “return”
> instruction and) terminate normally. H(P,P) simulates its input then P
> calls H(P,P) to simulate itself again. When H sees that this otherwise
> infinitely nested simulation would never end it aborts its simulation of
> P and rejects P as non-halting.
>

No, the above shows you do not understand how computers actually work.

> Halting problem proofs refuted on the basis of software engineering
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering (Mike fails to comprehend)

<tNGAK.84316$f81.52997@fx43.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx43.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering (Mike fails to comprehend)
Content-Language: en-US
Newsgroups: comp.theory
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
<bSBAK.186899$9j2.125246@fx33.iad>
<FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>
<cNqdndVCLrUNhk7_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <cNqdndVCLrUNhk7_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 204
Message-ID: <tNGAK.84316$f81.52997@fx43.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 16 Jul 2022 18:16:55 -0400
X-Received-Bytes: 10761
 by: Richard Damon - Sat, 16 Jul 2022 22:16 UTC

On 7/16/22 4:12 PM, olcott wrote:
> On 7/16/2022 2:28 PM, Mike Terry wrote:
>> On 16/07/2022 17:40, Richard Damon wrote:
>>> On 7/16/22 11:54 AM, Mike Terry wrote:
>>>> On 16/07/2022 12:23, Paul N wrote:
>>>>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>>>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>>>>> Do you accept that if H were required to report on the
>>>>>>>>> behaviour of the direct execution of P(P) then it would not be
>>>>>>>>> possible to write such an H?
>>>>>>>> That would require H to be a mind reader and report on something
>>>>>>>> other
>>>>>>>> than the actual behavior of its actual input.
>>>>>>>
>>>>>>> There's no mind involved. If P is a computer program then P(P) is
>>>>>>> perfectly well defined. Either H can work out what it will do, or
>>>>>>> it can't.
>>>>>
>>>>> You haven't said in what way a "mind" is involved in the direct
>>>>> execution of P(P).
>>>>>
>>>>>> It is like you ask your wife to go to the store and buy "a dozen
>>>>>> eggs"
>>>>>> fully expecting her to understand that what you mean by "a dozen
>>>>>> eggs"
>>>>>> is {a half gallon of grape juice}. When she gets back with the
>>>>>> eggs you
>>>>>> ask her where is the grape juice?
>>>>>
>>>>> No, you are the one who is twisting the meaning of words. When I
>>>>> talk about the actual behaviour of P(P) I mean what actually
>>>>> happens when P(P) is executed. That's what the words "actual" and
>>>>> "behaviour" mean.
>>>>>
>>>>> You are using the words "actual behavior" to mean something else
>>>>> which is clearly different. It seems to relate to some sort of
>>>>> simulator, which you simultaneously claim to be correct while
>>>>> acknowledging it produces different results from executing P(P)
>>>>> directly.
>>>>>
>>>>> Can you tell us if that "actual behavior" does actually happen in
>>>>> any circumstances, or is it (despite the name) just a theoretical
>>>>> thing?
>>>>>
>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>> accept or
>>>>>> reject state on the basis of the actual behavior that is actually
>>>>>> specified by these inputs.
>>>>>
>>>>> Yes, where the actual behaviour is the behaviour that actually
>>>>> happens.
>>>>>
>>>>>> It is common knowledge that a correct simulation of a program is a
>>>>>> correct measure of the behavior of this program.
>>>>>
>>>>> Yes, if the simulation is correct. You've insisted numerous times
>>>>> that your own simulator is incorrect.
>>>>
>>>> PO's simulation is correct at the individual instruction level.  His
>>>> H steps the simulation forward a number of steps, and each of those
>>>> steps exactly matches the P(P) calculation steps.  At some point
>>>> before the final P RET instruction, his H decides to stop stepping
>>>> (for whatever reason), so H's simulation is *incomplete*.
>>>>
>>>> That is the only sense in which P(P) and "the simulated input to
>>>> H(P,P)" differ - H simply stops simulating before P(P) terminates.
>>>
>>> But "incomplete" is incorrect if your logic assumes that the
>>> simulation not reaching the final state PROVES non-halting.
>>
>> I don't believe PO thinks that, irrespective of how badly he explains
>> things.  I think he believes that the simulation would never halt
>> *because his never-halting-abort test matched*, NOT simply as a
>> consequence of aborting.  E.g. he seems to understand that a simulator
>> that steps 10 steps then stops regardless, does not imply that the
>> simulated computation does not halt.
>>
>> Although... he doesn't properly understand what halting means, and
>> gets hopelessly confused by various wordings, so discussing any of
>> this with him is quite futile.  Seriously - just don't bother!!
>>
>>> "Simulation" as a word by itself implies complete and correct, and
>>> "Correct Simulation" implies Complete in normal English usage.
>>
>> That's an opinion, and it's one way to go.  To me "simulating" is an
>> /activity/ that H performs - it means calcultating succesive steps of
>> a given computation.  (Without implied /completeness/.)
>>>
>>> Yes, to be very precise we could everywhere say complete and correct
>>> simulation, but that gets wordy.
>>
>> No need - everywhere in these threads where "H simulates..." is used,
>> the meaning is nearly always my interpretation, not yours.  I don't
>> agree yours is the default/correct interpretation - at least it's not
>> the useful one.  In the event that you want to refer to a complete
>> simulation, you can just say "full simulation" or "complete
>> simulation", but that IMO hardly ever arises.  (Or we could make the
>> most common scenario more wordy, by always emphasising "partial
>> simulation".) Anyway, this seems to be a non-issue...
>>
>>>
>>> The key point is that H stops its simulating, AND THEN PRESUMES that
>>> this simulation, if continued correctly, would never halt.
>>
>> Yes, all the regulars here understand this mistake, if not it's
>> origin. BUT THERE IS NO POINT TRYING TO EXPLAIN THE PROBLEM TO PO - HE
>> IS INTELLECTUALLY INCAPABLE OF FOLLOWING ABSTRACT REASONING OR
>> UNDERSTANDING THE REQUIRED CONCEPTS.  Surely you must have come to
>> this conclusion after all this time?
>>
>
> A computation is said to terminate normally when it completes all of its
> steps by reaching its last instruction. It is shown below that P
> essentially calls H in infinite recursion and is rejected by H as
> non-halting on that basis.

Except that since H is shown to abort its simulation, there IS no
infinite recursion.

If when main calls H(P,P), then H(P,P) returns 0, and H actully IS a
pure function, than when P(P) calls H(P,P) we KNOW that H will decide to
abort it emulation (as soon as that emulation reaches the next call to
H(P,P), so the recursion depth is *1*, not infinite)
Since H(P,P) will then return 0 to P(P), we know that P(P) will halt and
thus be a halting computation. A computation that terminated normally by
reaching its last instruction (the simulation that was aborted is NOT
the computation we are looking at).

Since P(P) Halts when H(P,P) returns 0, that answer can NOT be the
correct answer.

If you want to go to your claim that the input H(P,P) doesn't actually
refer to P(P), then you need to deal with the fact that then you H isn't
defined right, as P is defined to ask H about itself with its input, and
it did that by calling H(P,P).

>
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*

OLCOTT DOESN'T UNABLE TO UNDERSTAND THIS.

>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> When simulating halt decider H(P,P) simulates its input it can see that:
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.

An incorrect rule as has been pointed out in the past, showing that you
seem unable to learn from your mistakes.

You are thus shown to be just talking fairy tales and you whole logic
built on incorrect rules and invalid.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering

<VOidnTs2WMbOyE7_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 16 Jul 2022 19:18:27 -0500
Date: Sat, 16 Jul 2022 19:18:26 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com> <405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com> <H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com> <706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com> <YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com> <ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com> <A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com> <677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com> <BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com> <2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com> <Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com> <47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com> <QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com> <37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com> <gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <VOidnTs2WMbOyE7_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 98
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ubcv31w+0GFdetGeQ+H5rg1bd6bhAlUk9e1Zl1lxjIOwgolmpXQO71+8aM9ZCLBbVsuciJflYKpYMuB!4+dl/B5TKdqCgwBCtLAQkrIHKCch9u9ahGnsMxczrv2kCy5YP2H+F+215zejA3+kSK9g2ryzXGtY!tQ==
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: 6036
X-Received-Bytes: 6178
 by: olcott - Sun, 17 Jul 2022 00:18 UTC

On 7/16/2022 10:54 AM, Mike Terry wrote:
> On 16/07/2022 12:23, Paul N wrote:
>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>> Do you accept that if H were required to report on the behaviour
>>>>>> of the direct execution of P(P) then it would not be possible to
>>>>>> write such an H?
>>>>> That would require H to be a mind reader and report on something other
>>>>> than the actual behavior of its actual input.
>>>>
>>>> There's no mind involved. If P is a computer program then P(P) is
>>>> perfectly well defined. Either H can work out what it will do, or it
>>>> can't.
>>
>> You haven't said in what way a "mind" is involved in the direct
>> execution of P(P).
>>
>>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>> is {a half gallon of grape juice}. When she gets back with the eggs you
>>> ask her where is the grape juice?
>>
>> No, you are the one who is twisting the meaning of words. When I talk
>> about the actual behaviour of P(P) I mean what actually happens when
>> P(P) is executed. That's what the words "actual" and "behaviour" mean.
>>
>> You are using the words "actual behavior" to mean something else which
>> is clearly different. It seems to relate to some sort of simulator,
>> which you simultaneously claim to be correct while acknowledging it
>> produces different results from executing P(P) directly.
>>
>> Can you tell us if that "actual behavior" does actually happen in any
>> circumstances, or is it (despite the name) just a theoretical thing?
>>
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> Yes, where the actual behaviour is the behaviour that actually happens.
>>
>>> It is common knowledge that a correct simulation of a program is a
>>> correct measure of the behavior of this program.
>>
>> Yes, if the simulation is correct. You've insisted numerous times that
>> your own simulator is incorrect.
>
> PO's simulation is correct at the individual instruction level.  His H
> steps the simulation forward a number of steps, and each of those steps
> exactly matches the P(P) calculation steps.  At some point before the
> final P RET instruction, his H decides to stop stepping (for whatever
> reason), so H's simulation is *incomplete*.
>

This review was very helpful thanks.

> That is the only sense in which P(P) and "the simulated input to H(P,P)"
> differ - H simply stops simulating before P(P) terminates.

*If you carefully examine this you will see that the simulated P cannot*
*possibly ever terminate normally by reaching its "return" instruction*

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

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

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

When simulating halt decider H(P,P) simulates its input it can see that:
(1) Function H() is called from P().
(2) With the same arguments to H().
(3) With no instructions in P preceding its invocation of H(P,P) that
could escape repeated simulations.

The above shows that the simulated P cannot possibly (reachs it “return”
instruction and) terminate normally. H(P,P) simulates its input then P
calls H(P,P) to simulate itself again. When H sees that this otherwise
infinitely nested simulation would never end it aborts its simulation of
P and rejects P as non-halting.

--
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: Halting problem proofs refuted on the basis of software engineering

<xSIAK.56979$sZ1.52752@fx07.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
<VOidnTs2WMbOyE7_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <VOidnTs2WMbOyE7_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 117
Message-ID: <xSIAK.56979$sZ1.52752@fx07.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 16 Jul 2022 20:38:51 -0400
X-Received-Bytes: 6554
 by: Richard Damon - Sun, 17 Jul 2022 00:38 UTC

On 7/16/22 8:18 PM, olcott wrote:
> On 7/16/2022 10:54 AM, Mike Terry wrote:
>> On 16/07/2022 12:23, Paul N wrote:
>>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>>> Do you accept that if H were required to report on the behaviour
>>>>>>> of the direct execution of P(P) then it would not be possible to
>>>>>>> write such an H?
>>>>>> That would require H to be a mind reader and report on something
>>>>>> other
>>>>>> than the actual behavior of its actual input.
>>>>>
>>>>> There's no mind involved. If P is a computer program then P(P) is
>>>>> perfectly well defined. Either H can work out what it will do, or
>>>>> it can't.
>>>
>>> You haven't said in what way a "mind" is involved in the direct
>>> execution of P(P).
>>>
>>>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>>> is {a half gallon of grape juice}. When she gets back with the eggs you
>>>> ask her where is the grape juice?
>>>
>>> No, you are the one who is twisting the meaning of words. When I talk
>>> about the actual behaviour of P(P) I mean what actually happens when
>>> P(P) is executed. That's what the words "actual" and "behaviour" mean.
>>>
>>> You are using the words "actual behavior" to mean something else
>>> which is clearly different. It seems to relate to some sort of
>>> simulator, which you simultaneously claim to be correct while
>>> acknowledging it produces different results from executing P(P)
>>> directly.
>>>
>>> Can you tell us if that "actual behavior" does actually happen in any
>>> circumstances, or is it (despite the name) just a theoretical thing?
>>>
>>>> A halt decider must compute the mapping from its inputs to an accept or
>>>> reject state on the basis of the actual behavior that is actually
>>>> specified by these inputs.
>>>
>>> Yes, where the actual behaviour is the behaviour that actually happens.
>>>
>>>> It is common knowledge that a correct simulation of a program is a
>>>> correct measure of the behavior of this program.
>>>
>>> Yes, if the simulation is correct. You've insisted numerous times
>>> that your own simulator is incorrect.
>>
>> PO's simulation is correct at the individual instruction level.  His H
>> steps the simulation forward a number of steps, and each of those
>> steps exactly matches the P(P) calculation steps.  At some point
>> before the final P RET instruction, his H decides to stop stepping
>> (for whatever reason), so H's simulation is *incomplete*.
>>
>
> This review was very helpful thanks.
>
>> That is the only sense in which P(P) and "the simulated input to
>> H(P,P)" differ - H simply stops simulating before P(P) terminates.
>
> *If you carefully examine this you will see that the simulated P cannot*
> *possibly ever terminate normally by reaching its "return" instruction*

Which just doesn't matter as Halting is defined based on the actual
machine and not a simulation.

Note, if H doesn't abort, it fails to be a decider.

If H does abort, it didn't completely and correctly simulate its input,
and a complete and correct simulation of the input WILL Halt.

We only care about the H that you actually are using, so if it aborts,
we need to look at the P that calls that same H that aborts, and since
that H doesn't complete its simulation, we need to test with the actual
machine or another simulator that actually does the complete and correct
simulation, and that one will show that P(P) halts if H(P,P) returns 0.

You basically are showing you don't understand basic requirements.

>
> typedef void (*ptr)();
> int H(ptr p, ptr i); // simulating halt decider
>
> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> When simulating halt decider H(P,P) simulates its input it can see that:
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.

(3) is just WRONG. FAIL. PROOF YOU ARE AN IDIOT.

>
> The above shows that the simulated P cannot possibly (reachs it “return”
> instruction and) terminate normally. H(P,P) simulates its input then P
> calls H(P,P) to simulate itself again. When H sees that this otherwise
> infinitely nested simulation would never end it aborts its simulation of
> P and rejects P as non-halting.
>
>

Re: Halting problem proofs refuted on the basis of software engineering

<bPGdnapT0ME5_k7_nZ2dnUU7_81j4p2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Followup: comp.lang.c,comp.lang.c++
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 16 Jul 2022 20:19:32 -0500
Date: Sat, 16 Jul 2022 20:19:31 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
<VOidnTs2WMbOyE7_nZ2dnUU7_83NnZ2d@giganews.com>
<xSIAK.56979$sZ1.52752@fx07.iad>
Followup-To: comp.lang.c,comp.lang.c++
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <xSIAK.56979$sZ1.52752@fx07.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <bPGdnapT0ME5_k7_nZ2dnUU7_81j4p2d@giganews.com>
Lines: 83
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FCmoKN51xx2yf/bKD4OVzMjPWrPGYpp4n6OwShnI1EQe8U4VZZSjdfU97ivibGM3nebBbwk1Ep5d+DC!/OTTgUhgRsiGMqIchOJVJaQ5edvoVpKs1ylhTfWOXRcURs0oARWdewISjn3HNci6aSIyFN588xvq!CA==
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: 5727
 by: olcott - Sun, 17 Jul 2022 01:19 UTC

On 7/16/2022 7:38 PM, Richard Damon wrote:
> On 7/16/22 8:18 PM, olcott wrote:
>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>> On 16/07/2022 12:23, Paul N wrote:
>>>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>>>> On 7/15/2022 11:17 AM, Paul N wrote:
>>>>>> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>>>>>>> On 7/15/2022 7:34 AM, Paul N wrote:
>>>>>>>> Do you accept that if H were required to report on the behaviour
>>>>>>>> of the direct execution of P(P) then it would not be possible to
>>>>>>>> write such an H?
>>>>>>> That would require H to be a mind reader and report on something
>>>>>>> other
>>>>>>> than the actual behavior of its actual input.
>>>>>>
>>>>>> There's no mind involved. If P is a computer program then P(P) is
>>>>>> perfectly well defined. Either H can work out what it will do, or
>>>>>> it can't.
>>>>
>>>> You haven't said in what way a "mind" is involved in the direct
>>>> execution of P(P).
>>>>
>>>>> It is like you ask your wife to go to the store and buy "a dozen eggs"
>>>>> fully expecting her to understand that what you mean by "a dozen eggs"
>>>>> is {a half gallon of grape juice}. When she gets back with the eggs
>>>>> you
>>>>> ask her where is the grape juice?
>>>>
>>>> No, you are the one who is twisting the meaning of words. When I
>>>> talk about the actual behaviour of P(P) I mean what actually happens
>>>> when P(P) is executed. That's what the words "actual" and
>>>> "behaviour" mean.
>>>>
>>>> You are using the words "actual behavior" to mean something else
>>>> which is clearly different. It seems to relate to some sort of
>>>> simulator, which you simultaneously claim to be correct while
>>>> acknowledging it produces different results from executing P(P)
>>>> directly.
>>>>
>>>> Can you tell us if that "actual behavior" does actually happen in
>>>> any circumstances, or is it (despite the name) just a theoretical
>>>> thing?
>>>>
>>>>> A halt decider must compute the mapping from its inputs to an
>>>>> accept or
>>>>> reject state on the basis of the actual behavior that is actually
>>>>> specified by these inputs.
>>>>
>>>> Yes, where the actual behaviour is the behaviour that actually happens.
>>>>
>>>>> It is common knowledge that a correct simulation of a program is a
>>>>> correct measure of the behavior of this program.
>>>>
>>>> Yes, if the simulation is correct. You've insisted numerous times
>>>> that your own simulator is incorrect.
>>>
>>> PO's simulation is correct at the individual instruction level.  His
>>> H steps the simulation forward a number of steps, and each of those
>>> steps exactly matches the P(P) calculation steps.  At some point
>>> before the final P RET instruction, his H decides to stop stepping
>>> (for whatever reason), so H's simulation is *incomplete*.
>>>
>>
>> This review was very helpful thanks.
>>
>>> That is the only sense in which P(P) and "the simulated input to
>>> H(P,P)" differ - H simply stops simulating before P(P) terminates.
>>
>> *If you carefully examine this you will see that the simulated P cannot*
>> *possibly ever terminate normally by reaching its "return" instruction*
>
>
> Which just doesn't matter as Halting is defined based on the actual
> machine and not a simulation.
>
Then the whole idea of a UTM would be totally bogus.

--
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: Halting problem proofs refuted on the basis of software engineering [thanks Mike]

<tavsrr$3jrqq$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,sci.math
Subject: Re: Halting problem proofs refuted on the basis of software
engineering [thanks Mike]
Date: Sat, 16 Jul 2022 21:40:57 -0500
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <tavsrr$3jrqq$1@dont-email.me>
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 17 Jul 2022 02:40:59 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d677a37bbaf7d3a192336cf8757f3ffc";
logging-data="3796826"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1foF+p/eeTO84VwPBrasP"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Cancel-Lock: sha1:lvO4V7BDLG3y2mfcWKgZrTmcWdM=
Content-Language: en-US
In-Reply-To: <gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
 by: olcott - Sun, 17 Jul 2022 02:40 UTC

On 7/16/2022 10:54 AM, Mike Terry wrote:
> On 16/07/2022 12:23, Paul N wrote:
>> Yes, if the simulation is correct. You've insisted numerous times that
>> your own simulator is incorrect.
>
> PO's simulation is correct at the individual instruction level.  His H
> steps the simulation forward a number of steps, and each of those steps
> exactly matches the P(P) calculation steps.

Thanks again for this Mike, this is very helpful.

--
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: Halting problem proofs refuted on the basis of software engineering [thanks Mike]

<eeSdney2L8qt3Un_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 17 Jul 2022 12:00:32 -0500
Date: Sun, 17 Jul 2022 12:00:32 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering [thanks Mike]
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
<bSBAK.186899$9j2.125246@fx33.iad>
<FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <eeSdney2L8qt3Un_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 31
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ttS3SS4IFDIVsKN8K8eHAvZ2mlVKB+MfED7cSPlenawYGe0b4TDaXZqYOrgT0TTvm2C5m/YhGFblL2F!ES5yM3ObQiBb0rjdA/W8Dpe0n7EjfxzuwBn6r2U5bdmmrWAfBltbgpOuT8mxzqeTbFGzUC/ZB34u!xQ==
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: 3439
X-Received-Bytes: 3561
 by: olcott - Sun, 17 Jul 2022 17:00 UTC

On 7/16/2022 2:28 PM, Mike Terry wrote:
> On 16/07/2022 17:40, Richard Damon wrote:
>> But "incomplete" is incorrect if your logic assumes that the
>> simulation not reaching the final state PROVES non-halting.
>
> I don't believe PO thinks that, irrespective of how badly he explains
> things.  I think he believes that the simulation would never halt
> *because his never-halting-abort test matched*, NOT simply as a
> consequence of aborting.  E.g. he seems to understand that a simulator
> that steps 10 steps then stops regardless, does not imply that the
> simulated computation does not halt.
>
> Although... he doesn't properly understand what halting means,

Halting means terminating normally by reaching the last "return"
instruction of the C function the last "ret" instruction of the x86
translation of this "C" function or the final state of a Turing machine.

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

--
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: Halting problem proofs refuted on the basis of software engineering [thanks Mike]

<tkXAK.153219$eQ5.91813@fx08.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math comp.software-eng
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx08.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering [thanks Mike]
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math,comp.software-eng
References: <EPWdnbcVB5MW-F3_nZ2dnUU7_83NnZ2d@giganews.com>
<405eb97d-b657-4090-b17d-459e64617010n@googlegroups.com>
<H_ydndfeFPdwpVP_nZ2dnUU7_83NnZ2d@giganews.com>
<706ee73d-22f4-412c-bba5-32aa77409858n@googlegroups.com>
<YKCdnbWsdrhAcFP_nZ2dnUU7_8zNnZ2d@giganews.com>
<ef5fdbbb-a19f-47f5-b2f6-bb9253000d8fn@googlegroups.com>
<A8CdnSusUaJ_g1L_nZ2dnUU7_8zNnZ2d@giganews.com>
<677b9171-b785-4c61-8d7c-1ad0e5aab634n@googlegroups.com>
<BY2dnctqJflD6U3_nZ2dnUU7_8zNnZ2d@giganews.com>
<2c68fba2-c0c4-41e9-bf67-b5c64eebfb95n@googlegroups.com>
<Z-Cdnesq2--h5kz_nZ2dnUU7_8zNnZ2d@giganews.com>
<47dc4226-b73d-42cd-81aa-7b31b554ef5an@googlegroups.com>
<QvednSpQ2vbfCEz_nZ2dnUU7_83NnZ2d@giganews.com>
<37ffd9c1-9751-4ed4-a036-0a83bb02783dn@googlegroups.com>
<gMudnZK_8_u5Qk__nZ2dnUU7-SfNnZ2d@brightview.co.uk>
<bSBAK.186899$9j2.125246@fx33.iad>
<FPednY0U5a_-jE7_nZ2dnUU7-WXNnZ2d@brightview.co.uk>
<eeSdney2L8qt3Un_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <eeSdney2L8qt3Un_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 41
Message-ID: <tkXAK.153219$eQ5.91813@fx08.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 17 Jul 2022 13:06:33 -0400
X-Received-Bytes: 3689
 by: Richard Damon - Sun, 17 Jul 2022 17:06 UTC

On 7/17/22 1:00 PM, olcott wrote:
> On 7/16/2022 2:28 PM, Mike Terry wrote:
>> On 16/07/2022 17:40, Richard Damon wrote:
>>> But "incomplete" is incorrect if your logic assumes that the
>>> simulation not reaching the final state PROVES non-halting.
>>
>> I don't believe PO thinks that, irrespective of how badly he explains
>> things.  I think he believes that the simulation would never halt
>> *because his never-halting-abort test matched*, NOT simply as a
>> consequence of aborting.  E.g. he seems to understand that a simulator
>> that steps 10 steps then stops regardless, does not imply that the
>> simulated computation does not halt.
>>
>> Although... he doesn't properly understand what halting means,
>
> Halting means terminating normally by reaching the last "return"
> instruction of the C function the last "ret" instruction of the x86
> translation of this "C" function or the final state of a Turing machine.
>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
>

Then why isn't the fact that P(P) will reach that when H(P,P) returns 0
and indication that H(P,P) returning 0 is wrong?

Remember, P calls H(P,P) to specifically ask it about P(P), so if that
means something else, you have not defined your machines correctly, and
are thus also WRONG.

A *Correct* simulation is a simulation that matches the behavior of the
thing it is simulating, so a simulation that shows that P(P) doesn't
halt can't be correct.

We also only talk about the program that IS THERE, not other
hypothetical programs, like the H that doesn't do the abort, as that
isn't the program we are looking at.

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor