On 6/14/2022 5:03 AM, Malcolm McLean wrote:
> On Tuesday, 14 June 2022 at 06:04:37 UTC+1, olcott wrote:
>> On 6/13/2022 11:59 PM, André G. Isaak wrote:
>>> On 2022-06-13 21:50, olcott wrote:
>>>> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>>>>> On 2022-06-13 11:51, olcott wrote:
>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>
>>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>>>> machine address) is able to look though the prior execution trace and
>>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>>> with and there are no instructions in P that would break this cycle.
>>>>>>> Naive.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>> another forum, thus saying that it is simply Naive carries zero weight.
>>>>>
>>>>> And which forum would that be?
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> That is irrelevant.
>>>
>>> It's certainly relevant to anyone interested in reading those reviews.
>>>
>>> André
>>>
>>>
>> I do appreciate that you are reviewing my work.
>> So you don't feel technically qualified to assess the merits of this
>> directly yourself? The impossibility of finding a valid counter-example
>> disproving the claim counts as proof that the claim is true.
>>
> We're dealing with our hands tied behind our backs, because we can't see H.

The above criterion applies to the universal set of all C functions, you
can't see them either. What you and others can do it find that there is
no exception to the above rule.

> I and other people have suggested an explanation for the results that you
> are seeing. But it can only be a shrewd guess. The behaviour of the program
> depends on how the emulator H is written. If it is in fact an emulator - some
> posters have disputed that. I doubt that they are right and that H is, as you
> describe it, an emulator. But it's impossible to actually prove these people
> wrong.

It is fully operational code, yet this does not matter.
Because the execution traces are provably correct it does not matter if
I hand-coded them or that they were generated by an emulator, H(P,P)==0
in either case.

I will be able to publish the code.
Until I figured out how to make H a pure function of its inputs I knew
that it would have been rejected. This doesn't change the fact that
H(P,P)==0 is correct.

comp.lang.c++
On 6/14/2022 6:47 AM, Paul N wrote:
> Yes, it is clear to us humans watching it that the
> program is repeating itself. Thus we can appreciate
> that it will never reach the final "ret" - indeed,
> it won't even get to the infinite loop identified above.

10 pages of code for H, H0, H1, H2 and their inputs.
50 pages of code for the x86utm operating system.
Hundreds of pages of code for the open source x86 emulator.

I just rewrote the paper yesterday and added an Appendix I

This explains the details of why the requirement for H decide the halt
status of P(P) is simply based on the false assumption that the behavior
of the correct emulation of the input to H(P,P) and P(P) is the same.

I also provide the provably correct execution traces of each proving
that their behavior is not the same.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

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

On 6/14/2022 6:14 AM, Richard Damon wrote:
> On 6/13/22 11:50 PM, olcott wrote:
>> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>>> On 2022-06-13 11:51, olcott wrote:
>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>> machine address) is able to look though the prior execution trace and
>>>>>> see that P is calling H with the same arguments that it was called
>>>>>> with and there are no instructions in P that would break this cycle.
>>>>> Naive.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> The last paragraph has been extensively reviewed and validated on
>>>> another forum, thus saying that it is simply Naive carries zero weight.
>>>
>>> And which forum would that be?
>>>
>>> André
>>>
>>>
>>
>> That is irrelevant. You should know that Validity supersedes
>> credibility. Do you believe (like 40% of the electorate) that the
>> consensus of fools correctly determines the truth?
>>
>
> Yes, and since you have none of the later, verification of validity is
> important.
>
> You SAYING you have reviewed it elsewhere means absolutely nothing, but
> if you have, then saying where should be easy and simple. If you
> actually haven't, your lie gets revealed.
>
> YOU of course know the answer for certain if you have done this.
>
> If you have, why hide the proof and add fuel to the, thus false, claims
> that you are lying about this. If you haven't, you need to ask yourself
> why did you lie about it?

If you can find an a valid counter example where my criteria does not
work then you have refuted it. If you have not found such a
counter-example then you have not refuted it. Everything else is merely
dishonest dodge to avoid the actual point.

--
Copyright 2022 Pete Olcott

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

On 6/14/2022 6:45 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> We're dealing with our hands tied behind our backs, because we can't
>> see H.
>

I am glad that you are still reviewing my work.

> That's only partly true. A sketch of H was posted and we know that that
> was wrong. And we know that H is wrong by definition because H(X,Y)
> does not report on the "halting" of X(Y). There are other detailed
> errors we can't critique without the actual H, but do you really care
> about those details?
>

I now have a brand new Appendix I that deals with this.
(1) Prior to my work
(a) No one ever fully investigated applying a simulating
halt decider to the halting problem's pathological inputs.

(b) Because of (a) no one was aware that the behavior of
the direct execution of P(P) could possibly be different
than the correct simulation of the input to H(P,P).

This only occurs when a simulating halt decider correctly
simulates pathological inputs: no one ever looked at this.

(2) I conclusively prove that these behaviors are different on the basis
of the *provably correct execution trace* of each. You must know the x86
language to follow this trace.

(3) Because textbook authors have never fully considered the idea of a
simulating halt decider they had no idea that the direct execution of
P(P) could possibly have different behavior than the correct simulation
of the input to H(P,P). Because of this they referred to the direct
execution of P(P) as the only criterion measure that they were aware of.

(4) All deciders including halt deciders must compute the mapping from
their inputs to and accept or reject state. It is self-evident that this
mapping must be on the basis of the actual behavior that is actually
specified by these inputs.

Therefore textbook authors specified an incorrect criterion measure
based on the false assumption that the behavior of the correctly
simulated input to H(P,P) must be the same as the behavior of the of the
direct execution of P(P).

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

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

On 6/14/22 11:00 AM, olcott wrote:
> On 6/14/2022 6:14 AM, Richard Damon wrote:
>> On 6/13/22 11:50 PM, olcott wrote:
>>> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>>>> On 2022-06-13 11:51, olcott wrote:
>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>>> machine address) is able to look though the prior execution trace
>>>>>>> and
>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>> with and there are no instructions in P that would break this cycle.
>>>>>> Naive.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> The last paragraph has been extensively reviewed and validated on
>>>>> another forum, thus saying that it is simply Naive carries zero
>>>>> weight.
>>>>
>>>> And which forum would that be?
>>>>
>>>> André
>>>>
>>>>
>>>
>>> That is irrelevant. You should know that Validity supersedes
>>> credibility. Do you believe (like 40% of the electorate) that the
>>> consensus of fools correctly determines the truth?
>>>
>>
>> Yes, and since you have none of the later, verification of validity is
>> important.
>>
>> You SAYING you have reviewed it elsewhere means absolutely nothing,
>> but if you have, then saying where should be easy and simple. If you
>> actually haven't, your lie gets revealed.
>>
>> YOU of course know the answer for certain if you have done this.
>>
>> If you have, why hide the proof and add fuel to the, thus false,
>> claims that you are lying about this. If you haven't, you need to ask
>> yourself why did you lie about it?
>
> If you can find an a valid counter example where my criteria does not
> work then you have refuted it. If you have not found such a
> counter-example then you have not refuted it. Everything else is merely
> dishonest dodge to avoid the actual point.
>

