computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

computer science decider
a decider is a machine that accepts or rejects inputs.
https://cs.stackexchange.com/questions/84433/what-is-decider

halt decider
A halt decider accepts or rejects inputs on the basis of the actual
behavior specified by these inputs. Whenever the direct execution or
pure simulation of an input would never reach
its final state this input is correctly decided as not halting.

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

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{ H(x, x);
}

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

Proof that H(P,P)==0 is correct for every possible H at machine address
00001a7e that simulates or executes the precise byte sequence shown below:

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]

P is defined as the above precise byte sequence.
The x86 language is the entire inference basis.

For every possible H defined at machine address 00001a7e that has input
(P,P) when the input to H(P,P) is executed or simulated this input is
either infinitely recursive or aborted at some point. In no case does
the input ever reach its final state of 00001a72.

Now that we have verified that the input to H(P,P) never halts we know
that the correct return value for any correct halt decider H(P,P) must
be 0.

To determine the correct halt status of the input to H(P,P) H merely
needs to simulate its input one instruction at a time until H sees P
call itself with the same parameters that it was called with. When H
sees this H correctly returns 0 for not halting.

Strachey, C 1965. An impossible program The Computer Journal, Volume 7,
Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

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

Halting problem undecidability and infinitely nested simulation (V2)
November 2021 PL Olcott

https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2

--
Copyright 2021 Pete Olcott

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

Thirteenth times a charm?

Rapid rewrites show the 'quality' of your work.

On 11/14/21 2:17 PM, olcott wrote:
> computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)

Right, but with the implied 'When Run as a independent computation'.

Otherwise ALL computations could be called non-halting if put into a
simulator/debugger that aborts them before the even get started.

>
> computer science decider
> a decider is a machine that accepts or rejects inputs.
> https://cs.stackexchange.com/questions/84433/what-is-decider

Needs a bit better definition or some clarity. Like that acceptance or
rejection is signaled by halting in finite time and signaling the
decision by either what state you stop in or the contents of the output.

>
> halt decider
> A halt decider accepts or rejects inputs on the basis of the actual
> behavior specified by these inputs. Whenever the direct execution or
> pure simulation of an input would never reach
> its final state this input is correctly decided as not halting.

Not quite. 'Input' doesn't have behavior.

Your mean on the basis of the behavior of the Computations represented
by the input.

This is where you get things wrong.

The decider accepts or rejects the input, but the basis is on the
behavior of the computation REPRESENTED by that input.

Thus, all you mumbo jumbe afterwards is an attempt to be deceitful.

Yes, if you mean that if this input was given to a pure simulator, or
the compuation represented was directly executed, then you are correct.

You can't 'directly execute' and input, as inputs are just symbols so
don't do anything themselves, but only by what they actually MEAN.

The ASCII string "x = y + 1" itself doesn't actually DO anything, when
interpreted as a part of a program it means something.

