Criterion Measure of a simulating halt decider proving that H(P,P)==0

[olcott]

*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a non-halting
behavior pattern such that it can be correctly determined that a correct
and complete simulation of the input would never stop running, or reach
the final state of this input then the SHD aborts its simulation and
returns 0.

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

*H and P match the above halting problem relationship to each other*

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

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

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

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




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

[olcott]

On 6/12/2022 11:07 AM, olcott wrote:

rewritten:

*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a non-halting

behavior pattern such that it correctly determines that a complete

[Mr Flibble]

The H you invoke from main() returns a value whilst the H you invoke
from P does not so they are not the same H. A halt decider, H, must
always return a value to its caller for it to qualify as a halt decider.

/Flibble

[Mr Flibble]

[Richard Damon]

On 6/12/22 12:10 PM, olcott wrote:
> On 6/12/2022 11:07 AM, olcott wrote:
>
> rewritten:
>
> *The criterion measure for a simulating halt decider SHD*
> When the correct partial simulation of the input matches a non-halting
> behavior pattern such that it correctly determines that a complete
> simulation of the input would never stop running, or reach the final
> state of this input then the SHD aborts its simulation and returns 0.

So, you are just admitting to the category error?

The ONLY criterion measure of a Halt Decider is that A Halt Decider
accepts an input that represents an Halting Computation and rejects
inputs that represent a non-halting Computation.

If "Your Criteria" EVER disagrees with this, as appearently it does for
P(P), then your criteria is INVALID, and your Simulating Halt Deciders
are NOT Halt Deciders.

YOU FAIL

Remember the Rules, you don't get to make the rules, but need to live
within the established rules if you want to playan existing game (like
the Halting Problem).


Note, you might be able to actually prove that with proper definitions
that this criteria can be proven to actually match the official
criteria, but such a proof also established the definitions of those
terms and shows that no such finite "non-halting behavior pattern"
actually exists in the simulation of P(P).

This is established because if any such pattern was assumed to exist,
and put into H, the a correct and complete simulation of P(P) will see
that P(P) call a H(P,P) and it simulating to that pattern, aborting its
simulation and returning the reject (0) and P then halting. The key
thing to notice is that H simulated N steps of its simulation, and the
point that it makes that decision is at a step > N in the outer simultion.

Thus a SHD built by this rule will NEVER find a pattern that allows it
to abort, and thus never gives an answer, thus failing to be a decider,
that must answer for ALL inputs in finite time.

[olcott]

On 6/12/2022 12:07 PM, Richard Damon wrote:
> On 6/12/22 12:10 PM, olcott wrote:
>> On 6/12/2022 11:07 AM, olcott wrote:
>>
>> rewritten:
>>
>> *The criterion measure for a simulating halt decider SHD*
>> When the correct partial simulation of the input matches a non-halting
>> behavior pattern such that it correctly determines that a complete
>> simulation of the input would never stop running, or reach the final
>> state of this input then the SHD aborts its simulation and returns 0.
>
> So, you are just admitting to the category error?
>

THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL:
A halt decider must compute the mapping from its input finite strings to
its own accept or reject state on the basis of the actual behavior that
is actually specified by this input finite string.

All rebuttals to this are exactly the same as looking for a white dog in
your living room by looking for a black cat in your kitchen.

[Richard Damon]

On 6/12/22 1:16 PM, olcott wrote:
> On 6/12/2022 12:07 PM, Richard Damon wrote:
>> On 6/12/22 12:10 PM, olcott wrote:
>>> On 6/12/2022 11:07 AM, olcott wrote:
>>>
>>> rewritten:
>>>
>>> *The criterion measure for a simulating halt decider SHD*
>>> When the correct partial simulation of the input matches a
>>> non-halting behavior pattern such that it correctly determines that a
>>> complete simulation of the input would never stop running, or reach
>>> the final state of this input then the SHD aborts its simulation and
>>> returns 0.
>>
>> So, you are just admitting to the category error?
>>
>
> THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL:
> A halt decider must compute the mapping from its input finite strings to
> its own accept or reject state on the basis of the actual behavior that
> is actually specified by this input finite string.
>
> All rebuttals to this are exactly the same as looking for a white dog in
> your living room by looking for a black cat in your kitchen.
>
>

Right, and the input to H needs to be a representation of the macine and
its input, in this case P and P.

That is the source of the Mapping.

The definition of the Results of that Mapping, is if P(P) Halts or not,
that is a legal (if impossible) required results.

Do you disagree that for a DEFINED H, that P(P) will definitely either
Halt or Not?

If so, we can define a mapping from the finite string representation of
P(P) to that result.