P(P)

H(P,P) returns 0 (reject), but P(P) Halts.

Since H claims to be a Halt Decider, H needs to accept any Halting
Computation.

You claim that H(P,P) doesn't represent P(P) says that P was defined
wrong, as P (H^ in Linz) is supposed to ask H about the machine its
input represents applied to its input, which will be P applied to the
representation of P.

Thus, you have your counter example or proof that you have lied about it
being built to the specifiecation of Linz.

Remember, you don't get to change ANY of the definitions of the problem
and still be working on it.

So, YOU FAIL.

On 6/15/2022 5:05 AM, Malcolm McLean wrote:
> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> We're dealing with our hands tied behind our backs, because we can't
>>> see H.
>> That's only partly true. A sketch of H was posted and we know that that
>> was wrong. And we know that H is wrong by definition because H(X,Y)
>> does not report on the "halting" of X(Y). There are other detailed
>> errors we can't critique without the actual H, but do you really care
>> about those details?
>>
> The current claim is that the direct execution of P(P) has different
> behavior to the correct simulation of the input to H(P,P).
> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
> But that's not possible if H is hidden. PO seems to think that H doesn't
> matter because its behaviour can be inferred, but here he is wrong.
>

Its behavior is stipulated to only execute x86 emulation on its input
until a non-halting behavior pattern is recognized.
WHY IS IT SO IMPOSSIBLY DIFFICULT FOR YOU TO UNDERSTAND THIS?

Appendix I analyzes P(P) versus H(P,P)
Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

> As for should we simply dismiss what PO is saying, it's reasonable to
> do that to all people who claim to have "solved the halting problem" or
> otherwise refuted established results. It's even maybe reasonable to
> dismiss people who post on Usenet claiming to have solved long-
> standing open problems which aren't known to be insoluble. And that
> might be a kindness to the proposer in the long run. But that bridge has
> long since been crossed.

When my work is evaluated from a purely software engineering point of
view: It is very obviously correct that the input to H(P,P) does meet
this criteria, thus the complete x86 emulation of the input to H(P,P)
would never reach its "ret" instruction.

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

I finally had one reviewer that did not lie about this.
It took a dozen forums 100 reviewers one year and thousands of messages
to find one reviewer that did not lie about very obviously correct
software engineering.

It is almost like I claim that 2 + 3 = 5 and most of the reviewers said
they simply don't believe in numbers and the rest said that even if
numbers do exist they could not be added together.

#include <stdint.h>
#define u32 uint32_t

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

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

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

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

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

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

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

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

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

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

--

--
Copyright 2022 Pete Olcott

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

On 6/15/22 6:30 AM, olcott wrote:
> On 6/15/2022 5:05 AM, Malcolm McLean wrote:
>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> We're dealing with our hands tied behind our backs, because we can't
>>>> see H.
>>> That's only partly true. A sketch of H was posted and we know that that
>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>> does not report on the "halting" of X(Y). There are other detailed
>>> errors we can't critique without the actual H, but do you really care
>>> about those details?
>>>
>> The current claim is that the direct execution of P(P) has different
>> behavior to the correct simulation of the input to H(P,P).
>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>> But that's not possible if H is hidden. PO seems to think that H doesn't
>> matter because its behaviour can be inferred, but here he is wrong.
>>
>
> Its behavior is stipulated to only execute x86 emulation on its input
> until a non-halting behavior pattern is recognized.
> WHY IS IT SO IMPOSSIBLY DIFFICULT FOR YOU TO UNDERSTAND THIS?

And what pattern are you useing that is an actual non-halting pattern?

That P(P) calls H(P,P) is not sufficient as has been proved.

If it waits until it finds an ACTUAL non-halting pattern, then it is
shown that H(P,P) will NEVER abort and thus never answers.

>
> Appendix I analyzes P(P) versus H(P,P)
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
>> As for should we simply dismiss what PO is saying, it's reasonable to
>> do that to all people who claim to have "solved the halting problem" or
>> otherwise refuted established results. It's even maybe reasonable to
>> dismiss people who post on Usenet claiming to have solved long-
>> standing open problems which aren't known to be insoluble. And that
>> might be a kindness to the proposer in the long run. But that bridge has
>> long since been crossed.
>
> When my work is evaluated from a purely software engineering point of
> view: It is very obviously correct that the input to H(P,P) does meet
> this criteria, thus the complete x86 emulation of the input to H(P,P)
> would never reach its "ret" instruction.

Nope, not unless you are using software engineering definitions that do
not match the actual required definitions.

For instance, if H isn't required to be an actual Algorithm, but just
some function that passes information to other instances of itself, and
the system has a limitation that you can't actually copy the code of
some key part of it. But this means you fail to have something with a
Turing Machine equivalent.

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

If this doesn't match the behavior of the original machine with that
input, the criterion is invalid, or at least proves you aren't doing the
actual halting problem, so you proof means nothing.

If it does match, then the fact that P(P) Halts when H(P,P) returns 0
means that H(P,P) actually returning 0 is not correct.

>
> I finally had one reviewer that did not lie about this.
> It took a dozen forums 100 reviewers one year and thousands of messages
> to find one reviewer that did not lie about very obviously correct
> software engineering.

You want to provide some proof of this?

Also, finding one person who agrees with you isn't going to fix your
problem.

>
> It is almost like I claim that 2 + 3 = 5 and most of the reviewers said
> they simply don't believe in numbers and the rest said that even if
> numbers do exist they could not be added together.
>

Nope, you don't know what you are saying.

YOU are claiming that 2 + 3 = 6, and people are objecting that this
doesn't match the accepted theory, and you are saying well, it is if we
change addition into multiplication.

> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efeffff      call 000011a2 // call H
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>
> // H emulates the first seven instructions of P
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> // The emulated H emulates the first seven instructions of P
> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>
> ...[00001384][0010229e][00000000] 83c408     add esp,+08
> ...[00001387][0010229a][00000000] 50         push eax
> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
> "Input_Halts = "
> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
> Input_Halts = 0
> ...[00001392][0010229e][00000000] 83c408     add esp,+08
> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
> ...[00001397][001022a2][00100000] 5d         pop ebp
> ...[00001398][001022a6][00000004] c3         ret
> Number of Instructions Executed(15892) = 237 pages
>
>