>
> #include <stdint.h>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y);  // direct execution of P(P)
>   return 1;
> }
>
> // Minimal essence of Linz(1990) Ĥ
> // and Strachey(1965) P
> void P(ptr x)
> {
>   H(x, x);
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> Proof that H(P,P)==0 is correct for every possible H at machine address
> 00001a7e that simulates or executes the precise byte sequence shown below:

So, you have provided a definite definition of H, and then you claim for
'every possible H', you need to decide which one you are talking about.

For your PROVIDED H, yes H(P,P)==0 would be the right answer, since this
H will unconditionally execute P causing P(P) to enter an infinite
recursion.

Unfortunately for your claim, while 0 WOULD be the right answer for THIS
H, it never returns it, so it never gives the right answer, and thus is
WRONG.

This behavior will also be true for ANY H that does UNCONDITIONALLY
simulate or execute the input.

>
> _P()
> [00001a5e](01)  55              push ebp
> [00001a5f](02)  8bec            mov ebp,esp
> [00001a61](03)  8b4508          mov eax,[ebp+08]
> [00001a64](01)  50              push eax        // push P
> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
> [00001a68](01)  51              push ecx        // push P
> [00001a69](05)  e810000000      call 00001a7e   // call H
> [00001a6e](03)  83c408          add esp,+08
> [00001a71](01)  5d              pop ebp
> [00001a72](01)  c3              ret
> Size in bytes:(0021) [00001a72]
>
> P is defined as the above precise byte sequence.
> The x86 language is the entire inference basis.

So P thus defined is a C function.

It is NOT a Computation per compuation theory, as it is not a complete
description. The Computation that P computes is ALSO based on the H
provided to it, so the 'Algortihm' part of the Computation include ALL
the code called during that call to H.

>
> For every possible H  defined at machine address 00001a7e that has input
> (P,P) when the input to H(P,P) is executed or simulated this input is
> either infinitely recursive or aborted at some point. In no case does
> the input ever reach its final state of 00001a72.

WRONG.

If we DIRECTLY exectute this P (as requried by your definition above) to
determine its halting status, this P will be haling PRECISESLY
identially to the behavor of H(P,P) returning something.

If H is a decider, then it ALWAYS will return something, so this P will
be halting for ANY H that meets the requirement of being a decider, or
even just returns for the call H(P,P).

Note, this is where you incorrect definition gets you. 'Inputs' don't
have behavior, only machines.

The 'input' to H represents the ACTUAL computation of the direct
execution of P(P), and if H(P,P) returns ANYTHING, the P(P) will halt.

We also have the alternate of giving that input to a machine that does a
pure simulation or direct execution, like a copy of the H you defined
previously (not changing the current H that P is using, as that is
changing P, but making an independent copy, called maybe Htest)

Running this on that same input will also show it to halt, BY DEFINITION.

>
> Now that we have verified that the input to H(P,P) never halts we know
> that the correct return value for any correct halt decider H(P,P) must
> be 0.
>

No, you haven't as that is a non-sense phrase.

We have shown that if we directly execute the computation that the input
to H represents, or simulate that input, then as long as H(P,P) returns
something, then that input represents a computaton that Halts.

All your H has seen is that it hasn't halted YET. Since an H that
returns te 0 value is NOT a direct exectution or a PURE simulation, the
behavior that it created within itself is not a direct proof of Halting
status.

> To determine the correct halt status of the input to H(P,P) H merely
> needs to simulate its input one instruction at a time until H sees P
> call itself with the same parameters that it was called with. When H
> sees this H correctly returns 0 for not halting.
>

Nope, not a valid rule. Proved wrong by THIS case.

FAIL.

>
> Strachey, C 1965.  An impossible program The Computer Journal, Volume 7,
> Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (318-320)
>
>
> Halting problem undecidability and infinitely nested simulation (V2)
> November 2021 PL Olcott
>
> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>
>

On 11/14/2021 2:02 PM, Richard Damon wrote:
> Thirteenth times a charm?
>
> Rapid rewrites show the 'quality' of your work.
>
>
> On 11/14/21 2:17 PM, olcott wrote:
>> computation that halts
>> a computation is said to halt whenever it enters a final state.
>> (Linz:1990:234)
>
> Right, but with the implied 'When Run as a independent computation'.
>
> Otherwise ALL computations could be called non-halting if put into a
> simulator/debugger that aborts them before the even get started.
>
>>
>> computer science decider
>> a decider is a machine that accepts or rejects inputs.
>> https://cs.stackexchange.com/questions/84433/what-is-decider
>
>
> Needs a bit better definition or some clarity. Like that acceptance or
> rejection is signaled by halting in finite time and signaling the
> decision by either what state you stop in or the contents of the output.
>
>>
>> halt decider
>> A halt decider accepts or rejects inputs on the basis of the actual
>> behavior specified by these inputs. Whenever the direct execution or
>> pure simulation of an input would never reach
>> its final state this input is correctly decided as not halting.
>
>
> Not quite. 'Input' doesn't have behavior.
>

the actual behavior specified by these inputs.
Behavior is specified by C source code.
Behavior is specified by x86 source code.
Behavior is specified by x86 machine code.

the actual behavior specified by these inputs.
Behavior is specified by C source code.
Behavior is specified by x86 source code.
Behavior is specified by x86 machine code.

the actual behavior specified by these inputs.
Behavior is specified by C source code.
Behavior is specified by x86 source code.
Behavior is specified by x86 machine code.

the actual behavior specified by these inputs.
Behavior is specified by C source code.
Behavior is specified by x86 source code.
Behavior is specified by x86 machine code.

--
Copyright 2021 Pete Olcott

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

On 11/14/21 3:06 PM, olcott wrote:
> On 11/14/2021 2:02 PM, Richard Damon wrote:
>> Thirteenth times a charm?
>>
>> Rapid rewrites show the 'quality' of your work.
>>
>>
>> On 11/14/21 2:17 PM, olcott wrote:
>>> computation that halts
>>> a computation is said to halt whenever it enters a final state.
>>> (Linz:1990:234)
>>
>> Right, but with the implied 'When Run as a independent computation'.
>>
>> Otherwise ALL computations could be called non-halting if put into a
>> simulator/debugger that aborts them before the even get started.
>>
>>>
>>> computer science decider
>>> a decider is a machine that accepts or rejects inputs.
>>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>
>>
>> Needs a bit better definition or some clarity. Like that acceptance or
>> rejection is signaled by halting in finite time and signaling the
>> decision by either what state you stop in or the contents of the output.
>>
>>>
>>> halt decider
>>> A halt decider accepts or rejects inputs on the basis of the actual
>>> behavior specified by these inputs. Whenever the direct execution or
>>> pure simulation of an input would never reach
>>> its final state this input is correctly decided as not halting.
>>
>>
>> Not quite. 'Input' doesn't have behavior.
>>
>
> the actual behavior specified by these inputs.
> Behavior is specified by C source code.
> Behavior is specified by x86 source code.
> Behavior is specified by x86 machine code.
>
> the actual behavior specified by these inputs.
> Behavior is specified by C source code.
> Behavior is specified by x86 source code.
> Behavior is specified by x86 machine code.
>
> the actual behavior specified by these inputs.
> Behavior is specified by C source code.
> Behavior is specified by x86 source code.
> Behavior is specified by x86 machine code.
>
> the actual behavior specified by these inputs.
> Behavior is specified by C source code.
> Behavior is specified by x86 source code.
> Behavior is specified by x86 machine code.
>

Right, so if we talk about the COMPUTATION P, that means ALL the source
code used by P, including the source code of H.

And, the 'behavior' of that input, is by your own words, based on the
DIRECT EXECUTION of that input.

Thus, the input P means we directly execute P, ie start the execution
with an unconditional execution path, starting at the begining of the
routine P with the input P.

It doesn't matter what H does with its input, it matters what that input
just does when processes in the specified manner: DIRECT EXECUTION or
PURE SIMULATION.

Your P that can 'abort' its processing, is neither.

FAIL

By the plain meaning of even your own words, the test of the right
answer for H to give is based on the ACTUAL DIRECT EXECUTION of the
function P with parameter P.

THAT direct execution is easy to show will ALWAYS halt if H(P,P) returns
the 0 that you claim to be correct, so, by observation any P that you
claim is correct is actually WRONG.

FAIL.

Any claim otherwise is thus shown to be a LIE.