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?

--
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 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 <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.

It's certainly relevant to anyone interested in reading those reviews.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

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 <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.
>
> 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.

--
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 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.

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?

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 2022-06-14 15:00:55 +0000, olcott said:

> If you can find an a valid counter example where my criteria does
> not work then you have refuted it.

Does it work for

int main(void) {
return H(main, main);
}

?

Mikko

On 6/14/2022 10:52 AM, Mikko wrote:
> On 2022-06-14 15:00:55 +0000, olcott said:
>
>> If you can find an a valid counter example where my criteria does
>> not work then you have refuted it.
>
> Does it work for
>
>    int main(void) {
>      return H(main, main);
>    }
>
> ?
>
> Mikko
>

It was designed such that one non-main C function could be a halt
decider for any non-main C function. It has very limited halt deciding
capability, yet sufficient for this case:

#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));
}

--
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 2022-06-14 15:58:55 +0000, olcott said:

> On 6/14/2022 10:52 AM, Mikko wrote:
>> On 2022-06-14 15:00:55 +0000, olcott said:
>>
>>> If you can find an a valid counter example where my criteria does
>>> not work then you have refuted it.
>>
>> Does it work for
>>
>>    int main(void) {
>>      return H(main, main);
>>    }
>>
>> ?
>>
>> Mikko
>>
>
> It was designed such that one non-main C function could be a halt
> decider for any non-main C function.

In that case, does it work with

static int test(void) {
return H(test, test);
}

int main(void) {
return test();
}

?

Mikko

On 6/14/2022 11:45 AM, Mikko wrote:
> On 2022-06-14 15:58:55 +0000, olcott said:
>
>> On 6/14/2022 10:52 AM, Mikko wrote:
>>> On 2022-06-14 15:00:55 +0000, olcott said:
>>>
>>>> If you can find an a valid counter example where my criteria does
>>>> not work then you have refuted it.
>>>
>>> Does it work for
>>>
>>>    int main(void) {
>>>      return H(main, main);
>>>    }
>>>
>>> ?
>>>
>>> Mikko
>>>
>>
>> It was designed such that one non-main C function could be a halt
>> decider for any non-main C function.
>
> In that case, does it work with
>
>    static int test(void) {
>      return H(test, test);
>    }
>
>    int main(void) {
>      return test();
>    }
>
> ?
>
> Mikko
>

I didn't know until I tried it

static int test(void)
{ return H(test, test);
}

int main()
{ test();
}

The correctly emulated input to H(test, test) specifies infinitely
nested emulation thus H does correctly determine that this correctly
emulated input would never reach is "ret" instruction.

Because halt deciders are required to map their inputs to an accept or
reject state on the basis of the actual behavior of the emulated input H
is correct to reject its input 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

Malcolm McLean <malcolm.arthur.mclean@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?

--
Ben.

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/14/22 1:17 PM, olcott wrote:
> On 6/14/2022 11:45 AM, Mikko wrote:
>> On 2022-06-14 15:58:55 +0000, olcott said:
>>
>>> On 6/14/2022 10:52 AM, Mikko wrote:
>>>> On 2022-06-14 15:00:55 +0000, olcott said:
>>>>
>>>>> If you can find an a valid counter example where my criteria does
>>>>> not work then you have refuted it.
>>>>
>>>> Does it work for
>>>>
>>>>    int main(void) {
>>>>      return H(main, main);
>>>>    }
>>>>
>>>> ?
>>>>
>>>> Mikko
>>>>
>>>
>>> It was designed such that one non-main C function could be a halt
>>> decider for any non-main C function.
>>
>> In that case, does it work with
>>
>>     static int test(void) {
>>       return H(test, test);
>>     }
>>
>>     int main(void) {
>>       return test();
>>     }
>>
>> ?
>>
>> Mikko
>>
>
> I didn't know until I tried it
>
> static int test(void)
> {
>   return H(test, test);
> }
>
> int main()
> {
>   test();
> }
>
> The correctly emulated input to H(test, test) specifies infinitely
> nested emulation thus H does correctly determine that this correctly
> emulated input would never reach is "ret" instruction.
>
> Because halt deciders are required to map their inputs to an accept or
> reject state on the basis of the actual behavior of the emulated input H
> is correct to reject its input as non-halting.
>
>

Except that it doesn't if H(test, test) return 0. If that is true, and H
is the pure function you have claimed it is, then test() will halt, so H
was wrong.

Thus, it seems your H isn't actually the pure function you claim it is,
since it doesn't behave like a pure function.

If you want to claim that two invocation of a pure function with the
same input, please provide the first x86 instruction executed in the
function that give differing results.

Failure to do so, as you have so far, just proves that this claim is a
lie. IT should be trivial to show if it is true, so your failure to do
sp convicts you of lying beyond a shadow of doubt (since the elementary
proof shows it can't happen).

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.

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/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
>
>

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. 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".

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
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.

> 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?

> 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.

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 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?)

--
Ben.

On 6/15/22 7: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. 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".
>
> 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
> 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.
>
>> 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?
>
>> 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.
>
> 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 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.

Once he starts on that flawed foundation, there is no way he can build
any solid formal theory.

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.

--
Ben.

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.
>