On 6/15/2022 6:17 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> We're dealing with our hands tied behind our backs, because we can't
>>>> see H.
>>> That's only partly true. A sketch of H was posted and we know that that
>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>> does not report on the "halting" of X(Y). There are other detailed
>>> errors we can't critique without the actual H, but do you really care
>>> about those details?
>>>
>> The current claim is that the direct execution of P(P) has different
>> behavior to the correct simulation of the input to H(P,P).
>> This is pretty bizarre.
>
> PO has studiously avoided saying what the new mantra means.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

So when I say that the provably correct execution traces in Appendix I
show that P(P) halts and the correct and complete x86 emulation of the
input to H(P,P) never reaches the "ret" instruction of this input these
words are pure nonsense gibberish to you?

> That's
> deliberate. He knows full well that H(X,Y) should report on the
> behaviour of X(Y) but all of his previous wordings were just a little
> too clear. Things like "yes, but H_Hat(H_Hat) only halts because H
> stops it" and "H_Hat(H_Hat) would be non-terminating if line 15 were
> commented out".
>

I proved otherwise in my Appendix I

> Everything for the last couple of years has been a linguistic exercise,
> not a technical one. Sure, some technical-looking things have been
> posted like deliberately deceptive edited traces, but the gist of all

That is libelous.

> his posts has been to find some wording that can keep the discussion
> going. Once it was 100% clear that he is determined to assert that
> H(H_Hat,H_Hat) == 0 is correct even though H_Hat(H_Hat) "halts" the game
> was up, from a technical point of view.
>
>> The obvious way to answer it is to dry-run P(P).
>
> He posted a trace of P(P) halting. H (deliberately not traced) spots
> the magic pattern and returns 0 so P(P) halts.
>

If one simply assumes that H runs an x86 emulator on its input until H
correctly determines that its complete and correct simulation of its
input wold never stop running then one sees that the behavior of P is
consistent with this. It is quite ridiculous that this is too hard for you.

Here is a tutorial if you are utterly clueless about the x86 language.
https://www.cs.virginia.edu/~evans/cs216/guides/x86.html

>> But that's not possible if H is hidden. PO seems to think that H doesn't
>> matter because its behaviour can be inferred, but here he is wrong.
>

Even if H dances the Gig and runs a house of prostitution on the side we
can see on the basis of the behavior of P that H has performed a correct
x86 emulation on its input until this input matches a non-halting
behavior pattern.

> Surely you don't believe PO is being sincere about that? He know he
> can't post H. He knows he can't even post the trace of H's execution
> which is why the traces are edited. If H simply "didn't matter", why go
> to the bother of editing the traces?
>

I will be able to post the source-code relatively soon. The one thing
that was holding me back was transforming the algorithm that H uses to
decide the halt status for P into a pure function of its inputs.

If I claim that 2 + 3 = 5, it is easy to see that this is correct.
If there are sixty pages of code between each of the above five elements
then it takes a lot of work to see that I even said 2 + 3 = 5.

>> As for should we simply dismiss what PO is saying, it's reasonable to
>> do that to all people who claim to have "solved the halting problem" or
>> otherwise refuted established results. It's even maybe reasonable to
>> dismiss people who post on Usenet claiming to have solved long-
>> standing open problems which aren't known to be insoluble. And that
>> might be a kindness to the proposer in the long run. But that bridge has
>> long since been crossed.
>
> I of all people can't advocate for dismissing what he is saying since
> I've spent so long replying myself, and I've only stopped because he
> called me a sadistic liar and there are some things that are just beyond
> the pale for me.
>

I apologize for this. Because everyone was refusing to affirm that the
correct and complete x86 emulation of the input to H(P,P) never reached
the "ret" instruction of P and this is so very easy to confirm as a fact
it seemed reasonable to call everyone refusing to affirm this a liar.

When you finally said that you neither affirm nor deny this, then and
only then did I have proof that you are not a liar on this point.

It took one year, one hundred reviewers across dozens of forums and
thousands of messages before one reviewer provided a step-by-step
analysis of my code and affirmed:

On 6/14/2022 6:47 AM, Paul N wrote:
> Yes, it is clear to us humans watching
> it that the program is repeating itself.
> Thus we can appreciate that it will never
> reach the final "ret" - indeed, it won't
> even get to the infinite loop identified above.

> It seems to be that stating that H(P,P) == 0 is wrong because P(P) halts
> is all that needs to said. His reply, that P(P) is a non-input can be
> explained a few times, but exactly how H gets the wrong answer is not
> interesting to me.
>

I explain this in in my Appendix I, I won't go through it again here.

> I thought PO /might/ like to learn why his "P(P) is a non-input"
> argument is rubbish, but he fell at the very first hurdle in my proposed
> exercises. It's possible that he really can't write a parity checking

I got sick then my now homeless friend needed help getting a home.
I plan on getting back to that, yet not until I complete the changes to
H so that it can be published.

> Turing machine, but I think it's more likely that he could see what's
> coming so he sabotaged the "learning" with all that "got to write a TM
> interpreter of my own" nonsense. (Were did that go, I wonder?)
>

I was sick.

--
Copyright 2022 Pete Olcott

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

On 6/15/2022 9:03 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 6/15/22 7:17 AM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> <cut>
>>>> But that's not possible if H is hidden. PO seems to think that H doesn't
>>>> matter because its behaviour can be inferred, but here he is wrong.
>>>
>>> Surely you don't believe PO is being sincere about that? He know he
>>> can't post H. He knows he can't even post the trace of H's execution
>>> which is why the traces are edited. If H simply "didn't matter", why go
>>> to the bother of editing the traces?
> <cut>
>>> I thought PO /might/ like to learn why his "P(P) is a non-input"
>>> argument is rubbish, but he fell at the very first hurdle in my proposed
>>> exercises. It's possible that he really can't write a parity checking
>>> Turing machine, but I think it's more likely that he could see what's
>>> coming so he sabotaged the "learning" with all that "got to write a TM
>>> interpreter of my own" nonsense. (Were did that go, I wonder?)
>>
>> To be honest, it might not be "deliberate" in a conscious manner, but
>> is sub-conscious distracting him keeping him from seeing something
>> that he is unwilling to accept.
>>
>> Ultimately, his problem is a wrong definition of wher Truth comes
>> from. Natural Lanugage isn't a source of truth, and can't be, because
>> it is a human creation, not a "natural" one. Just like his Theology
>> seems to stem from reality coming out of the individual, he seems to
>> believe that people get to create their own Truth, which goes against
>> the accepted definitions.
>
> That's an interesting perspective. It seems impossible that anyone
> could sustain that view for long, but there's nowt so queer as folk.
>