Now, part of the problem that you are running into is that you don't
seem to understand what the representation of P needs to be, it isn't
just the "C Function" P, it is the Algorithm of P, or the PROGRAM P, so
that representation needs to include EVERYTHING that P uses, thus
includes its copy of H, so it can't just be the machine code from
compiliation of just the function P.

That you fail to understand that H is ACTUALLY REQUIRED to compute this
results if it wants to be a Halt Decider, then you are showing you are
just ignorant of what this field is about.

If you claim that we can't actually ask a decider about the behavior of
a machine and input from a representation, then you are just agreeing
with the theory, that it impossible to build such a machine.

You arguement just show you don't even understan dwhat the Halting
Theorem is about.

[olcott]

On 6/12/2022 1:00 PM, Richard Damon wrote:
> On 6/12/22 1:16 PM, olcott wrote:
>> On 6/12/2022 12:07 PM, Richard Damon wrote:
>>> On 6/12/22 12:10 PM, olcott wrote:
>>>> On 6/12/2022 11:07 AM, olcott wrote:
>>>>
>>>> rewritten:
>>>>
>>>> *The criterion measure for a simulating halt decider SHD*
>>>> When the correct partial simulation of the input matches a
>>>> non-halting behavior pattern such that it correctly determines that
>>>> a complete simulation of the input would never stop running, or
>>>> reach the final state of this input then the SHD aborts its
>>>> simulation and returns 0.
>>>
>>> So, you are just admitting to the category error?
>>>
>>
>> THAT YOU FAIL TO COMPREHEND THE TRUTH OF THIS IS NO REBUTTAL AT ALL:
>> A halt decider must compute the mapping from its input finite strings
>> to its own accept or reject state on the basis of the actual behavior
>> that is actually specified by this input finite string.
>>
>> All rebuttals to this are exactly the same as looking for a white dog
>> in your living room by looking for a black cat in your kitchen.
>>
>>
>
> Right, and the input to H needs to be a representation of the macine and
> its input, in this case P and P.

The correct x86 emulation of the machine code of P by H is the ultimate
measure of the behavior specified by P to H.

[Richard Damon]

And by definition, the correct x86 emualation behaves exactly the same
as the program the code comes from.

Thus the correct x86 emulation of the input to H(P,P) halts if P(P)
halts, and doesn't halt if P(P) doesn't halt.

Thus H(P,P) returning 0 is incorrect if P(P) Halts when H(P,P) returns
0, which it does, so that answer is unconditionally wrong to give by H.

That is basic definition.

[olcott]

The direct execution of P(P) is conclusively proven to have a different
sequence of instructions that its correct x86 emulation by H.

This is caused by the fact that when H(P,P) is executed before its input
its emulated the sequence has a different starting point than when P is
executed before H is executed.

All competent software engineers will know that changing an invocation
sequence can change the outcome.

[Richard Damon]

Kind of hard for something to not match its definition and still be correct.

>
> This is caused by the fact that when H(P,P) is executed before its input
> its emulated the sequence has a different starting point than when P is
> executed before H is executed.

Nope, P starts at its beginning both times.

If it affects H, then H is just proved not to be a compuation, or a Pure
Function.

>
> All competent software engineers will know that changing an invocation
> sequence can change the outcome.
>
>

But both are invoced the same, as H(P,P). If context matters, then H is
NOT a Computation or a Pure Function, BY DEFINITON. PERIOD.

Since being a Computation is a REQUIREMENT for a Halt Decider, if it
fails to be a Computation, it isn't a Halt Decider.

So, you just admitted that your H doesn't meet the requirements to be a
Halt Decider.

[olcott]

When P(P) is executed its behavior conditionally depends on the return
value of H.

When H(P,P) is executed the correctly emulated P cannot possibly reach
the point where its behavior depends on H.

[Richard Damon]

You seem confused. We aren't comparing P(P) to H(P,P) and saying they
need to generate the same sequence of states.

We are comparing P(P) to the correct emulation of the input to H(P,P),
or the two different calls to H(P,P) (from main or from P(P)).

IF P(P) can call H(P,P) and get returned the value 0, then the CORRECT
simulation of the input to H(P,P) will do the same, because you have
DEFINED that H(P,P) WILL abort its simulation, and thus it doesn't do a
"Correct Simulation of its input".

Since you have already admitted that H doesn't ACTUALLY perform a
correct and complete emulation of its input, you can't use the logic
that if it did it would never return an answer. THAT is UNSOUND Logic.

If this IS the behavior of H, then H is NOT a pure function of its
inputs, since in both cases we are just calling H(P,P) and thus
somewhere the code is depending on something besides the input to behave
differently.

If you want to claim that H IS just a pure function of its input, but
does behave differerently, then what is the instruction that created the
first difference in behavior?

Since you claim that H only depends on its input, the inputs to that
instruction will be the same for the two cases, but the instruction does
two different things.