The notion of truth can be easily formalized using a very simple system
that making the Tarski Undefinability theorem (that "proves" truth
cannot be formalized") seem quite ridiculous.

Here is the Tarski proof.
https://liarparadox.org/Tarski_275_276.pdf

Within correct reasoning (not quite the same thing as logic)
One can know that an expression of natural or formal language is true
one of two ways:

(1) It is stipulated to be true like Haskell Curry elementary theorems

Then the elementary statements which belong to T we shall
call the elementary theorems of T; we also say that these
elementary statements are true for T. Thus, given T, an
elementary theorem is an elementary statement which is true.
https://www.liarparadox.org/Haskell_Curry_45.pdf

It is by this exact same process that we know that a cat is
an animal and not an office building. Natural language has
its own set of elementary theorems.

(2) Expressions of language that are derived by applying truth
preserving operations to (1)

When we do this many undecidable problems cease to exist.
An expression of language that is true and unprovable cannot possibly
exist. It is either provable or untrue.

To the same extent that logic systems diverge from this framework they
diverge from correct reasoning. We have to go all the way back to the
syllogism to find a logic system that does not diverge from this framework.

--
Copyright 2022 Pete Olcott

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

On 6/15/22 11:21 AM, olcott wrote:
> On 6/15/2022 9:03 AM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 6/15/22 7:17 AM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> <cut>
>>>>> But that's not possible if H is hidden. PO seems to think that H
>>>>> doesn't
>>>>> matter because its behaviour can be inferred, but here he is wrong.
>>>>
>>>> Surely you don't believe PO is being sincere about that?  He know he
>>>> can't post H.  He knows he can't even post the trace of H's execution
>>>> which is why the traces are edited.  If H simply "didn't matter",
>>>> why go
>>>> to the bother of editing the traces?
>> <cut>
>>>> I thought PO /might/ like to learn why his "P(P) is a non-input"
>>>> argument is rubbish, but he fell at the very first hurdle in my
>>>> proposed
>>>> exercises.  It's possible that he really can't write a parity checking
>>>> Turing machine, but I think it's more likely that he could see what's
>>>> coming so he sabotaged the "learning" with all that "got to write a TM
>>>> interpreter of my own" nonsense.  (Were did that go, I wonder?)
>>>
>>> To be honest, it might not be "deliberate" in a conscious manner, but
>>> is sub-conscious distracting him keeping him from seeing something
>>> that he is unwilling to accept.
>>>
>>> Ultimately, his problem is a wrong definition of wher Truth comes
>>> from. Natural Lanugage isn't a source of truth, and can't be, because
>>> it is a human creation, not a "natural" one. Just like his Theology
>>> seems to stem from reality coming out of the individual, he seems to
>>> believe that people get to create their own Truth, which goes against
>>> the accepted definitions.
>>
>> That's an interesting perspective.  It seems impossible that anyone
>> could sustain that view for long, but there's nowt so queer as folk.
>>
>
> The notion of truth can be easily formalized using a very simple system
> that making the Tarski Undefinability theorem (that "proves" truth
> cannot be formalized") seem quite ridiculous.
>
> Here is the Tarski proof.
> https://liarparadox.org/Tarski_275_276.pdf
>
> Within correct reasoning (not quite the same thing as logic)
> One can know that an expression of natural or formal language is true
> one of two ways:
>
> (1) It is stipulated to be true like Haskell Curry elementary theorems
>
>    Then the elementary statements which belong to T we shall
>    call the elementary theorems of T; we also say that these
>    elementary statements are true for T. Thus, given T, an
>    elementary theorem is an elementary statement which is true.
>    https://www.liarparadox.org/Haskell_Curry_45.pdf
>
>    It is by this exact same process that we know that a cat is
>    an animal and not an office building. Natural language has
>    its own set of elementary theorems.
>
> (2) Expressions of language that are derived by applying truth
> preserving operations to (1)
>
> When we do this many undecidable problems cease to exist.
> An expression of language that is true and unprovable cannot possibly
> exist. It is either provable or untrue.
>
> To the same extent that logic systems diverge from this framework they
> diverge from correct reasoning. We have to go all the way back to the
> syllogism to find a logic system that does not diverge from this framework.
>

So, in essence, you are claiming that if you change the fundamental
definition of what is Truth in the formal system, you can prove your
statement?

You don't GET to change the definition, so I guess you are just
admitting that your "proof" doesn't apply.

Can you actually prove that your system using this definition is capable
of supporting the needed properties of the Natural Numbers, and still
stay consistent?

My guess is you don't even understand the question or how to go about it.

That is your flaw in the logic.

On 6/15/22 11:02 AM, olcott wrote:
> On 6/15/2022 6:17 AM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> We're dealing with our hands tied behind our backs, because we can't
>>>>> see H.
>>>> That's only partly true. A sketch of H was posted and we know that that
>>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>>> does not report on the "halting" of X(Y). There are other detailed
>>>> errors we can't critique without the actual H, but do you really care
>>>> about those details?
>>>>
>>> The current claim is that the direct execution of P(P) has different
>>> behavior to the correct simulation of the input to H(P,P).
>>> This is pretty bizarre.
>>
>> PO has studiously avoided saying what the new mantra means.
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
> So when I say that the provably correct execution traces in Appendix I
> show that P(P) halts and the correct and complete x86 emulation of the
> input to H(P,P) never reaches the "ret" instruction of this input these
> words are pure nonsense gibberish to you?

So, how do you resolve that the DEFINITION of the behavior of the input
to a Halt Decider IS the behavior of the program it represents, so the
behavior of the input to H(P,P) is BY DEFINITION the behavior of P(P).

All you seem to do is say that is can't be, which doesn't give you
licence to define something else, but you just need to admit that a
decider that meets the requirements can't ex

>
>> That's
>> deliberate.  He knows full well that H(X,Y) should report on the
>> behaviour of X(Y) but all of his previous wordings were just a little
>> too clear.  Things like "yes, but H_Hat(H_Hat) only halts because H
>> stops it" and "H_Hat(H_Hat) would be non-terminating if line 15 were
>> commented out".
>>
>
> I proved otherwise in my Appendix I

Proiving that you don't know the meaning of the word "REQUIREMENT"

Yes, if you want to claim that H is a correct POOP decider, go ahead, it
is just a Halt Decider it can't be because it doesn't meet the
requirements of one, and you aren't allowed to change them, NO MATTER WHAT.

>
>> Everything for the last couple of years has been a linguistic exercise,
>> not a technical one.  Sure, some technical-looking things have been
>> posted like deliberately deceptive edited traces, but the gist of all
>
> That is libelous.
>

It is True, which is a defense against libel.
] >> his posts has been to find some wording that can keep the discussion
>> going.  Once it was 100% clear that he is determined to assert that
>> H(H_Hat,H_Hat) == 0 is correct even though H_Hat(H_Hat) "halts" the game
>> was up, from a technical point of view.
>>
>>> The obvious way to answer it is to dry-run P(P).
>>
>> He posted a trace of P(P) halting.  H (deliberately not traced) spots
>> the magic pattern and returns 0 so P(P) halts.
>>
>
> If one simply assumes that H runs an x86 emulator on its input until H
> correctly determines that its complete and correct simulation of its
> input wold never stop running then one sees that the behavior of P is
> consistent with this. It is quite ridiculous that this is too hard for you.
>
> Here is a tutorial if you are utterly clueless about the x86 language.
> https://www.cs.virginia.edu/~evans/cs216/guides/x86.html

Yes, if you assume that H does something that is actually impossible,
you can "prove" that it gets the right answer, but that is an invalid
proof as it isn't based on actually True Premises.

The fact that it can be trivially proven WRONG should be a hint to you
that you logic is flawed.

>
>>> But that's not possible if H is hidden. PO seems to think that H doesn't
>>> matter because its behaviour can be inferred, but here he is wrong.
>>
>
> Even if H dances the Gig and runs a house of prostitution on the side we
> can see on the basis of the behavior of P that H has performed a correct
> x86 emulation on its input until this input matches a non-halting
> behavior pattern.
>

You need to decide which H is the H you are talking about, or your whole
logic if flawed.

Is H a program that DOES emulate its input correctly, which does cause
P(P) to be non-halting, but H can NEVER abort to say that (or it isn't
actually a correct emulation), or does H abort its emulation and thus
its answer needs to be tested by a seperate emulator that actually DOES
that correct emulation.

It can't be both and be a computation / pure function.

>> Surely you don't believe PO is being sincere about that?  He know he
>> can't post H.  He knows he can't even post the trace of H's execution
>> which is why the traces are edited.  If H simply "didn't matter", why go
>> to the bother of editing the traces?
>>
>
> I will be able to post the source-code relatively soon. The one thing
> that was holding me back was transforming the algorithm that H uses to
> decide the halt status for P into a pure function of its inputs.

I wait to see this. Remember also, Pure Functions can not call unPure
functions or they tend to loose their purity.

>
> If I claim that 2 + 3 = 5, it is easy to see that this is correct.
> If there are sixty pages of code between each of the above five elements
> then it takes a lot of work to see that I even said 2 + 3 = 5.
>
>>> As for should we simply dismiss what PO is saying, it's reasonable to
>>> do that to all people who claim to have "solved the halting problem" or
>>> otherwise refuted established results. It's even maybe reasonable to
>>> dismiss people who post on Usenet claiming to have solved long-
>>> standing open problems which aren't known to be insoluble. And that
>>> might be a kindness to the proposer in the long run. But that bridge has
>>> long since been crossed.
>>
>> I of all people can't advocate for dismissing what he is saying since
>> I've spent so long replying myself, and I've only stopped because he
>> called me a sadistic liar and there are some things that are just beyond
>> the pale for me.
>>
>
> I apologize for this. Because everyone was refusing to affirm that the
> correct and complete x86 emulation of the input to H(P,P) never reached
> the "ret" instruction of P and this is so very easy to confirm as a fact
> it seemed reasonable to call everyone refusing to affirm this a liar.

The issue is that you have TWO H's by the same name the you conflate.

The "Correct Emulation" H, does in fact, create a non-halting P and the
fact that this H can never reach the return instruction does prove this.
The problem is that proof is BASED on H having that property, so when
you look at your OTHER H, that decides to abort, you lose that property
for the P based on it.

>
> When you finally said that you neither affirm nor deny this, then and
> only then did I have proof that you are not a liar on this point.
>
> It took one year, one hundred reviewers across dozens of forums and
> thousands of messages before one reviewer provided a step-by-step
> analysis of my code and affirmed:
>
> On 6/14/2022 6:47 AM, Paul N wrote:
> > Yes, it is clear to us humans watching
> > it that the program is repeating itself.
> > Thus we can appreciate that it will never
> > reach the final "ret" - indeed, it won't
> > even get to the infinite loop identified above.

That has never been denied, and I have affermed that.

*IF* the program actually DOES continue to repeat itself, which means
that it NEVER aborts its simulation, that the input becomes non-halting.

Your problem is when you then CHANGE H to not do that, and actually does
the abort, then the basis of that proof disappears.

>
>> It seems to be that stating that H(P,P) == 0 is wrong because P(P) halts
>> is all that needs to said.  His reply, that P(P) is a non-input can be
>> explained a few times, but exactly how H gets the wrong answer is not
>> interesting to me.
>>
>
> I explain this in in my Appendix I, I won't go through it again here.
>
>> I thought PO /might/ like to learn why his "P(P) is a non-input"
>> argument is rubbish, but he fell at the very first hurdle in my proposed
>> exercises.  It's possible that he really can't write a parity checking
>
> I got sick then my now homeless friend needed help getting a home.
> I plan on getting back to that, yet not until I complete the changes to
> H so that it can be published.
>
>> Turing machine, but I think it's more likely that he could see what's
>> coming so he sabotaged the "learning" with all that "got to write a TM
>> interpreter of my own" nonsense.  (Were did that go, I wonder?)
>>
>
> I was sick.
>

On 6/15/2022 6:31 PM, Mike Terry wrote:
> On 15/06/2022 11:05, Malcolm McLean wrote:
>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> We're dealing with our hands tied behind our backs, because we can't
>>>> see H.
>>> That's only partly true. A sketch of H was posted and we know that that
>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>> does not report on the "halting" of X(Y). There are other detailed
>>> errors we can't critique without the actual H, but do you really care
>>> about those details?
>>>
>> The current claim is that the direct execution of P(P) has different
>> behavior to the correct simulation of the input to H(P,P).
>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>> But that's not possible if H is hidden. PO seems to think that H doesn't
>> matter because its behaviour can be inferred, but here he is wrong.
>>
> PO recently (yesterday?) posted one of his traces with P(P) halting.
>
> Inside that trace, we see P call H, and immediately after that in the
> trace we see NOT H trace entries (all suppressed), but the trace entries
> from "H simulating the input to H(P,P)" - i.e. exactly the trace entries
> PO claims are substantially different from the computation steps of P(P)
> [aka "running" P(P) directly].
>
> So, /are/ they substantially different?  NOT IN THE SLIGHTEST!  (As I've
> suggested a few times, but the evidence is there in PO's own post...)
>
> All we see is that H simulating P(P) calculates EXACTLY the same entries
> as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS SIMULATION.  Not
> one shred of any evidence of diversion!
>
> Of course, it's true we don't see the suppressed H entries, but I don't
> see any reason to think those would be any different if included.  PO is
> simply confused by his own code, and invents silly PSR explanations to
> try to justify it all to himself.  The explanation is obvious to anyone
> who's analysed - H mistakenly decides it sees non-halting behaviour and
> so stops simulating, whereas the computation itself (while containing
> the pattern H spotted - nobody denies that I think) proceeds further and
> after a short while halts.  (PO's rule is unsound, and why shouldn't it
> be - he's never felt the need to offer any /proof/ that it's sound.  He
> just really really really realy thinks it is!)
>

It is the case that the correct and complete x86 emulation of the input
to H(P,P) never reaches its "ret" instruction and on this basis it is
correct to say that it is non-halting.

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

> The most PO could come up with to explain this would be "ok, P(P) and
> H's simulation of the input to H(P,P) /are/ identical step for step as
> far as H simulates, so the difference in computation states /must/ occur
> in the computation steps that H never got to!".

I never say anything like that. It is ridiculously simple for any fully
competent software engineer to easily determine that

the correct and complete x86 emulation of the input to H(P,P) never
reaches its "ret" instruction.

>   That's Dumb, Dumb,
> Dumb thinking, but it wouldn't surprise me if that's what PO eventually
> comes up with... (He's not capable of thinking it through rationally.)
>
>
> Mike.
>
>> As for should we simply dismiss what PO is saying, it's reasonable to
>> do that to all people who claim to have "solved the halting problem" or
>> otherwise refuted established results. It's even maybe reasonable to
>> dismiss people who post on Usenet claiming to have solved long-
>> standing open problems which aren't known to be insoluble. And that
>> might be a kindness to the proposer in the long run. But that bridge has
>> long since been crossed.
>>
>

--
Copyright 2022 Pete Olcott

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

On 6/15/22 7:48 PM, olcott wrote:
> On 6/15/2022 6:31 PM, Mike Terry wrote:
>> On 15/06/2022 11:05, Malcolm McLean wrote:
>>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> We're dealing with our hands tied behind our backs, because we can't
>>>>> see H.
>>>> That's only partly true. A sketch of H was posted and we know that that
>>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>>> does not report on the "halting" of X(Y). There are other detailed
>>>> errors we can't critique without the actual H, but do you really care
>>>> about those details?
>>>>
>>> The current claim is that the direct execution of P(P) has different
>>> behavior to the correct simulation of the input to H(P,P).
>>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>>> But that's not possible if H is hidden. PO seems to think that H doesn't
>>> matter because its behaviour can be inferred, but here he is wrong.
>>>
>> PO recently (yesterday?) posted one of his traces with P(P) halting.
>>
>> Inside that trace, we see P call H, and immediately after that in the
>> trace we see NOT H trace entries (all suppressed), but the trace
>> entries from "H simulating the input to H(P,P)" - i.e. exactly the
>> trace entries PO claims are substantially different from the
>> computation steps of P(P) [aka "running" P(P) directly].
>>
>> So, /are/ they substantially different?  NOT IN THE SLIGHTEST!  (As
>> I've suggested a few times, but the evidence is there in PO's own
>> post...)
>>
>> All we see is that H simulating P(P) calculates EXACTLY the same
>> entries as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS
>> SIMULATION.  Not one shred of any evidence of diversion!
>>
>> Of course, it's true we don't see the suppressed H entries, but I
>> don't see any reason to think those would be any different if
>> included.  PO is simply confused by his own code, and invents silly
>> PSR explanations to try to justify it all to himself.  The explanation
>> is obvious to anyone who's analysed - H mistakenly decides it sees
>> non-halting behaviour and so stops simulating, whereas the computation
>> itself (while containing the pattern H spotted - nobody denies that I
>> think) proceeds further and after a short while halts.  (PO's rule is
>> unsound, and why shouldn't it be - he's never felt the need to offer
>> any /proof/ that it's sound.  He just really really really realy
>> thinks it is!)
>>
>
> It is the case that the correct and complete x86 emulation of the input
> to H(P,P) never reaches its "ret" instruction and on this basis it is
> correct to say that it is non-halting.

Except that it DOES if H(P,P) returns 0, as P(P) does, and the
DEFINITION of a correct emulation of a program is to have the same
behavior as the actual program it is emulating.

Thus since P(P) returns when H(P,P) returns 0, the input to H(P,P) in
this case also halts.

You try to claim differently, but that is just junk as it is the
DEFINITION. If H(P,P) isn't refering to P(P), then you have built P
incorrectly, as that is what the Linz "impossible" program is asking for.

If you want to claim it is impossible to ask for, then you H fails just
by that claim.

FAIL.

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

Right, THE TURING MACHINE. That is in this model P, with parameter P,
and it Halts if H(P,P) returned 0.

>
>> The most PO could come up with to explain this would be "ok, P(P) and
>> H's simulation of the input to H(P,P) /are/ identical step for step as
>> far as H simulates, so the difference in computation states /must/
>> occur in the computation steps that H never got to!".
>
> I never say anything like that. It is ridiculously simple for any fully
> competent software engineer to easily determine that
>
> the correct and complete x86 emulation of the input to H(P,P) never
> reaches its "ret" instruction.

Nope, it does if H(P,P) aborts its simulation (and thus H doesn't itself
do a correct and complete x86 emulation) and return 0.

You can't have H do BOTH a complete and correct emulation and return 0,

If H(P,P) aborts its simulation, we need to give that exact same input
to an actual correct emulator. Note, this means that P will still call
H, as that is part of the PROBRAM P, which seems to be one of your errors.

>
>>   That's Dumb, Dumb, Dumb thinking, but it wouldn't surprise me if
>> that's what PO eventually comes up with... (He's not capable of
>> thinking it through rationally.)
>>
>>
>> Mike.
>>
>>> As for should we simply dismiss what PO is saying, it's reasonable to
>>> do that to all people who claim to have "solved the halting problem" or
>>> otherwise refuted established results. It's even maybe reasonable to
>>> dismiss people who post on Usenet claiming to have solved long-
>>> standing open problems which aren't known to be insoluble. And that
>>> might be a kindness to the proposer in the long run. But that bridge has
>>> long since been crossed.
>>>
>>
>
>

On 6/14/2022 5:03 AM, Malcolm McLean wrote:
> On Tuesday, 14 June 2022 at 06:04:37 UTC+1, olcott wrote:
>> On 6/13/2022 11:59 PM, André G. Isaak wrote:
>>> On 2022-06-13 21:50, olcott wrote:
>>>> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>>>>> On 2022-06-13 11:51, olcott wrote:
>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>
>>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its own
>>>>>>>> machine address) is able to look though the prior execution trace and
>>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>>> with and there are no instructions in P that would break this cycle.
>>>>>>> Naive.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>> another forum, thus saying that it is simply Naive carries zero weight.
>>>>>
>>>>> And which forum would that be?
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> That is irrelevant.
>>>
>>> It's certainly relevant to anyone interested in reading those reviews.
>>>
>>> André
>>>
>>>
>> I do appreciate that you are reviewing my work.
>> So you don't feel technically qualified to assess the merits of this
>> directly yourself? The impossibility of finding a valid counter-example
>> disproving the claim counts as proof that the claim is true.
>>
> We're dealing with our hands tied behind our backs, because we can't see H.
> I and other people have suggested an explanation for the results that you
> are seeing. But it can only be a shrewd guess. The behaviour of the program
> depends on how the emulator H is written. If it is in fact an emulator - some
> posters have disputed that. I doubt that they are right and that H is, as you
> describe it, an emulator. But it's impossible to actually prove these people
> wrong.

#include <stdint.h>
typedef void (*ptr)();

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

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

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

(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret"
instruction.

(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this.

(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.

Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.

The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never reach
its "ret" instruction as a pure function of its inputs.

--
Copyright 2022 Pete Olcott

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

On 6/15/2022 6:31 PM, Mike Terry wrote:
> On 15/06/2022 11:05, Malcolm McLean wrote:
>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> We're dealing with our hands tied behind our backs, because we can't
>>>> see H.
>>> That's only partly true. A sketch of H was posted and we know that that
>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>> does not report on the "halting" of X(Y). There are other detailed
>>> errors we can't critique without the actual H, but do you really care
>>> about those details?
>>>
>> The current claim is that the direct execution of P(P) has different
>> behavior to the correct simulation of the input to H(P,P).
>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>> But that's not possible if H is hidden. PO seems to think that H doesn't
>> matter because its behaviour can be inferred, but here he is wrong.
>>
> PO recently (yesterday?) posted one of his traces with P(P) halting.
>
> Inside that trace, we see P call H, and immediately after that in the
> trace we see NOT H trace entries (all suppressed), but the trace entries
> from "H simulating the input to H(P,P)" - i.e. exactly the trace entries
> PO claims are substantially different from the computation steps of P(P)
> [aka "running" P(P) directly].
>
> So, /are/ they substantially different?  NOT IN THE SLIGHTEST!  (As I've
> suggested a few times, but the evidence is there in PO's own post...)
>
> All we see is that H simulating P(P) calculates EXACTLY the same entries
> as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS SIMULATION.  Not
> one shred of any evidence of diversion!
>
> Of course, it's true we don't see the suppressed H entries, but I don't
> see any reason to think those would be any different if included.  PO is
> simply confused by his own code, and invents silly PSR explanations to
> try to justify it all to himself.  The explanation is obvious to anyone
> who's analysed - H mistakenly decides it sees non-halting behaviour and
> so stops simulating, whereas the computation itself (while containing
> the pattern H spotted - nobody denies that I think) proceeds further and
> after a short while halts.  (PO's rule is unsound, and why shouldn't it
> be - he's never felt the need to offer any /proof/ that it's sound.  He
> just really really really realy thinks it is!)
>
> The most PO could come up with to explain this would be "ok, P(P) and
> H's simulation of the input to H(P,P) /are/ identical step for step as
> far as H simulates, so the difference in computation states /must/ occur
> in the computation steps that H never got to!".   That's Dumb, Dumb,
> Dumb thinking, but it wouldn't surprise me if that's what PO eventually
> comes up with... (He's not capable of thinking it through rationally.)
>
>
> Mike.

#include <stdint.h>
typedef void (*ptr)();

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

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

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

(1) It is an easily verified fact that when we assume that H is only an
x86 emulator that the correctly emulated P never reaches its "ret"
instruction it remains stuck in repeated cycles of emulation.

(2) It is an easily verified fact that if H has been adapted to
correctly detect (in a finite number of steps) that the correct and
complete x86 emulation of its input would never each its "ret"
instruction that H could abort its emulation and return 0 to report this.

(3) When the halt status criteria is defined as correctly determining
whether or not an x86 emulated input would ever reach its "ret"
instruction then it becomes an easily verified fact H(P,P) could
correctly reject its input as non-halting.

*technically competent honest reviewers will know that*
Correct deductive inference proves that all of these things are true
without any need what-so-ever to see either the source-code or the
execution trace of H.

The one thing that is not proved is whether or not an actual encoded
H(P,P) does indeed correctly determine that its input would never reach
its "ret" instruction as a pure function of its inputs.

Now that I finally figured out a very simple way to transform H(P,P)==0
into a pure function of its inputs I will be able to provide the
source-code proving this. I refrained from providing the source-code
before because I knew it would be rejected for using static local memory.

Since the above does prove that H(P,P)==0 is correct whether or not H
can compute this and we know that P(P) halts then
*technically competent honest reviewers* will know that the behavior of
the simulated input is not the same as the directly executed 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

On 6/16/22 10:31 AM, olcott wrote:
> On 6/15/2022 6:31 PM, Mike Terry wrote:
>> On 15/06/2022 11:05, Malcolm McLean wrote:
>>> On Wednesday, 15 June 2022 at 00:45:05 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> We're dealing with our hands tied behind our backs, because we can't
>>>>> see H.
>>>> That's only partly true. A sketch of H was posted and we know that that
>>>> was wrong. And we know that H is wrong by definition because H(X,Y)
>>>> does not report on the "halting" of X(Y). There are other detailed
>>>> errors we can't critique without the actual H, but do you really care
>>>> about those details?
>>>>
>>> The current claim is that the direct execution of P(P) has different
>>> behavior to the correct simulation of the input to H(P,P).
>>> This is pretty bizarre. The obvious way to answer it is to dry-run P(P).
>>> But that's not possible if H is hidden. PO seems to think that H doesn't
>>> matter because its behaviour can be inferred, but here he is wrong.
>>>
>> PO recently (yesterday?) posted one of his traces with P(P) halting.
>>
>> Inside that trace, we see P call H, and immediately after that in the
>> trace we see NOT H trace entries (all suppressed), but the trace
>> entries from "H simulating the input to H(P,P)" - i.e. exactly the
>> trace entries PO claims are substantially different from the
>> computation steps of P(P) [aka "running" P(P) directly].
>>
>> So, /are/ they substantially different?  NOT IN THE SLIGHTEST!  (As
>> I've suggested a few times, but the evidence is there in PO's own
>> post...)
>>
>> All we see is that H simulating P(P) calculates EXACTLY the same
>> entries as P(P) as expected, UP TO THE POINT WHERE H STOPS ITS
>> SIMULATION.  Not one shred of any evidence of diversion!
>>
>> Of course, it's true we don't see the suppressed H entries, but I
>> don't see any reason to think those would be any different if
>> included.  PO is simply confused by his own code, and invents silly
>> PSR explanations to try to justify it all to himself.  The explanation
>> is obvious to anyone who's analysed - H mistakenly decides it sees
>> non-halting behaviour and so stops simulating, whereas the computation
>> itself (while containing the pattern H spotted - nobody denies that I
>> think) proceeds further and after a short while halts.  (PO's rule is
>> unsound, and why shouldn't it be - he's never felt the need to offer
>> any /proof/ that it's sound.  He just really really really realy
>> thinks it is!)
>>
>> The most PO could come up with to explain this would be "ok, P(P) and
>> H's simulation of the input to H(P,P) /are/ identical step for step as
>> far as H simulates, so the difference in computation states /must/
>> occur in the computation steps that H never got to!".   That's Dumb,
>> Dumb, Dumb thinking, but it wouldn't surprise me if that's what PO
>> eventually comes up with... (He's not capable of thinking it through
>> rationally.)
>>
>>
>> Mike.
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax              // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx              // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> (1) It is an easily verified fact that when we assume that H is only an
> x86 emulator that the correctly emulated P never reaches its "ret"
> instruction it remains stuck in repeated cycles of emulation.

Right, *IF* H is a pure x86 emulator, P() will not reach the ret
instruciton, but that ONLY applies to a P that calls an H that is
defined to be that.

>
> (2) It is an easily verified fact that if H has been adapted to
> correctly detect (in a finite number of steps) that the correct and
> complete x86 emulation of its input would never each its "ret"
> instruction that H could abort its emulation and return 0 to report this.

Yes, *IF* there actually existed a pattern, that when implemented in H
actually correctly detects that the correct and complete emulation of
the input would never reach its final state, H can abort its emulation
and return. Note, the proof above said that GIVEN this behavior of H,
that the correct an complete emulation by ANOTHER function that is a
pure emulator STILL doesn't reach the return.

THere is no such pattern in P(P), since ANY pattern that H might use and
see in P(P) causes the H called by P(P) to abort its emulaiton and
return 0 to that P which then halts, showing the pattern to be incorrect.

>
> (3) When the halt status criteria is defined as correctly determining
> whether or not an x86 emulated input would ever reach its "ret"
> instruction then it becomes an easily verified fact H(P,P) could
> correctly reject its input as non-halting.

But only if the pattern was correct even if H included that pattern in
its decision. As pointed above, not such pattern actually exists in P(P)
built on the H that has that pattern in it.

>
> *technically competent honest reviewers will know that*
> Correct deductive inference proves that all of these things are true
> without any need what-so-ever to see either the source-code or the
> execution trace of H.

Nope, It has been proved that no pattern exists, thus your "logic" is
incorrect.

>
> The one thing that is not proved is whether or not an actual encoded
> H(P,P) does indeed correctly determine that its input would never reach
> its "ret" instruction as a pure function of its inputs.
>
> Now that I finally figured out a very simple way to transform H(P,P)==0
> into a pure function of its inputs I will be able to provide the
> source-code proving this. I refrained from providing the source-code
> before because I knew it would be rejected for using static local memory.
>
> Since the above does prove that H(P,P)==0 is correct whether or not H
> can compute this and we know that P(P) halts then
> *technically competent honest reviewers* will know that the behavior of
> the simulated input is not the same as the directly executed input.
>
>
>

Nope, just shows you ignorance of the the actual meaning, or that you
are just a liar.

On 6/16/22 9:47 AM, olcott wrote:
> On 6/14/2022 5:03 AM, Malcolm McLean wrote:
>> On Tuesday, 14 June 2022 at 06:04:37 UTC+1, olcott wrote:
>>> On 6/13/2022 11:59 PM, André G. Isaak wrote:
>>>> On 2022-06-13 21:50, olcott wrote:
>>>>> On 6/13/2022 10:46 PM, André G. Isaak wrote:
>>>>>> On 2022-06-13 11:51, olcott wrote:
>>>>>>> On 6/13/2022 11:13 AM, Mr Flibble wrote:
>>>>>>>> On Mon, 13 Jun 2022 09:27:08 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>
>>>>>>>>> I have updated the algorithm so that it is a pure function of its
>>>>>>>>> inputs. As soon as P calls H for the first time, H (knowing its
>>>>>>>>> own
>>>>>>>>> machine address) is able to look though the prior execution
>>>>>>>>> trace and
>>>>>>>>> see that P is calling H with the same arguments that it was called
>>>>>>>>> with and there are no instructions in P that would break this
>>>>>>>>> cycle.
>>>>>>>> Naive.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> The last paragraph has been extensively reviewed and validated on
>>>>>>> another forum, thus saying that it is simply Naive carries zero
>>>>>>> weight.
>>>>>>
>>>>>> And which forum would that be?
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> That is irrelevant.
>>>>
>>>> It's certainly relevant to anyone interested in reading those reviews.
>>>>
>>>> André
>>>>
>>>>
>>> I do appreciate that you are reviewing my work.
>>> So you don't feel technically qualified to assess the merits of this
>>> directly yourself? The impossibility of finding a valid counter-example
>>> disproving the claim counts as proof that the claim is true.
>>>
>> We're dealing with our hands tied behind our backs, because we can't
>> see H.
>> I and other people have suggested an explanation for the results that you
>> are seeing. But it can only be a shrewd guess. The behaviour of the
>> program
>> depends on how the emulator H is written. If it is in fact an emulator
>> - some
>> posters have disputed that. I doubt that they are right and that H is,
>> as you
>> describe it, an emulator. But it's impossible to actually prove these
>> people
>> wrong.
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax              // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx              // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> (1) It is an easily verified fact that when we assume that H is only an
> x86 emulator that the correctly emulated P never reaches its "ret"
> instruction.
>
> (2) It is an easily verified fact that if H has been adapted to
> correctly detect (in a finite number of steps) that the correct and
> complete x86 emulation of its input would never each its "ret"
> instruction that H could abort its emulation and return 0 to report this.

And since H is now not the pure x86 emulator, the information from (1)
no longer holds.

>
> (3) When the halt status criteria is defined as correctly determining
> whether or not an x86 emulated input would ever reach its "ret"
> instruction then it becomes an easily verified fact H(P,P) could
> correctly reject its input as non-halting.
>

Such a pattern has been proved to not exist in H's trace of P(P).

> Correct deductive inference proves that all of these things are true
> without any need what-so-ever to see either the source-code or the
> execution trace of H.
>
> The one thing that is not proved is whether or not an actual encoded
> H(P,P) does indeed correctly determine that its input would never reach
> its "ret" instruction as a pure function of its inputs.
>
>

So, you have nothing.