I don't think you can show that, because you design for H is likely not
actually a pure function of its inputs (or it is using a function that
isn't a pure function ITS inputs, which makes H not pure either).

Go ahead, prove me a liar and post what instruction behaved differently
in the two cases with the same input.

[olcott]

This is the part where you seem to be a brain dead moron.
I use these harsh terms because I have totally explained this to you
many hundreds of times.

The correctly emulated input to H(P,P) cannot possibly get any return
value from H because it keeps calling H in infinitely nested emulation
until it has its emulation aborted.

[olcott]

On 6/13/2022 2:44 AM, Malcolm McLean wrote:

> So your case is that you have dry run P(P) and determined that it never halts.
> Additionally H(P,P) reports non-halting. Therefore you conclude that H is
> correct.

In the above case when H(P,P) partially emulates its input it correctly
determines that a correct and complete emulation of its input would
never stop running or reach the "ret" instruction of P. Instead it would
be stuck in infinitely recursive emulation.

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.

[Mr Flibble]

Naive.

/Flibble

[olcott]

The last paragraph has been extensively reviewed and validated on
another forum, thus saying that it is simply Naive carries zero weight.

The only way that the last paragraph can be rebutted is to find a
counter-example that proves it to be incorrect.

[Mr Flibble]

On Mon, 13 Jun 2022 12:51:08 -0500

Publish your algorithm which determines that there are no instructions
in P that would break the cycle.

/Flibble

[olcott]

[Mr Flibble]

On Mon, 13 Jun 2022 13:25:50 -0500

That is a trace of P, it is not an algorithm which determines that
there are no instructions in P that would break the cycle. Publish the
source code of your algorithm.

/Flibble

[olcott]

Because everyone can see that above first seven instructions of P
provide no means for the emulated input to H(P,P) to break out of
repeated x86 emulations your request for code that recognizes this is
merely playing head games.

[Mr Flibble]

On Mon, 13 Jun 2022 14:25:47 -0500

You've got nothing.

/Flibble

[olcott]

Every competent software engineer can very easily tell that it would be
very easy to write a program that examines the correct x86 emulation of
the above P to determine that P cannot break out of its recursive
emulation.

That you imply that this cannot be correctly determined without actually
seeing the code that does this can't reasonably be construed as any
honest mistake.

[Mr Flibble]

On Mon, 13 Jun 2022 14:47:16 -0500

Are you pattern matching x86 opcodes "EB FE" or not? Publish source
code so we don't have to guess.

/Flibble

[olcott]

The only actual relevant question is this:
Is it possible or impossible for an algorithm to correctly determine
that the correctly emulated input to H(P,P) never halts?

If it is possible then H(P,P)==0 is proven to be correct.

[Mr Flibble]

On Mon, 13 Jun 2022 15:14:48 -0500

You've got nothing, nothing but hot air.

/Flibble

[olcott]

What dishonest person says when they know that they have been correctly
refuted. On the other hand when an honest person forms a rebuttal they
use reasoning to point out errors.

[Mr Flibble]

On Mon, 13 Jun 2022 15:56:44 -0500

You simply ignore any reasoning pointing out errors. You are dishonest
and you've got nothing.

/Flibble

[olcott]

I provided the reasoning above and it is still there.
You provided no rebuttal to this reasoning as the clearly record shows.

[Mr Flibble]

On Mon, 13 Jun 2022 16:20:00 -0500

The hubris is unbelievable.

/Flibble

[olcott]

So far every single reviewer has managed to dodge a rigorous
point-by-point software engineering review of H(P,P)==0.

Like you they resort to mere rhetoric presumably because they know that
when using correct reaoning as a basis that every rebuttal must fail.

[Mr Flibble]

On Mon, 13 Jun 2022 17:15:29 -0500

You are correct on that point: every rebuttal fails to get through your
thick skull.

/Flibble

[Richard Damon]

Except that H is MISTAKEN on the behavior of H, because, since THIS H is
going to abort its simulation, it needs to allow for the H that it is
simulating to do the same thing.

Thus H makes the same mistake that you keep on doing and thinking that H
can actually do a complete and correct emulation and also return an
annswer for P.

This is impossible, ALL H(P,P) must do the same thing, either return 0
or recurse infinitely in their simulatings, and any statement contrary
is just a LIE.

If you want to show that it can. just provide, as previously ask, to
provide the FIRST x86 instruction that behaved differently in those two
different paths.

You claim that H is a "Pure Function" of its inputs, so that at that
first difference, the instruction will be the same, and the inputs to it
will be the same, but the results will be different.

Since you have the code for H already (or so you claim) this should be
easy to find, and when you show it you will be famous.

When you don't show it, you will be shown to just be a pathlogical liar.


Note, you keep on making this mistake of forgetting that the H that P
calls is part of that function, so the conditionals there DO count for
breaking the cycle. Your missing this just shows how ignorant you are of
the basic of programming.

[Richard Damon]

Can you point to the message where someone actually agreed with your
conclusion?

I don't remember seeing one, so I think this is another of your lies.

[Richard Damon]

But it doesn't matter, since the alogrithm of H is part of the algorithm
of P by the call.

THAT has the code to break out of the emulation cycle.

You are just showing your stupidity by ignoring the basic facts.

[olcott]

another forum, not USENET.

Ultimately the truth of it depends on the fact that zero correct
rebuttals exist.

[Richard Damon]

Nope, lack of evidence of error is not evidence of lack of error.

So, can you actually QUOTE someone who agrees with you?

Note, you LIE that no correct rebuttalls exist as many have been posted,
not of which you have shown an error in.

"Correct" is not just agreeing with YOUR beliefs.

Until you can show an ACTUAL proof of what you claim (which is
impossible basedd on the actual definitions) all you statemeents are
just LIES.

You don't even KNOW the meaning of Truth.

I can say by your logic, that since "NO correct rebuttals exist" about
the claim that you are just a pathological liar, that must be true, and
by your logic you need to accept it.

[olcott]

If there has been no evidence that anyone has presented then this is not
proof at all that the claim is true.

If there is no evidence that anyone could ever possibly present then
this is proof that the claim is true.

[Richard Damon]

Evidence of error HAS been given, and IGNRORED by you, proving your
ignorance, and that you are a pathological liar.

Your choosing to ignore the evidence doesn't negate that it does prove
you to be wrong, just that you are incapable of learning.

You can continue this way, and when you are gone, all people will
remember you for is what an idiot you were.

Your choice.

[olcott]

Only the rebuttals that you and Flibble provide are woefully incorrect.
You can't even understand that a dead process does not continue to
execute and Flibble cannot understand that unreachable code has no
effect on behavior.

[Richard Damon]

Show the ACTUAL error.

Your "Dead Process" claim just shows your ignorance, as you have been
told multiple times (but seem to dumb to understand) that Halting is a
property of the TURING MACHINE, not the simulaiton of it, and the TURING
MACHINE doesn't halt until it reaches a final state

What is wrong with that statement, or are you going to admit to being
ignorant of the meaning of the words.

You just keep repeating your LIES that have been PROVEN incorrect, the
world knows you are wrong, the universe knows you are wrong, the Theory
knows you are wrong.

You are just wrong, and are going to die as the promoter of errors.

[Mr Flibble]

On Mon, 13 Jun 2022 19:45:49 -0500

Of course I understand that unreachable code has no effect on
behaviour; what has an effect on behaviour is changing unreachable code
to be reachable -- i.e. what *if* P isn't pathological (i.e. it halts),
your H never returns to allow such code to be reach which is an error:
all halting deciders return a value to their caller.

/Flibble

[olcott]

(1) It is no longer P it is X
(2) H(X,X)==1

> your H never returns to allow such code to be reach which is an error:
> all halting deciders return a value to their caller.
>
> /Flibble
>

[Richard Damon]

I think the issue is that Olcott thinks that ANY computation X(Y) that
uses H(X, Y) becomes non-halting, even if it unconditionally halts
afterwards, which just proves that H itself is non-halting and thus not
a decider.

He somehow thinks that it is ok for the simulation of H to be different
than the actual call to H, but refuses to actually show at what point
the two diverge, because they can't if H is doing a step-accurate
simulation.

[Richard Damon]

How does it know? The code doesn't include the name, the first bytes
that it emulates are just the same.

You don't seem to have a case.

[André G. Isaak]

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é


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

[olcott]

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. You should know that Validity supersedes
credibility. Do you believe (like 40% of the electorate) that the
consensus of fools correctly determines the truth?

[André G. Isaak]

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.

[olcott]

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.

[Richard Damon]

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

[olcott]

On 6/14/2022 5:03 AM, Malcolm McLean wrote:

> 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

[olcott]

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.

[olcott]

On 6/14/2022 6:45 PM, 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.
>

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

[Richard Damon]

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.

[olcott]

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


--

[Richard Damon]

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.

[olcott]

On 6/15/2022 6:17 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@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.

[olcott]

On 6/15/2022 9:03 AM, Ben Bacarisse wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:

>
>> On 6/15/22 7:17 AM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@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.

[Richard Damon]

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.

[Richard Damon]

On 6/15/22 11:02 AM, olcott wrote:
> On 6/15/2022 6:17 AM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@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.

[olcott]

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

[Richard Damon]

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.

[olcott]

On 6/14/2022 5:03 AM, Malcolm McLean wrote:

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

[olcott]

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.

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

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.

[Richard Damon]

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.

[Richard Damon]

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.