#include <stdint.h>
#include <stdio.h>
typedef int (*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
int P(ptr x)
{ H(x, x);
return 1; // Give P a last instruction at the "c" level
}

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

The above program is obviously infinitely recursive. It is self evident
that when 0 to ∞ steps of the input to H(P,P) are directly executed or
correctly simulated that the input to H(P,P) never reaches its final
instruction.

PSR set (pathological self-reference)
H1(P1,P1) Is the above code.
H2(P2,P2) Is the above code where H2 simulates rather than directly
executes its input.
H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).

<rewrite>
Every Hn(Px,Py) that returns a value returns 1 except for instances of
{H3, H4} that determine whether or not to return {0,1} on the basis of
the behavior of their input.
</rewrite>

The sequence of 1 to N configurations specified by the input to H(X, Y)
cannot be correctly construed as anything other than the sequence of 1
to N steps of the (direct execution, x86 emulation or UTM simulation of
this input by H.

When H directly executes 1 to N steps of its actual input this
conclusively proves that this is the correct direct execution basis for
the halt decider's halt status decision. The simulation of this same
input derives the exact same sequence of steps.

The point in the sequence of 1 to N steps where the execution trace of
the simulation of P shows that P is about to call H(P,P) again with the
same input that H was called with provides conclusive proof that P would
be infinitely recursive unless H aborted its simulation.

When P(P) calls H(P,P) reaches the above point in its simulation it
returns 0 to P.

H is a computable function that accepts or rejects inputs in its domain
on the basis that these inputs specify a sequence of configurations that
reach their final state.

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

On 2021-11-25 12:29, olcott wrote:
> #include <stdint.h>
> #include <stdio.h>
> typedef int (*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
> int P(ptr x)
> {
>   H(x, x);
>   return 1; // Give P a last instruction at the "c" level
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> The above program is obviously infinitely recursive. It is self evident
> that when 0 to ∞ steps of the input to H(P,P) are directly executed or
> correctly simulated that the input to H(P,P) never reaches its final
> instruction.
>
> PSR set (pathological self-reference)
> H1(P1,P1) Is the above code.
> H2(P2,P2) Is the above code where H2 simulates rather than directly
> executes its input.
> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>
> <rewrite>
> Every Hn(Px,Py) that returns a value returns 1 except for instances of
> {H3, H4} that determine whether or not to return {0,1} on the basis of
> the behavior of their input.
> </rewrite>
>
> The sequence of 1 to N configurations specified by the input to H(X, Y)
> cannot be correctly construed as anything other than the sequence of 1
> to N steps of the (direct execution, x86 emulation or UTM simulation of
> this input by H.
>
> When H directly executes 1 to N steps of its actual input this
> conclusively proves that this is the correct direct execution basis for
> the halt decider's halt status decision. The simulation of this same
> input derives the exact same sequence of steps.
>
> The point in the sequence of 1 to N steps where the execution trace of
> the simulation of P shows that P is about to call H(P,P) again with the
> same input that H was called with provides conclusive proof that P would
> be infinitely recursive unless H aborted its simulation.
>
> When P(P) calls H(P,P) reaches the above point in its simulation it
> returns 0 to P.
>
> H is a computable function that accepts or rejects inputs in its domain
> on the basis that these inputs specify a sequence of configurations that
> reach their final state.

You seem determined not to learn.

H is a computer program, *not* a computable function.

If it is a halt decider, it computes the halting function.

The domain of the halting function is the set of all computations.

Therefore, the domain of H is the same, appropriately encoded as strings.

P(P) is a computation, therefore it is in the domain of H.

P(P) halts, therefore H(P, P) must return true.

Your H(P, P) returns false, and therefore does not compute the halting
function (not surprising, given that the halting function is not
computable).

André

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

Rapid cycling through versions still.

The fact that you don't answer the refutations just shows you HAVE no
answer and are just flailing.

Ultimately, your problem is the the DEFINITION of a Halt decider has its
right answer based on the behavior of the computation the input
represents, so the right answer to H(p,i) depends on the behavior of
p(i), and since when H(P,P) returns 0, we know that (and you agree) P(P)
will Halt, that 0 answer can not be correct.

Trying to rephrase the condition just points out that you are being
deceptive in the conditions, and NOT actually using the definition of a
real Halt Decider.

Similarly with you creation of all these sets. Since you only really
need to come up with ONE example, your obfusaction with sets makes it
clear that you don't ACTUALLY have a case that is the counter, but are
just throwing out a bunch of POOP and hoping something will stick.

On 11/25/21 2:29 PM, olcott wrote:
> #include <stdint.h>
> #include <stdio.h>
> typedef int (*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
> int P(ptr x)
> {
>   H(x, x);
>   return 1; // Give P a last instruction at the "c" level
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> The above program is obviously infinitely recursive. It is self evident
> that when 0 to ∞ steps of the input to H(P,P) are directly executed or
> correctly simulated that the input to H(P,P) never reaches its final
> instruction.
>
> PSR set (pathological self-reference)
> H1(P1,P1) Is the above code.
> H2(P2,P2) Is the above code where H2 simulates rather than directly
> executes its input.
> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>
> <rewrite>
> Every Hn(Px,Py) that returns a value returns 1 except for instances of
> {H3, H4} that determine whether or not to return {0,1} on the basis of
> the behavior of their input.
> </rewrite>

And H1 and H2 will never answer Hn(Pn,Pn) so will fail to be a decider

And every H3 and H4 will answer 0 for Hn(Pn,Pn), and be wrong, since
Pn(Pn) will halt in N+k steps (so Hn won't see it) and thus also be wrong.

And how does H3 answer the input to H1? H3 needs to answer its OWN
input, the P based on IT, not some other halt decider.

If Hn is given Pm (n != m) then the answer doesn't say anything about
Linz proof, as H^ is only claimed to confound H, not some other Halt
decider, so the only Hn(Pn,Pn) matters, and it fails for that.

>
> The sequence of 1 to N configurations specified by the input to H(X, Y)
> cannot be correctly construed as anything other than the sequence of 1
> to N steps of the (direct execution, x86 emulation or UTM simulation of
> this input by H.

Ok, but simulating N steps of a computation doesn't tell you anything
abut the computation unless it DID halt in that many steps, you can't
tell if the computation will halt in some M > N steps or never halt even
if run for an unbounded number of steps.

>
> When H directly executes 1 to N steps of its actual input this
> conclusively proves that this is the correct direct execution basis for
> the halt decider's halt status decision. The simulation of this same
> input derives the exact same sequence of steps.

No, it does not. The DEFINITION of direct execution is running the
machine UNCONDITIONALLY TO ITS END, even if that takes an unboundd
number of steps. FAIL, you are using bad definitions.

>
> The point in the sequence of 1 to N steps where the execution trace of
> the simulation of P shows that P is about to call H(P,P) again with the
> same input that H was called with provides conclusive proof that P would
> be infinitely recursive unless H aborted its simulation.

Except that doesn't prove what you claim. Since it is given that Hn will
only execute/simulate its input for N steps, then H can NOT create
infinte recursion as that would require running the input for an
infinite number of steps (no finite N is unbounded).

This shows that the CALLING P will be finite (and reach ITS end without
itself being aborted), and thus, since P is a computation, we also know
that the same happed for the P that H was simulating.

>
> When P(P) calls H(P,P) reaches the above point in its simulation it
> returns 0 to P.

Right, Calling P gets the returned 0, and Halts.

Thus ALL copies of this P(P) are Halting.

>
> H is a computable function that accepts or rejects inputs in its domain
> on the basis that these inputs specify a sequence of configurations that
> reach their final state.

Right, and P(P) is a computation that reaches its final state, and thus
SHOULD be accepted.

It reaches that final state in more steps then its H allows, so that H
give the wrong answer and thus fails to be a HALT decider.

Maybe it is a POOP decider, but it isn't a Halt decider.

>
>
> 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/25/2021 2:00 PM, André G. Isaak wrote:
> On 2021-11-25 12:29, olcott wrote:
>> #include <stdint.h>
>> #include <stdio.h>
>> typedef int (*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
>> int P(ptr x)
>> {
>>    H(x, x);
>>    return 1; // Give P a last instruction at the "c" level
>> }
>>
>> int main(void)
>> {
>>    H(P, P);
>> }
>>
>> The above program is obviously infinitely recursive. It is self
>> evident that when 0 to ∞ steps of the input to H(P,P) are directly
>> executed or correctly simulated that the input to H(P,P) never reaches
>> its final instruction.
>>
>> PSR set (pathological self-reference)
>> H1(P1,P1) Is the above code.
>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>> executes its input.
>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>
>> <rewrite>
>> Every Hn(Px,Py) that returns a value returns 1 except for instances of
>> {H3, H4} that determine whether or not to return {0,1} on the basis of
>> the behavior of their input.
>> </rewrite>
>>
>> The sequence of 1 to N configurations specified by the input to H(X,
>> Y) cannot be correctly construed as anything other than the sequence
>> of 1 to N steps of the (direct execution, x86 emulation or UTM
>> simulation of this input by H.
>>
>> When H directly executes 1 to N steps of its actual input this
>> conclusively proves that this is the correct direct execution basis
>> for the halt decider's halt status decision. The simulation of this
>> same input derives the exact same sequence of steps.
>>
>> The point in the sequence of 1 to N steps where the execution trace of
>> the simulation of P shows that P is about to call H(P,P) again with
>> the same input that H was called with provides conclusive proof that P
>> would be infinitely recursive unless H aborted its simulation.
>>
>> When P(P) calls H(P,P) reaches the above point in its simulation it
>> returns 0 to P.
>>
>> H is a computable function that accepts or rejects inputs in its
>> domain on the basis that these inputs specify a sequence of
>> configurations that reach their final state.
>
> You seem determined not to learn.
>
> H is a computer program, *not* a computable function.
>
> If it is a halt decider, it computes the halting function.
>

If it is a decider then if maps finite strings to accept / reject states.

> The domain of the halting function is the set of all computations.
>

This is too abstract and you know it.
A halt decider maps finite string pairs to accept / reject states.

> Therefore, the domain of H is the same, appropriately encoded as strings.
>
> P(P) is a computation, therefore it is in the domain of H.
>
> P(P) halts, therefore H(P, P) must return true.
>

You keep insisting on a leap of logic. For H(x,y) the pair of finite
strings (x,y) must be transformed into a sequence of configurations by a
specific algorithm.

Simply saying that this is whatever sequence is specified by the direct
execution of P(P) is too vague.

The input to H(x,y) is transformed into a sequence of configurations by
the (direct execution, x86 emulation or UTM simulation) of this (x,y)
input by H.

> Your H(P, P) returns false, and therefore does not compute the halting
> function (not surprising, given that the halting function is not
> computable).
>
> André
>

--
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/25/21 6:56 PM, olcott wrote:
> On 11/25/2021 2:00 PM, André G. Isaak wrote:
>> On 2021-11-25 12:29, olcott wrote:
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> typedef int (*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
>>> int P(ptr x)
>>> {
>>>    H(x, x);
>>>    return 1; // Give P a last instruction at the "c" level
>>> }
>>>
>>> int main(void)
>>> {
>>>    H(P, P);
>>> }
>>>
>>> The above program is obviously infinitely recursive. It is self
>>> evident that when 0 to ∞ steps of the input to H(P,P) are directly
>>> executed or correctly simulated that the input to H(P,P) never
>>> reaches its final instruction.
>>>
>>> PSR set (pathological self-reference)
>>> H1(P1,P1) Is the above code.
>>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>>> executes its input.
>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>
>>> <rewrite>
>>> Every Hn(Px,Py) that returns a value returns 1 except for instances
>>> of {H3, H4} that determine whether or not to return {0,1} on the
>>> basis of the behavior of their input.
>>> </rewrite>
>>>
>>> The sequence of 1 to N configurations specified by the input to H(X,
>>> Y) cannot be correctly construed as anything other than the sequence
>>> of 1 to N steps of the (direct execution, x86 emulation or UTM
>>> simulation of this input by H.
>>>
>>> When H directly executes 1 to N steps of its actual input this
>>> conclusively proves that this is the correct direct execution basis
>>> for the halt decider's halt status decision. The simulation of this
>>> same input derives the exact same sequence of steps.
>>>
>>> The point in the sequence of 1 to N steps where the execution trace
>>> of the simulation of P shows that P is about to call H(P,P) again
>>> with the same input that H was called with provides conclusive proof
>>> that P would be infinitely recursive unless H aborted its simulation.
>>>
>>> When P(P) calls H(P,P) reaches the above point in its simulation it
>>> returns 0 to P.
>>>
>>> H is a computable function that accepts or rejects inputs in its
>>> domain on the basis that these inputs specify a sequence of
>>> configurations that reach their final state.
>>
>> You seem determined not to learn.
>>
>> H is a computer program, *not* a computable function.
>>
>> If it is a halt decider, it computes the halting function.
>>
>
> If it is a decider then if maps finite strings to accept / reject states.

And if that Mapping isn't the Halting Function, it isn't a Halt Decider.

That means if H(p,i) doesn't match the behavior of p(i) it FAILS to be
the required Halt Decider.

>
>> The domain of the halting function is the set of all computations.
>>
>
> This is too abstract and you know it.
> A halt decider maps finite string pairs to accept / reject states.

Right, but the DOMAIN of those finite strings is the representation of
ALL Computations.

In particular, since you only claim partial deciding for the Linz
formula, it must be able to decide on the H^/P that is built from it.

>
>> Therefore, the domain of H is the same, appropriately encoded as strings.
>>
>> P(P) is a computation, therefore it is in the domain of H.
>>
>> P(P) halts, therefore H(P, P) must return true.
>>
>
> You keep insisting on a leap of logic. For H(x,y) the pair of finite
> strings (x,y) must be transformed into a sequence of configurations by a
> specific algorithm.
>

That is implementation detail. Ultimately, it needs to produce the
answer that matches its requirement. Either H(x,y) by HOWEVER it works,
be it simulation or some funny hash function, gives the right answer, or
it gives the wrong answer. That rightness or wrongness is measured by
the Function that it is supposed to compute, which is based on the
behavior of the computation that the input represents.

> Simply saying that this is whatever sequence is specified by the direct
> execution of P(P) is too vague.

But that is how it is defined, For EVERY Turing Machine (for which there
is a countably infinte number of them) given every input (again a
countably infinte number, so a countably infinite number of pairings)
the Halting Function (whether that Turing Machine given that Input Halts
or not) gives us the output that H needs to give when it is supplied
that input.

Nothing 'vague' about that.

>
> The input to H(x,y) is transformed into a sequence of configurations by
> the (direct execution, x86 emulation or UTM simulation) of this (x,y)
> input by H.
>

Yes, given a REAL UTM (one that will NEVER stop) one way to determine
what the answer is would be to compute what UTM(x,y) will do.

I.E, the proper output of H(x,y) will exactly match the halting behavior
of UTM(x,y). Note, if H 'aborts' its processing of simulating/executing
that x(y) input, it is NOT the equivalent of a UTM.

So, THAT rule gives you a concrete answer that can be used to check if H
gave the right answer,

It can't always be used by H to determine its answer, as the UTM might
never stop, so H can't wait for that to decide.

H might be able to do this simulation for a while and then CORRECTLY
determine that the machine at its input will never halt, and then abort
and give that answer, but it needs to use VALID rules to decide that.

Note, your claim that H(P,P) == 0 got it right is disproven as UTM(P,P)
behaves the same as P(P) which Halts, so H did something WRONG in its
analysis, and that error has been pointed out to you many times.

>
>> Your H(P, P) returns false, and therefore does not compute the halting
>> function (not surprising, given that the halting function is not
>> computable).
>>
>> André
>>
>
>

On 2021-11-25 16:56, olcott wrote:
> On 11/25/2021 2:00 PM, André G. Isaak wrote:
>> On 2021-11-25 12:29, olcott wrote:
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> typedef int (*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
>>> int P(ptr x)
>>> {
>>>    H(x, x);
>>>    return 1; // Give P a last instruction at the "c" level
>>> }
>>>
>>> int main(void)
>>> {
>>>    H(P, P);
>>> }
>>>
>>> The above program is obviously infinitely recursive. It is self
>>> evident that when 0 to ∞ steps of the input to H(P,P) are directly
>>> executed or correctly simulated that the input to H(P,P) never
>>> reaches its final instruction.
>>>
>>> PSR set (pathological self-reference)
>>> H1(P1,P1) Is the above code.
>>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>>> executes its input.
>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>
>>> <rewrite>
>>> Every Hn(Px,Py) that returns a value returns 1 except for instances
>>> of {H3, H4} that determine whether or not to return {0,1} on the
>>> basis of the behavior of their input.
>>> </rewrite>
>>>
>>> The sequence of 1 to N configurations specified by the input to H(X,
>>> Y) cannot be correctly construed as anything other than the sequence
>>> of 1 to N steps of the (direct execution, x86 emulation or UTM
>>> simulation of this input by H.
>>>
>>> When H directly executes 1 to N steps of its actual input this
>>> conclusively proves that this is the correct direct execution basis
>>> for the halt decider's halt status decision. The simulation of this
>>> same input derives the exact same sequence of steps.
>>>
>>> The point in the sequence of 1 to N steps where the execution trace
>>> of the simulation of P shows that P is about to call H(P,P) again
>>> with the same input that H was called with provides conclusive proof
>>> that P would be infinitely recursive unless H aborted its simulation.
>>>
>>> When P(P) calls H(P,P) reaches the above point in its simulation it
>>> returns 0 to P.
>>>
>>> H is a computable function that accepts or rejects inputs in its
>>> domain on the basis that these inputs specify a sequence of
>>> configurations that reach their final state.
>>
>> You seem determined not to learn.
>>
>> H is a computer program, *not* a computable function.
>>
>> If it is a halt decider, it computes the halting function.
>>
>
> If it is a decider then if maps finite strings to accept / reject states.

Yes, and in doing so it computes the halting function.

>> The domain of the halting function is the set of all computations.
>>
>
> This is too abstract and you know it.
> A halt decider maps finite string pairs to accept / reject states.

And those strings consist of descriptions of a computation,
appropriately encoded for your particular halt decider.

>> Therefore, the domain of H is the same, appropriately encoded as strings.
>>
>> P(P) is a computation, therefore it is in the domain of H.
>>
>> P(P) halts, therefore H(P, P) must return true.
>>
>
> You keep insisting on a leap of logic. For H(x,y) the pair of finite
> strings (x,y) must be transformed into a sequence of configurations by a
> specific algorithm.

No, it doesn't. That's the implementational path you've chosen to take,
but the problem doesn't specify this.

> Simply saying that this is whatever sequence is specified by the direct
> execution of P(P) is too vague.

There's nothing vague about this at all.

> The input to H(x,y) is transformed into a sequence of configurations by
> the (direct execution, x86 emulation or UTM simulation) of this (x,y)
> input by H.

You are extremely confused here. You keep referring to
*implementational* details of your H as if they were somehow part of the
halting problem.

The halting problem is defined as follows. Note this is a definition, so
it isn't open to debate.

A halt decider H is a turing machine which decides for any arbitrary
computation M(I) whether that computation will halt. In your
terminology, that means whether int main { M(I); } halts. [This last bit
isn't usually specified since computations by definition are
*indendepent* entities and you are the only one who gets confused by this].

The input to H is a string which encodes M and a string which encodes I.

Note that nothing in the above statement of the problem mentions
anything about 'sequences of configurations' or the (direct execution,
x86 emulation or UTM simulation) of the input by H. These are *YOUR*
additions which have nothing to do with the actual definition of the
problem.

Since P(P) is a computation it must be possible to represent this as a
concatenation of strings which can be passed to H as an input.

Since P(P) halts, H must return 1 for this particular input.

If your H cannot properly interpret the representation of P(P) as
representing the *independent* computation P(P), then your
implementation fails to meet the definition of the problem.

If your H cannot properly determine that P(P) halts, then your
implementation fails to meet the definition of the problem.

The fact that your H is unable to meet these specifications doesn't
*change* what these specifications are. The problem is what it is. The
definition of halt decider is what it is. You can't fiddle with these
definitions just because you can't figure out how to solve the actual
question specified by the problem.

The halting function is simply not computable, so you'll never be able
to create an H which actually gets all cases right.

André

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

On 11/25/2021 6:46 PM, André G. Isaak wrote:
> On 2021-11-25 16:56, olcott wrote:
>> On 11/25/2021 2:00 PM, André G. Isaak wrote:
>>> On 2021-11-25 12:29, olcott wrote:
>>>> #include <stdint.h>
>>>> #include <stdio.h>
>>>> typedef int (*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
>>>> int P(ptr x)
>>>> {
>>>>    H(x, x);
>>>>    return 1; // Give P a last instruction at the "c" level
>>>> }
>>>>
>>>> int main(void)
>>>> {
>>>>    H(P, P);
>>>> }
>>>>
>>>> The above program is obviously infinitely recursive. It is self
>>>> evident that when 0 to ∞ steps of the input to H(P,P) are directly
>>>> executed or correctly simulated that the input to H(P,P) never
>>>> reaches its final instruction.
>>>>
>>>> PSR set (pathological self-reference)
>>>> H1(P1,P1) Is the above code.
>>>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>>>> executes its input.
>>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>>
>>>> <rewrite>
>>>> Every Hn(Px,Py) that returns a value returns 1 except for instances
>>>> of {H3, H4} that determine whether or not to return {0,1} on the
>>>> basis of the behavior of their input.
>>>> </rewrite>
>>>>
>>>> The sequence of 1 to N configurations specified by the input to H(X,
>>>> Y) cannot be correctly construed as anything other than the sequence
>>>> of 1 to N steps of the (direct execution, x86 emulation or UTM
>>>> simulation of this input by H.
>>>>
>>>> When H directly executes 1 to N steps of its actual input this
>>>> conclusively proves that this is the correct direct execution basis
>>>> for the halt decider's halt status decision. The simulation of this
>>>> same input derives the exact same sequence of steps.
>>>>
>>>> The point in the sequence of 1 to N steps where the execution trace
>>>> of the simulation of P shows that P is about to call H(P,P) again
>>>> with the same input that H was called with provides conclusive proof
>>>> that P would be infinitely recursive unless H aborted its simulation.
>>>>
>>>> When P(P) calls H(P,P) reaches the above point in its simulation it
>>>> returns 0 to P.
>>>>
>>>> H is a computable function that accepts or rejects inputs in its
>>>> domain on the basis that these inputs specify a sequence of
>>>> configurations that reach their final state.
>>>
>>> You seem determined not to learn.
>>>
>>> H is a computer program, *not* a computable function.
>>>
>>> If it is a halt decider, it computes the halting function.
>>>
>>
>> If it is a decider then if maps finite strings to accept / reject states.
>
> Yes, and in doing so it computes the halting function.
>
>>> The domain of the halting function is the set of all computations.
>>>
>>
>> This is too abstract and you know it.
>> A halt decider maps finite string pairs to accept / reject states.
>
> And those strings consist of descriptions of a computation,
> appropriately encoded for your particular halt decider.
>
>>> Therefore, the domain of H is the same, appropriately encoded as
>>> strings.
>>>
>>> P(P) is a computation, therefore it is in the domain of H.
>>>
>>> P(P) halts, therefore H(P, P) must return true.
>>>
>>
>> You keep insisting on a leap of logic. For H(x,y) the pair of finite
>> strings (x,y) must be transformed into a sequence of configurations by
>> a specific algorithm.
>
> No, it doesn't. That's the implementational path you've chosen to take,
> but the problem doesn't specify this.
>
>> Simply saying that this is whatever sequence is specified by the
>> direct execution of P(P) is too vague.
>
> There's nothing vague about this at all.
>
>> The input to H(x,y) is transformed into a sequence of configurations
>> by the (direct execution, x86 emulation or UTM simulation) of this
>> (x,y) input by H.
>
> You are extremely confused here. You keep referring to
> *implementational* details of your H as if they were somehow part of the
> halting problem.
>
> The halting problem is defined as follows. Note this is a definition, so
> it isn't open to debate.
>
> A halt decider H is a turing machine which decides for any arbitrary
> computation M(I) whether that computation will halt. In your
> terminology, that means whether int main { M(I); } halts. [This last bit
> isn't usually specified since computations by definition are
> *indendepent* entities and you are the only one who gets confused by this].
>
> The input to H is a string which encodes M and a string which encodes I.
>
> Note that nothing in the above statement of the problem mentions
> anything about 'sequences of configurations' or the (direct execution,
> x86 emulation or UTM simulation) of the input by H. These are *YOUR*
> additions which have nothing to do with the actual definition of the
> problem.
>

computable function
Computable functions are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given an input of the function domain it can return the
corresponding output. https://en.wikipedia.org/wiki/Computable_function

an algorithm that can do the job of the function,
an algorithm that can do the job of the function,
an algorithm that can do the job of the function,
an algorithm that can do the job of the function,

given an input ... it can return the corresponding output.
given an input ... it can return the corresponding output.
given an input ... it can return the corresponding output.
given an input ... it can return the corresponding output.

Given a finite string pair (x,y) every configuration
from x.q0, x.q1, x.q2, x.qn ... x.final must be shown.

The actual TM description quintuple for each configuration must be
explicitly shown: http://www.lns.mit.edu/~dsw/turing/examples/add10.tm

It is only vagueness that has kept the truth hidden for so many years.
I use x86 because it has zero vagueness.

If you can not specify a 100% perfectly precise algorithm that lists the
actual quintuple for x.q0, x.q1, x.q2, x.qn ... x.final for H(x,y)
you are only talking about vague abstractions.

When you say whatever it is that x(y) actually does
you are only talking about vague abstractions.

> Since P(P) is a computation it must be possible to represent this as a
> concatenation of strings which can be passed to H as an input.
>
> Since P(P) halts, H must return 1 for this particular input.
>
> If your H cannot properly interpret the representation of P(P) as
> representing the *independent* computation P(P), then your
> implementation fails to meet the definition of the problem.
>
> If your H cannot properly determine that P(P) halts, then your
> implementation fails to meet the definition of the problem.
>
> The fact that your H is unable to meet these specifications doesn't
> *change* what these specifications are. The problem is what it is. The
> definition of halt decider is what it is. You can't fiddle with these
> definitions just because you can't figure out how to solve the actual
> question specified by the problem.
>
> The halting function is simply not computable, so you'll never be able
> to create an H which actually gets all cases right.
>
> André
>

--
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/25/21 9:28 PM, olcott wrote:
> On 11/25/2021 6:46 PM, André G. Isaak wrote:
>> On 2021-11-25 16:56, olcott wrote:
>>> On 11/25/2021 2:00 PM, André G. Isaak wrote:
>>>> On 2021-11-25 12:29, olcott wrote:
>>>>> #include <stdint.h>
>>>>> #include <stdio.h>
>>>>> typedef int (*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
>>>>> int P(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>>    return 1; // Give P a last instruction at the "c" level
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>>    H(P, P);
>>>>> }
>>>>>
>>>>> The above program is obviously infinitely recursive. It is self
>>>>> evident that when 0 to ∞ steps of the input to H(P,P) are directly
>>>>> executed or correctly simulated that the input to H(P,P) never
>>>>> reaches its final instruction.
>>>>>
>>>>> PSR set (pathological self-reference)
>>>>> H1(P1,P1) Is the above code.
>>>>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>>>>> executes its input.
>>>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>>>
>>>>> <rewrite>
>>>>> Every Hn(Px,Py) that returns a value returns 1 except for instances
>>>>> of {H3, H4} that determine whether or not to return {0,1} on the
>>>>> basis of the behavior of their input.
>>>>> </rewrite>
>>>>>
>>>>> The sequence of 1 to N configurations specified by the input to
>>>>> H(X, Y) cannot be correctly construed as anything other than the
>>>>> sequence of 1 to N steps of the (direct execution, x86 emulation or
>>>>> UTM simulation of this input by H.
>>>>>
>>>>> When H directly executes 1 to N steps of its actual input this
>>>>> conclusively proves that this is the correct direct execution basis
>>>>> for the halt decider's halt status decision. The simulation of this
>>>>> same input derives the exact same sequence of steps.
>>>>>
>>>>> The point in the sequence of 1 to N steps where the execution trace
>>>>> of the simulation of P shows that P is about to call H(P,P) again
>>>>> with the same input that H was called with provides conclusive
>>>>> proof that P would be infinitely recursive unless H aborted its
>>>>> simulation.
>>>>>
>>>>> When P(P) calls H(P,P) reaches the above point in its simulation it
>>>>> returns 0 to P.
>>>>>
>>>>> H is a computable function that accepts or rejects inputs in its
>>>>> domain on the basis that these inputs specify a sequence of
>>>>> configurations that reach their final state.
>>>>
>>>> You seem determined not to learn.
>>>>
>>>> H is a computer program, *not* a computable function.
>>>>
>>>> If it is a halt decider, it computes the halting function.
>>>>
>>>
>>> If it is a decider then if maps finite strings to accept / reject
>>> states.
>>
>> Yes, and in doing so it computes the halting function.
>>
>>>> The domain of the halting function is the set of all computations.
>>>>
>>>
>>> This is too abstract and you know it.
>>> A halt decider maps finite string pairs to accept / reject states.
>>
>> And those strings consist of descriptions of a computation,
>> appropriately encoded for your particular halt decider.
>>
>>>> Therefore, the domain of H is the same, appropriately encoded as
>>>> strings.
>>>>
>>>> P(P) is a computation, therefore it is in the domain of H.
>>>>
>>>> P(P) halts, therefore H(P, P) must return true.
>>>>
>>>
>>> You keep insisting on a leap of logic. For H(x,y) the pair of finite
>>> strings (x,y) must be transformed into a sequence of configurations
>>> by a specific algorithm.
>>
>> No, it doesn't. That's the implementational path you've chosen to
>> take, but the problem doesn't specify this.
>>
>>> Simply saying that this is whatever sequence is specified by the
>>> direct execution of P(P) is too vague.
>>
>> There's nothing vague about this at all.
>>
>>> The input to H(x,y) is transformed into a sequence of configurations
>>> by the (direct execution, x86 emulation or UTM simulation) of this
>>> (x,y) input by H.
>>
>> You are extremely confused here. You keep referring to
>> *implementational* details of your H as if they were somehow part of
>> the halting problem.
>>
>> The halting problem is defined as follows. Note this is a definition,
>> so it isn't open to debate.
>>
>> A halt decider H is a turing machine which decides for any arbitrary
>> computation M(I) whether that computation will halt. In your
>> terminology, that means whether int main { M(I); } halts. [This last
>> bit isn't usually specified since computations by definition are
>> *indendepent* entities and you are the only one who gets confused by
>> this].
>>
>> The input to H is a string which encodes M and a string which encodes I.
>>
>> Note that nothing in the above statement of the problem mentions
>> anything about 'sequences of configurations' or the (direct execution,
>> x86 emulation or UTM simulation) of the input by H. These are *YOUR*
>> additions which have nothing to do with the actual definition of the
>> problem.
>>
>
> computable function
> Computable functions are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given an input of the function domain it can return the
> corresponding output. https://en.wikipedia.org/wiki/Computable_function
>
> an algorithm that can do the job of the function,
> an algorithm that can do the job of the function,
> an algorithm that can do the job of the function,
> an algorithm that can do the job of the function,
>

Right, 'do the job' not 'is'

A Function is computatable if their exist a anlgorithm that can 'do the
job' of the function.

I.E if an algorithm can compute all the elements of the mapping.

being able to compute is not being the mapping, which is what the
function is.

> given an input ... it can return the corresponding output.
> given an input ... it can return the corresponding output.
> given an input ... it can return the corresponding output.
> given an input ... it can return the corresponding output.

Right. return the corresponding output, not IS the mapping.

You just don't know the technical meaning of the words.

>
> Given a finite string pair (x,y) every configuration
> from x.q0, x.q1, x.q2, x.qn ... x.final must be shown.
>
> The actual TM description quintuple for each configuration must be
> explicitly shown: http://www.lns.mit.edu/~dsw/turing/examples/add10.tm
>

> It is only vagueness that has kept the truth hidden for so many years.
> I use x86 because it has zero vagueness.

What is vague about that.

>
> If you can not specify a 100% perfectly precise algorithm that lists the
> actual quintuple for x.q0, x.q1, x.q2, x.qn ... x.final for H(x,y)
> you are only talking about vague abstractions.

But if you have actually designed the Turing Machine, you have exactly that.

For each of the STATES the Turing Machine can be in, you list for all
the possible input symbols, what the machine will do for THAT state.

Do you somehow think that is a TRACE of the execution path of the machine?

On 2021-11-25 19:28, olcott wrote:
> On 11/25/2021 6:46 PM, André G. Isaak wrote:
>> On 2021-11-25 16:56, olcott wrote:
>>> On 11/25/2021 2:00 PM, André G. Isaak wrote:
>>>> On 2021-11-25 12:29, olcott wrote:
>>>>> #include <stdint.h>
>>>>> #include <stdio.h>
>>>>> typedef int (*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
>>>>> int P(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>>    return 1; // Give P a last instruction at the "c" level
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>>    H(P, P);
>>>>> }
>>>>>
>>>>> The above program is obviously infinitely recursive. It is self
>>>>> evident that when 0 to ∞ steps of the input to H(P,P) are directly
>>>>> executed or correctly simulated that the input to H(P,P) never
>>>>> reaches its final instruction.
>>>>>
>>>>> PSR set (pathological self-reference)
>>>>> H1(P1,P1) Is the above code.
>>>>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>>>>> executes its input.
>>>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>>>
>>>>> <rewrite>
>>>>> Every Hn(Px,Py) that returns a value returns 1 except for instances
>>>>> of {H3, H4} that determine whether or not to return {0,1} on the
>>>>> basis of the behavior of their input.
>>>>> </rewrite>
>>>>>
>>>>> The sequence of 1 to N configurations specified by the input to
>>>>> H(X, Y) cannot be correctly construed as anything other than the
>>>>> sequence of 1 to N steps of the (direct execution, x86 emulation or
>>>>> UTM simulation of this input by H.
>>>>>
>>>>> When H directly executes 1 to N steps of its actual input this
>>>>> conclusively proves that this is the correct direct execution basis
>>>>> for the halt decider's halt status decision. The simulation of this
>>>>> same input derives the exact same sequence of steps.
>>>>>
>>>>> The point in the sequence of 1 to N steps where the execution trace
>>>>> of the simulation of P shows that P is about to call H(P,P) again
>>>>> with the same input that H was called with provides conclusive
>>>>> proof that P would be infinitely recursive unless H aborted its
>>>>> simulation.
>>>>>
>>>>> When P(P) calls H(P,P) reaches the above point in its simulation it
>>>>> returns 0 to P.
>>>>>
>>>>> H is a computable function that accepts or rejects inputs in its
>>>>> domain on the basis that these inputs specify a sequence of
>>>>> configurations that reach their final state.
>>>>
>>>> You seem determined not to learn.
>>>>
>>>> H is a computer program, *not* a computable function.
>>>>
>>>> If it is a halt decider, it computes the halting function.
>>>>
>>>
>>> If it is a decider then if maps finite strings to accept / reject
>>> states.
>>
>> Yes, and in doing so it computes the halting function.
>>
>>>> The domain of the halting function is the set of all computations.
>>>>
>>>
>>> This is too abstract and you know it.
>>> A halt decider maps finite string pairs to accept / reject states.
>>
>> And those strings consist of descriptions of a computation,
>> appropriately encoded for your particular halt decider.
>>
>>>> Therefore, the domain of H is the same, appropriately encoded as
>>>> strings.
>>>>
>>>> P(P) is a computation, therefore it is in the domain of H.
>>>>
>>>> P(P) halts, therefore H(P, P) must return true.
>>>>
>>>
>>> You keep insisting on a leap of logic. For H(x,y) the pair of finite
>>> strings (x,y) must be transformed into a sequence of configurations
>>> by a specific algorithm.
>>
>> No, it doesn't. That's the implementational path you've chosen to
>> take, but the problem doesn't specify this.
>>
>>> Simply saying that this is whatever sequence is specified by the
>>> direct execution of P(P) is too vague.
>>
>> There's nothing vague about this at all.
>>
>>> The input to H(x,y) is transformed into a sequence of configurations
>>> by the (direct execution, x86 emulation or UTM simulation) of this
>>> (x,y) input by H.
>>
>> You are extremely confused here. You keep referring to
>> *implementational* details of your H as if they were somehow part of
>> the halting problem.
>>
>> The halting problem is defined as follows. Note this is a definition,
>> so it isn't open to debate.
>>
>> A halt decider H is a turing machine which decides for any arbitrary
>> computation M(I) whether that computation will halt. In your
>> terminology, that means whether int main { M(I); } halts. [This last
>> bit isn't usually specified since computations by definition are
>> *indendepent* entities and you are the only one who gets confused by
>> this].
>>
>> The input to H is a string which encodes M and a string which encodes I.
>>
>> Note that nothing in the above statement of the problem mentions
>> anything about 'sequences of configurations' or the (direct execution,
>> x86 emulation or UTM simulation) of the input by H. These are *YOUR*
>> additions which have nothing to do with the actual definition of the
>> problem.
>>
>
> computable function
> Computable functions are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given an input of the function domain it can return the
> corresponding output. https://en.wikipedia.org/wiki/Computable_function
>
> an algorithm that can do the job of the function,
> an algorithm that can do the job of the function,
> an algorithm that can do the job of the function,
> an algorithm that can do the job of the function,
>
> given an input ... it can return the corresponding output.
> given an input ... it can return the corresponding output.
> given an input ... it can return the corresponding output.
> given an input ... it can return the corresponding output.

Is there some reason why you are quoting the above, let alone quoting it
five times? Does it have something to do with something I said? If so, what?

An algorithm computes a function. An algorithm is not the function it
computes. A given function may have many different algorithms which can
compute it. Or it might have none.

> Given a finite string pair (x,y) every configuration
> from x.q0, x.q1, x.q2, x.qn ... x.final must be shown.
>
> The actual TM description quintuple for each configuration must be
> explicitly shown: http://www.lns.mit.edu/~dsw/turing/examples/add10.tm

That's exactly what the input string describes: it encodes a Turing
Machine and an input string. It does *not* encode a 'sequence of
configurations'. The TM description includes a *set* of quintuples
representing state transitions. A set is *not* a sequence.

> It is only vagueness that has kept the truth hidden for so many years.
> I use x86 because it has zero vagueness.

Which vagueness?

> If you can not specify a 100% perfectly precise algorithm that lists the
> actual quintuple for x.q0, x.q1, x.q2, x.qn ... x.final for H(x,y)
> you are only talking about vague abstractions.
>
> When you say whatever it is that x(y) actually does
> you are only talking about vague abstractions.

Do you not understand the difference between a SPECIFICATION and an
IMPLEMENTATION?

On 11/25/2021 9:15 PM, André G. Isaak wrote:
> On 2021-11-25 19:28, olcott wrote:
>> On 11/25/2021 6:46 PM, André G. Isaak wrote:
>>> On 2021-11-25 16:56, olcott wrote:
>>>> On 11/25/2021 2:00 PM, André G. Isaak wrote:
>>>>> On 2021-11-25 12:29, olcott wrote:
>>>>>> #include <stdint.h>
>>>>>> #include <stdio.h>
>>>>>> typedef int (*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
>>>>>> int P(ptr x)
>>>>>> {
>>>>>>    H(x, x);
>>>>>>    return 1; // Give P a last instruction at the "c" level
>>>>>> }
>>>>>>
>>>>>> int main(void)
>>>>>> {
>>>>>>    H(P, P);
>>>>>> }
>>>>>>
>>>>>> The above program is obviously infinitely recursive. It is self
>>>>>> evident that when 0 to ∞ steps of the input to H(P,P) are directly
>>>>>> executed or correctly simulated that the input to H(P,P) never
>>>>>> reaches its final instruction.
>>>>>>
>>>>>> PSR set (pathological self-reference)
>>>>>> H1(P1,P1) Is the above code.
>>>>>> H2(P2,P2) Is the above code where H2 simulates rather than
>>>>>> directly executes its input.
>>>>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>>>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>>>>
>>>>>> <rewrite>
>>>>>> Every Hn(Px,Py) that returns a value returns 1 except for
>>>>>> instances of {H3, H4} that determine whether or not to return
>>>>>> {0,1} on the basis of the behavior of their input.
>>>>>> </rewrite>
>>>>>>
>>>>>> The sequence of 1 to N configurations specified by the input to
>>>>>> H(X, Y) cannot be correctly construed as anything other than the
>>>>>> sequence of 1 to N steps of the (direct execution, x86 emulation
>>>>>> or UTM simulation of this input by H.
>>>>>>
>>>>>> When H directly executes 1 to N steps of its actual input this
>>>>>> conclusively proves that this is the correct direct execution
>>>>>> basis for the halt decider's halt status decision. The simulation
>>>>>> of this same input derives the exact same sequence of steps.
>>>>>>
>>>>>> The point in the sequence of 1 to N steps where the execution
>>>>>> trace of the simulation of P shows that P is about to call H(P,P)
>>>>>> again with the same input that H was called with provides
>>>>>> conclusive proof that P would be infinitely recursive unless H
>>>>>> aborted its simulation.
>>>>>>
>>>>>> When P(P) calls H(P,P) reaches the above point in its simulation
>>>>>> it returns 0 to P.
>>>>>>
>>>>>> H is a computable function that accepts or rejects inputs in its
>>>>>> domain on the basis that these inputs specify a sequence of
>>>>>> configurations that reach their final state.
>>>>>
>>>>> You seem determined not to learn.
>>>>>
>>>>> H is a computer program, *not* a computable function.
>>>>>
>>>>> If it is a halt decider, it computes the halting function.
>>>>>
>>>>
>>>> If it is a decider then if maps finite strings to accept / reject
>>>> states.
>>>
>>> Yes, and in doing so it computes the halting function.
>>>
>>>>> The domain of the halting function is the set of all computations.
>>>>>
>>>>
>>>> This is too abstract and you know it.
>>>> A halt decider maps finite string pairs to accept / reject states.
>>>
>>> And those strings consist of descriptions of a computation,
>>> appropriately encoded for your particular halt decider.
>>>
>>>>> Therefore, the domain of H is the same, appropriately encoded as
>>>>> strings.
>>>>>
>>>>> P(P) is a computation, therefore it is in the domain of H.
>>>>>
>>>>> P(P) halts, therefore H(P, P) must return true.
>>>>>
>>>>
>>>> You keep insisting on a leap of logic. For H(x,y) the pair of finite
>>>> strings (x,y) must be transformed into a sequence of configurations
>>>> by a specific algorithm.
>>>
>>> No, it doesn't. That's the implementational path you've chosen to
>>> take, but the problem doesn't specify this.
>>>
>>>> Simply saying that this is whatever sequence is specified by the
>>>> direct execution of P(P) is too vague.
>>>
>>> There's nothing vague about this at all.
>>>
>>>> The input to H(x,y) is transformed into a sequence of configurations
>>>> by the (direct execution, x86 emulation or UTM simulation) of this
>>>> (x,y) input by H.
>>>
>>> You are extremely confused here. You keep referring to
>>> *implementational* details of your H as if they were somehow part of
>>> the halting problem.
>>>
>>> The halting problem is defined as follows. Note this is a definition,
>>> so it isn't open to debate.
>>>
>>> A halt decider H is a turing machine which decides for any arbitrary
>>> computation M(I) whether that computation will halt. In your
>>> terminology, that means whether int main { M(I); } halts. [This last
>>> bit isn't usually specified since computations by definition are
>>> *indendepent* entities and you are the only one who gets confused by
>>> this].
>>>
>>> The input to H is a string which encodes M and a string which encodes I.
>>>
>>> Note that nothing in the above statement of the problem mentions
>>> anything about 'sequences of configurations' or the (direct
>>> execution, x86 emulation or UTM simulation) of the input by H. These
>>> are *YOUR* additions which have nothing to do with the actual
>>> definition of the problem.
>>>
>>
>> computable function
>> Computable functions are the basic objects of study in computability
>> theory. Computable functions are the formalized analogue of the
>> intuitive notion of algorithms, in the sense that a function is
>> computable if there exists an algorithm that can do the job of the
>> function, i.e. given an input of the function domain it can return the
>> corresponding output. https://en.wikipedia.org/wiki/Computable_function
>>
>> an algorithm that can do the job of the function,
>> an algorithm that can do the job of the function,
>> an algorithm that can do the job of the function,
>> an algorithm that can do the job of the function,
>>
>> given an input ... it can return the corresponding output.
>> given an input ... it can return the corresponding output.
>> given an input ... it can return the corresponding output.
>> given an input ... it can return the corresponding output.
>
> Is there some reason why you are quoting the above, let alone quoting it
> five times? Does it have something to do with something I said? If so,
> what?
>
> An algorithm computes a function. An algorithm is not the function it
> computes. A given function may have many different algorithms which can
> compute it. Or it might have none.
>
>> Given a finite string pair (x,y) every configuration
>> from x.q0, x.q1, x.q2, x.qn ... x.final must be shown.
>>
>> The actual TM description quintuple for each configuration must be
>> explicitly shown: http://www.lns.mit.edu/~dsw/turing/examples/add10.tm
>
> That's exactly what the input string describes: it encodes a Turing
> Machine and an input string. It does *not* encode a 'sequence of
> configurations'. The TM description includes a *set* of quintuples
> representing state transitions. A set is *not* a sequence.
>
>> It is only vagueness that has kept the truth hidden for so many years.
>> I use x86 because it has zero vagueness.
>
> Which vagueness?
>
>> If you can not specify a 100% perfectly precise algorithm that lists
>> the actual quintuple for x.q0, x.q1, x.q2, x.qn ... x.final for H(x,y)
>> you are only talking about vague abstractions.
>>
>> When you say whatever it is that x(y) actually does
>> you are only talking about vague abstractions.
>
> Do you not understand the difference between a SPECIFICATION and an
> IMPLEMENTATION?
>
> I have been giving you the specification of the halting problem, i.e. a
> description of *exactly* which problem a halt decider must solve. How
> you go about solving it is the implementation.
>

On 2021-11-25 21:23, olcott wrote:
> On 11/25/2021 9:15 PM, André G. Isaak wrote:

>> Do you not understand the difference between a SPECIFICATION and an
>> IMPLEMENTATION?
>>
>> I have been giving you the specification of the halting problem, i.e.
>> a description of *exactly* which problem a halt decider must solve.
>> How you go about solving it is the implementation.
>>
>
> The halt decider H(x,y) does not simply take a pair of finite string
> inputs and then make a good guess about whether this input reaches its
> final state or not.

Nobody ever claimed otherwise. However, it must do this in a way that
actually conforms to the specification of the problem given below. That
means that if the input is a description of P(P), it must map to 'halts'.

You keep accusing people of 'vagueness' for not specifying these steps,
but bear in mind that Linz's H and H_Hat, aren't Turing Machines, they
are *variables* ranging over classes of Turing Machines, and the whole
point of his proof is to show that those classes are *empty*. You can't
specify the specific steps involved in a nonexistent computation.

You're the one who claims that it actually is possible to create such a
program despite the existence of proofs (note the plural) that the
halting function is not computable. So the onus is on you to actually
provide this 'sequence of configurations', not on anyone else.

But so far all you've done is created a program which fails to meet the
specification which defines the problem that you purport to have solved
and thus which fails to demonstrate such an algorithm.

André

> It must proceed through what is essentially a formal proof of the
> behavior of this finite string pair.
>
> This formal proof begins at x.q0 the start state and proceeds
> through a sequence of quintuple configurations until N steps of
> configurations have been specified.
>
> N is either the final state of x.final or the number of steps required
> for H to detect an infinite behavior pattern.
>
>> The SPECIFICATION of the problem is that a halt decider takes as its
>> input a description of a computation and determines whether that
>> computation, when run independently, halts.
>>
>> P(P) halts, so by the specification of the problem any halt decider
>> which is passed a string representing P(P) *must* return true as its
>> answer. Any "halt decider" which fails to do this fails to implement
>> the specification.
>>
>> All your nonsense about what P(P) does "inside H" is just that --
>> nonsense, because the specification clearly states that the decider
>> must describe the behaviour of P(P) as an independent computation.
>>
>> If you don't grasp the distinction between a specification and an
>> implementation, read the C Standard. It describes the standard library
>> functions and gives a *specification* of what each function must do.
>> The actual implementation of these routines varies depending on your
>> IDE and operating system.
>>
>>
>
>

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

On 11/25/2021 10:35 PM, André G. Isaak wrote:
> On 2021-11-25 21:23, olcott wrote:
>> On 11/25/2021 9:15 PM, André G. Isaak wrote:
>
>>> Do you not understand the difference between a SPECIFICATION and an
>>> IMPLEMENTATION?
>>>
>>> I have been giving you the specification of the halting problem, i.e.
>>> a description of *exactly* which problem a halt decider must solve.
>>> How you go about solving it is the implementation.
>>>
>>
>> The halt decider H(x,y) does not simply take a pair of finite string
>> inputs and then make a good guess about whether this input reaches its
>> final state or not.
>
> Nobody ever claimed otherwise. However, it must do this in a way that
> actually conforms to the specification of the problem given below. That
> means that if the input is a description of P(P), it must map to 'halts'.
>

Halt decider H must derive a formal proof of the behavior of (x,y) based
on the sequence of configurations from x.q0 to x.qn.

> You keep accusing people of 'vagueness' for not specifying these steps,
> but bear in mind that Linz's H and H_Hat, aren't Turing Machines, they
> are *variables* ranging over classes of Turing Machines, and the whole
> point of his proof is to show that those classes are *empty*. You can't
> specify the specific steps involved in a nonexistent computation.
>

That is why I derived the 100% complete specificity of H/P.
My H/P <is> the (Strachey:1965) T/P

rec routine P
§L:if T[P] go to L
Return §

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

H(P,P) derives its formal proof of the behavior of its input based on
the x86 emulation of the machine code of its input from the start state
of P though N steps of P.

That you expect H to somehow imagine what you mean by the direct
execution of P(P) is ridiculous.

It is a formal proof that already has every single step completely
specified.

> You're the one who claims that it actually is possible to create such a
> program despite the existence of proofs (note the plural) that the
> halting function is not computable. So the onus is on you to actually
> provide this 'sequence of configurations', not on anyone else.
>
> But so far all you've done is created a program which fails to meet the
> specification which defines the problem that you purport to have solved
> and thus which fails to demonstrate such an algorithm.
>
> André
>
>> It must proceed through what is essentially a formal proof of the
>> behavior of this finite string pair.
>>
>> This formal proof begins at x.q0 the start state and proceeds
>> through a sequence of quintuple configurations until N steps of
>> configurations have been specified.
>>
>> N is either the final state of x.final or the number of steps required
>> for H to detect an infinite behavior pattern.
>>
>>> The SPECIFICATION of the problem is that a halt decider takes as its
>>> input a description of a computation and determines whether that
>>> computation, when run independently, halts.
>>>
>>> P(P) halts, so by the specification of the problem any halt decider
>>> which is passed a string representing P(P) *must* return true as its
>>> answer. Any "halt decider" which fails to do this fails to implement
>>> the specification.
>>>
>>> All your nonsense about what P(P) does "inside H" is just that --
>>> nonsense, because the specification clearly states that the decider
>>> must describe the behaviour of P(P) as an independent computation.
>>>
>>> If you don't grasp the distinction between a specification and an
>>> implementation, read the C Standard. It describes the standard
>>> library functions and gives a *specification* of what each function
>>> must do. The actual implementation of these routines varies depending
>>> on your IDE and operating system.
>>>
>>>
>>
>>
>
>

--
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 2021-11-25 22:06, olcott wrote:
> On 11/25/2021 10:35 PM, André G. Isaak wrote:
>> On 2021-11-25 21:23, olcott wrote:
>>> On 11/25/2021 9:15 PM, André G. Isaak wrote:
>>
>>>> Do you not understand the difference between a SPECIFICATION and an
>>>> IMPLEMENTATION?
>>>>
>>>> I have been giving you the specification of the halting problem,
>>>> i.e. a description of *exactly* which problem a halt decider must
>>>> solve. How you go about solving it is the implementation.
>>>>
>>>
>>> The halt decider H(x,y) does not simply take a pair of finite string
>>> inputs and then make a good guess about whether this input reaches
>>> its final state or not.
>>
>> Nobody ever claimed otherwise. However, it must do this in a way that
>> actually conforms to the specification of the problem given below.
>> That means that if the input is a description of P(P), it must map to
>> 'halts'.
>>
>
> Halt decider H must derive a formal proof of the behavior of (x,y) based
> on the sequence of configurations from x.q0 to x.qn.

No.

A halt decider accepts or rejects a computation based on whether it
halts. It doesn't derive a formal proof, anymore than a program which
adds two numbers derives a formal proof. It just returns a sum.

>> You keep accusing people of 'vagueness' for not specifying these
>> steps, but bear in mind that Linz's H and H_Hat, aren't Turing
>> Machines, they are *variables* ranging over classes of Turing
>> Machines, and the whole point of his proof is to show that those
>> classes are *empty*. You can't specify the specific steps involved in
>> a nonexistent computation.
>>
>
> That is why I derived the 100% complete specificity of H/P.
> My H/P <is> the (Strachey:1965) T/P
>
>       rec routine P
>         §L:if T[P] go to L
>           Return §
>
> 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

How is Stratchey's code any more 'completely specified' than Linz? He
simply describes what T *does*. He doesn't provide a single line of code
describing how it does it. Just as in the Linz proof, his T is a
*variable* ranging over an (empty) class of programs.

> H(P,P) derives its formal proof of the behavior of its input based on
> the x86 emulation of the machine code of its input from the start state
> of P though N steps of P.
>
> That you expect H to somehow imagine what you mean by the direct
> execution of P(P) is ridiculous.

What I mean by 'the direct execution of P(P)' is completely unambiguous
and is part of the halting problem's specification. H doesn't have to
imagine anything. YOU, as the programmer, have to ensure that the answer
it gives reflects the behaviour of int main { P(P); } since that is how
the halting problem is DEFINED.

> It is a formal proof that already has every single step completely
> specified.

Where is this 'formal proof' of which you speak?

Do you even know what a formal proof is?

André

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

On 11/25/2021 11:49 PM, André G. Isaak wrote:
> On 2021-11-25 22:06, olcott wrote:
>> On 11/25/2021 10:35 PM, André G. Isaak wrote:
>>> On 2021-11-25 21:23, olcott wrote:
>>>> On 11/25/2021 9:15 PM, André G. Isaak wrote:
>>>
>>>>> Do you not understand the difference between a SPECIFICATION and an
>>>>> IMPLEMENTATION?
>>>>>
>>>>> I have been giving you the specification of the halting problem,
>>>>> i.e. a description of *exactly* which problem a halt decider must
>>>>> solve. How you go about solving it is the implementation.
>>>>>
>>>>
>>>> The halt decider H(x,y) does not simply take a pair of finite string
>>>> inputs and then make a good guess about whether this input reaches
>>>> its final state or not.
>>>
>>> Nobody ever claimed otherwise. However, it must do this in a way that
>>> actually conforms to the specification of the problem given below.
>>> That means that if the input is a description of P(P), it must map to
>>> 'halts'.
>>>
>>
>> Halt decider H must derive a formal proof of the behavior of (x,y)
>> based on the sequence of configurations from x.q0 to x.qn.
>
> No.
>
> A halt decider accepts or rejects a computation based on whether it
> halts. It doesn't derive a formal proof, anymore than a program which
> adds two numbers derives a formal proof. It just returns a sum.
>
>>> You keep accusing people of 'vagueness' for not specifying these
>>> steps, but bear in mind that Linz's H and H_Hat, aren't Turing
>>> Machines, they are *variables* ranging over classes of Turing
>>> Machines, and the whole point of his proof is to show that those
>>> classes are *empty*. You can't specify the specific steps involved in
>>> a nonexistent computation.
>>>
>>
>> That is why I derived the 100% complete specificity of H/P.
>> My H/P <is> the (Strachey:1965) T/P
>>
>>        rec routine P
>>          §L:if T[P] go to L
>>            Return §
>>
>> 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
>
> How is Stratchey's code any more 'completely specified' than Linz? He
> simply describes what T *does*. He doesn't provide a single line of code
> describing how it does it. Just as in the Linz proof, his T is a
> *variable* ranging over an (empty) class of programs.
>
>> H(P,P) derives its formal proof of the behavior of its input based on
>> the x86 emulation of the machine code of its input from the start
>> state of P though N steps of P.
>>
>> That you expect H to somehow imagine what you mean by the direct
>> execution of P(P) is ridiculous.
>
> What I mean by 'the direct execution of P(P)' is completely unambiguous
> and is part of the halting problem's specification. H doesn't have to
> imagine anything. YOU, as the programmer, have to ensure that the answer
> it gives reflects the behaviour of int main { P(P); } since that is how
> the halting problem is DEFINED.
>
>> It is a formal proof that already has every single step completely
>> specified.
>
> Where is this 'formal proof' of which you speak?
>

The formal proof that I mean is every single step of the behavior of the
input that leads to the last instruction of this input or some kind of
repeating cycle.

_H()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b450c mov eax,[ebp+0c]
[00001a64](01) 50 push eax // push P
[00001a65](03) ff5508 call dword [ebp+08] // call P
[00001a68](03) 83c404 add esp,+04
[00001a6b](05) b801000000 mov eax,00000001
[00001a70](01) 5d pop ebp
[00001a71](01) c3 ret
Size in bytes:(0020) [00001a71]

_P()
[00001a7e](01) 55 push ebp
[00001a7f](02) 8bec mov ebp,esp
[00001a81](03) 8b4508 mov eax,[ebp+08]
[00001a84](01) 50 push eax // push P
[00001a85](03) 8b4d08 mov ecx,[ebp+08]
[00001a88](01) 51 push ecx // push P
[00001a89](05) e8d0ffffff call 00001a5e // call H
[00001a8e](03) 83c408 add esp,+08
[00001a91](05) b801000000 mov eax,00000001
[00001a96](01) 5d pop ebp
[00001a97](01) c3 ret
Size in bytes:(0026) [00001a97]

_main()
[00001a9e](01) 55 push ebp
[00001a9f](02) 8bec mov ebp,esp
[00001aa1](05) 687e1a0000 push 00001a7e // push P
[00001aa6](05) 687e1a0000 push 00001a7e // push P
[00001aab](05) e8aeffffff call 00001a5e // call H
[00001ab0](03) 83c408 add esp,+08
[00001ab3](02) 33c0 xor eax,eax
[00001ab5](01) 5d pop ebp
[00001ab6](01) c3 ret
Size in bytes:(0025) [00001ab6]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001a9e][00102ec8][00000000] 55 push ebp
[00001a9f][00102ec8][00000000] 8bec mov ebp,esp
[00001aa1][00102ec4][00001a7e] 687e1a0000 push 00001a7e // push P
[00001aa6][00102ec0][00001a7e] 687e1a0000 push 00001a7e // push P
[00001aab][00102ebc][00001ab0] e8aeffffff call 00001a5e // call H
[00001a5e][00102eb8][00102ec8] 55 push ebp
[00001a5f][00102eb8][00102ec8] 8bec mov ebp,esp
[00001a61][00102eb8][00102ec8] 8b450c mov eax,[ebp+0c]
[00001a64][00102eb4][00001a7e] 50 push eax // push P
[00001a65][00102eb0][00001a68] ff5508 call dword [ebp+08] // call P
[00001a7e][00102eac][00102eb8] 55 push ebp
[00001a7f][00102eac][00102eb8] 8bec mov ebp,esp
[00001a81][00102eac][00102eb8] 8b4508 mov eax,[ebp+08]
[00001a84][00102ea8][00001a7e] 50 push eax // push P
[00001a85][00102ea8][00001a7e] 8b4d08 mov ecx,[ebp+08]
[00001a88][00102ea4][00001a7e] 51 push ecx // push P
[00001a89][00102ea0][00001a8e] e8d0ffffff call 00001a5e // call H
[00001a5e][00102e9c][00102eac] 55 push ebp
[00001a5f][00102e9c][00102eac] 8bec mov ebp,esp
[00001a61][00102e9c][00102eac] 8b450c mov eax,[ebp+0c]
[00001a64][00102e98][00001a7e] 50 push eax // push P
[00001a65][00102e94][00001a68] ff5508 call dword [ebp+08] // call P
[00001a7e][00102e90][00102e9c] 55 push ebp
[00001a7f][00102e90][00102e9c] 8bec mov ebp,esp
[00001a81][00102e90][00102e9c] 8b4508 mov eax,[ebp+08]
[00001a84][00102e8c][00001a7e] 50 push eax // push P
[00001a85][00102e8c][00001a7e] 8b4d08 mov ecx,[ebp+08]
[00001a88][00102e88][00001a7e] 51 push ecx
[00001a89][00102e84][00001a8e] e8d0ffffff call 00001a5e // call H
[00001a5e][00102e80][00102e90] 55 push ebp
[00001a5f][00102e80][00102e90] 8bec mov ebp,esp
[00001a61][00102e80][00102e90] 8b450c mov eax,[ebp+0c]
[00001a64][00102e7c][00001a7e] 50 push eax // push P
[00001a65][00102e78][00001a68] ff5508 call dword [ebp+08] // call P
[00001a7e][00102e74][00102e80] 55 push ebp
[00001a7f][00102e74][00102e80] 8bec mov ebp,esp
[00001a81][00102e74][00102e80] 8b4508 mov eax,[ebp+08]
[00001a84][00102e70][00001a7e] 50 push eax // push P
[00001a85][00102e70][00001a7e] 8b4d08 mov ecx,[ebp+08]
[00001a88][00102e6c][00001a7e] 51 push ecx // push P
[00001a89][00102e68][00001a8e] e8d0ffffff call 00001a5e // call H

A turing machine program consists of a list of 'quintuples', each one of
which is a five-symbol turing machine instruction. For example, the
quintuple 'SCcsm' is executed by the machine if it is in state 'S' and
is reading the symbol 'C' on the tape. In that case, the instruction
causes the machine to make a transition to state 's' and to overwrite
the symbol 'C' on the tape with the symbol 'c'. The last operation it
performs under this instruction is to move the tape reading head one
symbol to the left or right according to whether 'm' is 'l' or 'r'.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

The input to H(x,y) is a finite string pair where x is a list of
quintuples of Turing machine instructions and y is a finite string.

The formal proof of the behavior of N steps of x applied to y is the
sequence of configurations derived when a UTM is applied to x on input y
for N steps of configurations.

> Do you even know what a formal proof is?

On 11/26/21 10:29 AM, olcott wrote:
> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>> On 2021-11-25 22:06, olcott wrote:
>>> On 11/25/2021 10:35 PM, André G. Isaak wrote:
>>>> On 2021-11-25 21:23, olcott wrote:
>>>>> On 11/25/2021 9:15 PM, André G. Isaak wrote:
>>>>
>>>>>> Do you not understand the difference between a SPECIFICATION and
>>>>>> an IMPLEMENTATION?
>>>>>>
>>>>>> I have been giving you the specification of the halting problem,
>>>>>> i.e. a description of *exactly* which problem a halt decider must
>>>>>> solve. How you go about solving it is the implementation.
>>>>>>
>>>>>
>>>>> The halt decider H(x,y) does not simply take a pair of finite
>>>>> string inputs and then make a good guess about whether this input
>>>>> reaches its final state or not.
>>>>
>>>> Nobody ever claimed otherwise. However, it must do this in a way
>>>> that actually conforms to the specification of the problem given
>>>> below. That means that if the input is a description of P(P), it
>>>> must map to 'halts'.
>>>>
>>>
>>> Halt decider H must derive a formal proof of the behavior of (x,y)
>>> based on the sequence of configurations from x.q0 to x.qn.
>>
>> No.
>>
>> A halt decider accepts or rejects a computation based on whether it
>> halts. It doesn't derive a formal proof, anymore than a program which
>> adds two numbers derives a formal proof. It just returns a sum.
>>
>>>> You keep accusing people of 'vagueness' for not specifying these
>>>> steps, but bear in mind that Linz's H and H_Hat, aren't Turing
>>>> Machines, they are *variables* ranging over classes of Turing
>>>> Machines, and the whole point of his proof is to show that those
>>>> classes are *empty*. You can't specify the specific steps involved
>>>> in a nonexistent computation.
>>>>
>>>
>>> That is why I derived the 100% complete specificity of H/P.
>>> My H/P <is> the (Strachey:1965) T/P
>>>
>>>        rec routine P
>>>          §L:if T[P] go to L
>>>            Return §
>>>
>>> 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
>>
>> How is Stratchey's code any more 'completely specified' than Linz? He
>> simply describes what T *does*. He doesn't provide a single line of
>> code describing how it does it. Just as in the Linz proof, his T is a
>> *variable* ranging over an (empty) class of programs.
>>
>>> H(P,P) derives its formal proof of the behavior of its input based on
>>> the x86 emulation of the machine code of its input from the start
>>> state of P though N steps of P.
>>>
>>> That you expect H to somehow imagine what you mean by the direct
>>> execution of P(P) is ridiculous.
>>
>> What I mean by 'the direct execution of P(P)' is completely
>> unambiguous and is part of the halting problem's specification. H
>> doesn't have to imagine anything. YOU, as the programmer, have to
>> ensure that the answer it gives reflects the behaviour of int main {
>> P(P); } since that is how the halting problem is DEFINED.
>>
>>> It is a formal proof that already has every single step completely
>>> specified.
>>
>> Where is this 'formal proof' of which you speak?
>>
>
> The formal proof that I mean is every single step of the behavior of the
> input that leads to the last instruction of this input or some kind of
> repeating cycle.
>
> _H()
> [00001a5e](01)  55              push ebp
> [00001a5f](02)  8bec            mov ebp,esp
> [00001a61](03)  8b450c          mov eax,[ebp+0c]
> [00001a64](01)  50              push eax             // push P
> [00001a65](03)  ff5508          call dword [ebp+08]  // call P
> [00001a68](03)  83c404          add esp,+04
> [00001a6b](05)  b801000000      mov eax,00000001
> [00001a70](01)  5d              pop ebp
> [00001a71](01)  c3              ret
> Size in bytes:(0020) [00001a71]
>
> _P()
> [00001a7e](01)  55              push ebp
> [00001a7f](02)  8bec            mov ebp,esp
> [00001a81](03)  8b4508          mov eax,[ebp+08]
> [00001a84](01)  50              push eax       // push P
> [00001a85](03)  8b4d08          mov ecx,[ebp+08]
> [00001a88](01)  51              push ecx       // push P
> [00001a89](05)  e8d0ffffff      call 00001a5e  // call H
> [00001a8e](03)  83c408          add esp,+08
> [00001a91](05)  b801000000      mov eax,00000001
> [00001a96](01)  5d              pop ebp
> [00001a97](01)  c3              ret
> Size in bytes:(0026) [00001a97]
>
> _main()
> [00001a9e](01)  55              push ebp
> [00001a9f](02)  8bec            mov ebp,esp
> [00001aa1](05)  687e1a0000      push 00001a7e // push P
> [00001aa6](05)  687e1a0000      push 00001a7e // push P
> [00001aab](05)  e8aeffffff      call 00001a5e // call H
> [00001ab0](03)  83c408          add esp,+08
> [00001ab3](02)  33c0            xor eax,eax
> [00001ab5](01)  5d              pop ebp
> [00001ab6](01)  c3              ret
> Size in bytes:(0025) [00001ab6]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00001a9e][00102ec8][00000000] 55         push ebp
> [00001a9f][00102ec8][00000000] 8bec       mov ebp,esp
> [00001aa1][00102ec4][00001a7e] 687e1a0000 push 00001a7e       // push P
> [00001aa6][00102ec0][00001a7e] 687e1a0000 push 00001a7e       // push P
> [00001aab][00102ebc][00001ab0] e8aeffffff call 00001a5e       // call H
> [00001a5e][00102eb8][00102ec8] 55         push ebp
> [00001a5f][00102eb8][00102ec8] 8bec       mov ebp,esp
> [00001a61][00102eb8][00102ec8] 8b450c     mov eax,[ebp+0c]
> [00001a64][00102eb4][00001a7e] 50         push eax            // push P
> [00001a65][00102eb0][00001a68] ff5508     call dword [ebp+08] // call P
> [00001a7e][00102eac][00102eb8] 55         push ebp
> [00001a7f][00102eac][00102eb8] 8bec       mov ebp,esp
> [00001a81][00102eac][00102eb8] 8b4508     mov eax,[ebp+08]
> [00001a84][00102ea8][00001a7e] 50         push eax            // push P
> [00001a85][00102ea8][00001a7e] 8b4d08     mov ecx,[ebp+08]
> [00001a88][00102ea4][00001a7e] 51         push ecx            // push P
> [00001a89][00102ea0][00001a8e] e8d0ffffff call 00001a5e       // call H
> [00001a5e][00102e9c][00102eac] 55         push ebp
> [00001a5f][00102e9c][00102eac] 8bec       mov ebp,esp
> [00001a61][00102e9c][00102eac] 8b450c     mov eax,[ebp+0c]
> [00001a64][00102e98][00001a7e] 50         push eax            // push P
> [00001a65][00102e94][00001a68] ff5508     call dword [ebp+08] // call P
> [00001a7e][00102e90][00102e9c] 55         push ebp
> [00001a7f][00102e90][00102e9c] 8bec       mov ebp,esp
> [00001a81][00102e90][00102e9c] 8b4508     mov eax,[ebp+08]
> [00001a84][00102e8c][00001a7e] 50         push eax            // push P
> [00001a85][00102e8c][00001a7e] 8b4d08     mov ecx,[ebp+08]
> [00001a88][00102e88][00001a7e] 51         push ecx
> [00001a89][00102e84][00001a8e] e8d0ffffff call 00001a5e       // call H
> [00001a5e][00102e80][00102e90] 55         push ebp
> [00001a5f][00102e80][00102e90] 8bec       mov ebp,esp
> [00001a61][00102e80][00102e90] 8b450c     mov eax,[ebp+0c]
> [00001a64][00102e7c][00001a7e] 50         push eax            // push P
> [00001a65][00102e78][00001a68] ff5508     call dword [ebp+08] // call P
> [00001a7e][00102e74][00102e80] 55         push ebp
> [00001a7f][00102e74][00102e80] 8bec       mov ebp,esp
> [00001a81][00102e74][00102e80] 8b4508     mov eax,[ebp+08]
> [00001a84][00102e70][00001a7e] 50         push eax            // push P
> [00001a85][00102e70][00001a7e] 8b4d08     mov ecx,[ebp+08]
> [00001a88][00102e6c][00001a7e] 51         push ecx            // push P
> [00001a89][00102e68][00001a8e] e8d0ffffff call 00001a5e       // call H

On 11/25/21 11:23 PM, olcott wrote:
> On 11/25/2021 9:15 PM, André G. Isaak wrote:
>> On 2021-11-25 19:28, olcott wrote:
>>> On 11/25/2021 6:46 PM, André G. Isaak wrote:
>>>> On 2021-11-25 16:56, olcott wrote:
>>>>> On 11/25/2021 2:00 PM, André G. Isaak wrote:
>>>>>> On 2021-11-25 12:29, olcott wrote:
>>>>>>> #include <stdint.h>
>>>>>>> #include <stdio.h>
>>>>>>> typedef int (*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
>>>>>>> int P(ptr x)
>>>>>>> {
>>>>>>>    H(x, x);
>>>>>>>    return 1; // Give P a last instruction at the "c" level
>>>>>>> }
>>>>>>>
>>>>>>> int main(void)
>>>>>>> {
>>>>>>>    H(P, P);
>>>>>>> }
>>>>>>>
>>>>>>> The above program is obviously infinitely recursive. It is self
>>>>>>> evident that when 0 to ∞ steps of the input to H(P,P) are
>>>>>>> directly executed or correctly simulated that the input to H(P,P)
>>>>>>> never reaches its final instruction.
>>>>>>>
>>>>>>> PSR set (pathological self-reference)
>>>>>>> H1(P1,P1) Is the above code.
>>>>>>> H2(P2,P2) Is the above code where H2 simulates rather than
>>>>>>> directly executes its input.
>>>>>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>>>>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>>>>>
>>>>>>> <rewrite>
>>>>>>> Every Hn(Px,Py) that returns a value returns 1 except for
>>>>>>> instances of {H3, H4} that determine whether or not to return
>>>>>>> {0,1} on the basis of the behavior of their input.
>>>>>>> </rewrite>
>>>>>>>
>>>>>>> The sequence of 1 to N configurations specified by the input to
>>>>>>> H(X, Y) cannot be correctly construed as anything other than the
>>>>>>> sequence of 1 to N steps of the (direct execution, x86 emulation
>>>>>>> or UTM simulation of this input by H.
>>>>>>>
>>>>>>> When H directly executes 1 to N steps of its actual input this
>>>>>>> conclusively proves that this is the correct direct execution
>>>>>>> basis for the halt decider's halt status decision. The simulation
>>>>>>> of this same input derives the exact same sequence of steps.
>>>>>>>
>>>>>>> The point in the sequence of 1 to N steps where the execution
>>>>>>> trace of the simulation of P shows that P is about to call H(P,P)
>>>>>>> again with the same input that H was called with provides
>>>>>>> conclusive proof that P would be infinitely recursive unless H
>>>>>>> aborted its simulation.
>>>>>>>
>>>>>>> When P(P) calls H(P,P) reaches the above point in its simulation
>>>>>>> it returns 0 to P.
>>>>>>>
>>>>>>> H is a computable function that accepts or rejects inputs in its
>>>>>>> domain on the basis that these inputs specify a sequence of
>>>>>>> configurations that reach their final state.
>>>>>>
>>>>>> You seem determined not to learn.
>>>>>>
>>>>>> H is a computer program, *not* a computable function.
>>>>>>
>>>>>> If it is a halt decider, it computes the halting function.
>>>>>>
>>>>>
>>>>> If it is a decider then if maps finite strings to accept / reject
>>>>> states.
>>>>
>>>> Yes, and in doing so it computes the halting function.
>>>>
>>>>>> The domain of the halting function is the set of all computations.
>>>>>>
>>>>>
>>>>> This is too abstract and you know it.
>>>>> A halt decider maps finite string pairs to accept / reject states.
>>>>
>>>> And those strings consist of descriptions of a computation,
>>>> appropriately encoded for your particular halt decider.
>>>>
>>>>>> Therefore, the domain of H is the same, appropriately encoded as
>>>>>> strings.
>>>>>>
>>>>>> P(P) is a computation, therefore it is in the domain of H.
>>>>>>
>>>>>> P(P) halts, therefore H(P, P) must return true.
>>>>>>
>>>>>
>>>>> You keep insisting on a leap of logic. For H(x,y) the pair of
>>>>> finite strings (x,y) must be transformed into a sequence of
>>>>> configurations by a specific algorithm.
>>>>
>>>> No, it doesn't. That's the implementational path you've chosen to
>>>> take, but the problem doesn't specify this.
>>>>
>>>>> Simply saying that this is whatever sequence is specified by the
>>>>> direct execution of P(P) is too vague.
>>>>
>>>> There's nothing vague about this at all.
>>>>
>>>>> The input to H(x,y) is transformed into a sequence of
>>>>> configurations by the (direct execution, x86 emulation or UTM
>>>>> simulation) of this (x,y) input by H.
>>>>
>>>> You are extremely confused here. You keep referring to
>>>> *implementational* details of your H as if they were somehow part of
>>>> the halting problem.
>>>>
>>>> The halting problem is defined as follows. Note this is a
>>>> definition, so it isn't open to debate.
>>>>
>>>> A halt decider H is a turing machine which decides for any arbitrary
>>>> computation M(I) whether that computation will halt. In your
>>>> terminology, that means whether int main { M(I); } halts. [This last
>>>> bit isn't usually specified since computations by definition are
>>>> *indendepent* entities and you are the only one who gets confused by
>>>> this].
>>>>
>>>> The input to H is a string which encodes M and a string which
>>>> encodes I.
>>>>
>>>> Note that nothing in the above statement of the problem mentions
>>>> anything about 'sequences of configurations' or the (direct
>>>> execution, x86 emulation or UTM simulation) of the input by H. These
>>>> are *YOUR* additions which have nothing to do with the actual
>>>> definition of the problem.
>>>>
>>>
>>> computable function
>>> Computable functions are the basic objects of study in computability
>>> theory. Computable functions are the formalized analogue of the
>>> intuitive notion of algorithms, in the sense that a function is
>>> computable if there exists an algorithm that can do the job of the
>>> function, i.e. given an input of the function domain it can return
>>> the corresponding output.
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>> an algorithm that can do the job of the function,
>>> an algorithm that can do the job of the function,
>>> an algorithm that can do the job of the function,
>>> an algorithm that can do the job of the function,
>>>
>>> given an input ... it can return the corresponding output.
>>> given an input ... it can return the corresponding output.
>>> given an input ... it can return the corresponding output.
>>> given an input ... it can return the corresponding output.
>>
>> Is there some reason why you are quoting the above, let alone quoting
>> it five times? Does it have something to do with something I said? If
>> so, what?
>>
>> An algorithm computes a function. An algorithm is not the function it
>> computes. A given function may have many different algorithms which
>> can compute it. Or it might have none.
>>
>>> Given a finite string pair (x,y) every configuration
>>> from x.q0, x.q1, x.q2, x.qn ... x.final must be shown.
>>>
>>> The actual TM description quintuple for each configuration must be
>>> explicitly shown: http://www.lns.mit.edu/~dsw/turing/examples/add10.tm
>>
>> That's exactly what the input string describes: it encodes a Turing
>> Machine and an input string. It does *not* encode a 'sequence of
>> configurations'. The TM description includes a *set* of quintuples
>> representing state transitions. A set is *not* a sequence.
>>
>>> It is only vagueness that has kept the truth hidden for so many years.
>>> I use x86 because it has zero vagueness.
>>
>> Which vagueness?
>>
>>> If you can not specify a 100% perfectly precise algorithm that lists
>>> the actual quintuple for x.q0, x.q1, x.q2, x.qn ... x.final for H(x,y)
>>> you are only talking about vague abstractions.
>>>
>>> When you say whatever it is that x(y) actually does
>>> you are only talking about vague abstractions.
>>
>> Do you not understand the difference between a SPECIFICATION and an
>> IMPLEMENTATION?
>>
>> I have been giving you the specification of the halting problem, i.e.
>> a description of *exactly* which problem a halt decider must solve.
>> How you go about solving it is the implementation.
>>
>
> The halt decider H(x,y) does not simply take a pair of finite string
> inputs and then make a good guess about whether this input reaches its
> final state or not.
>
> It must proceed through what is essentially a formal proof of the
> behavior of this finite string pair.

On 11/26/21 12:06 AM, olcott wrote:
> On 11/25/2021 10:35 PM, André G. Isaak wrote:
>> On 2021-11-25 21:23, olcott wrote:
>>> On 11/25/2021 9:15 PM, André G. Isaak wrote:
>>
>>>> Do you not understand the difference between a SPECIFICATION and an
>>>> IMPLEMENTATION?
>>>>
>>>> I have been giving you the specification of the halting problem,
>>>> i.e. a description of *exactly* which problem a halt decider must
>>>> solve. How you go about solving it is the implementation.
>>>>
>>>
>>> The halt decider H(x,y) does not simply take a pair of finite string
>>> inputs and then make a good guess about whether this input reaches
>>> its final state or not.
>>
>> Nobody ever claimed otherwise. However, it must do this in a way that
>> actually conforms to the specification of the problem given below.
>> That means that if the input is a description of P(P), it must map to
>> 'halts'.
>>
>
> Halt decider H must derive a formal proof of the behavior of (x,y) based
> on the sequence of configurations from x.q0 to x.qn.
Right, a VALID formal proof. No assuming that H is a real UTM when it isn't.

FAIL.

>
>> You keep accusing people of 'vagueness' for not specifying these
>> steps, but bear in mind that Linz's H and H_Hat, aren't Turing
>> Machines, they are *variables* ranging over classes of Turing
>> Machines, and the whole point of his proof is to show that those
>> classes are *empty*. You can't specify the specific steps involved in
>> a nonexistent computation.
>>
>
> That is why I derived the 100% complete specificity of H/P.
> My H/P <is> the (Strachey:1965) T/P
>
>       rec routine P
>         §L:if T[P] go to L
>           Return §
>
> 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
>
> H(P,P) derives its formal proof of the behavior of its input based on
> the x86 emulation of the machine code of its input from the start state
> of P though N steps of P.
>
> That you expect H to somehow imagine what you mean by the direct
> execution of P(P) is ridiculous.

It doesn't need to imagine what direct execution of P(P) does, it needs
to compute the value it is programed to compute.

'Get the Right Answer' is NOT an algorithm, as this case shows.

The key is that the right answer for the problem it claims to solve can
well be based on stuff that it can not directly see.

'H' doesn't need to 'imagine' anything, it is just a mechanical
computation. The creator of H needs to think about this direct execution
to try to design a correc5 algorithm, one that gives the right answer
even though H can't actually do the possibly infinite operation to find
the direct answer since it needs to answer in finite time.

No program actually 'thinks', it just mechanically computes something.
The programmer creates algorithms that make it look like the program has
some intelligence.

>
> It is a formal proof that already has every single step completely
> specified.

Except that it fails because it presumes that H will be a pure UTM and
not abort its processing, when that is not the behavior of H.

FAIL.

>
>> You're the one who claims that it actually is possible to create such
>> a program despite the existence of proofs (note the plural) that the
>> halting function is not computable. So the onus is on you to actually
>> provide this 'sequence of configurations', not on anyone else.
>>
>> But so far all you've done is created a program which fails to meet
>> the specification which defines the problem that you purport to have
>> solved and thus which fails to demonstrate such an algorithm.
>>
>> André
>>
>>> It must proceed through what is essentially a formal proof of the
>>> behavior of this finite string pair.
>>>
>>> This formal proof begins at x.q0 the start state and proceeds
>>> through a sequence of quintuple configurations until N steps of
>>> configurations have been specified.
>>>
>>> N is either the final state of x.final or the number of steps
>>> required for H to detect an infinite behavior pattern.
>>>
>>>> The SPECIFICATION of the problem is that a halt decider takes as its
>>>> input a description of a computation and determines whether that
>>>> computation, when run independently, halts.
>>>>
>>>> P(P) halts, so by the specification of the problem any halt decider
>>>> which is passed a string representing P(P) *must* return true as its
>>>> answer. Any "halt decider" which fails to do this fails to implement
>>>> the specification.
>>>>
>>>> All your nonsense about what P(P) does "inside H" is just that --
>>>> nonsense, because the specification clearly states that the decider
>>>> must describe the behaviour of P(P) as an independent computation.
>>>>
>>>> If you don't grasp the distinction between a specification and an
>>>> implementation, read the C Standard. It describes the standard
>>>> library functions and gives a *specification* of what each function
>>>> must do. The actual implementation of these routines varies
>>>> depending on your IDE and operating system.
>>>>
>>>>
>>>
>>>
>>
>>
>
>

On 2021-11-26 08:29, olcott wrote:
> On 11/25/2021 11:49 PM, André G. Isaak wrote:

>> Where is this 'formal proof' of which you speak?
>>
>
> The formal proof that I mean is every single step of the behavior of the
> input that leads to the last instruction of this input or some kind of
> repeating cycle.

<snip pointless trace>

That was a *trace*. A trace is no even remotely a formal proof. It is
simply a trace. You should review what a proof actually looks like.

<snip definition of Turing Machine -- we already know what a TM is>

> The input to H(x,y) is a finite string pair where x is a list of
> quintuples of Turing machine instructions and y is a finite string.
>
> The formal proof of the behavior of N steps of x applied to y is the
> sequence of configurations derived when a UTM is applied to x on input y
> for N steps of configurations.
>
>> Do you even know what a formal proof is?
>
> I am defining it more broadly as every inference step in sound deduction
> leading to a true conclusion.

You are 'defining' it in a way which bears no resemblance to the actual
definition of 'proof'. And a trace does not constitute a 'sound
deduction' either, nor does it include 'inference steps'.

There must be some sound deductive reasoning *underlying* an algorithm,
but the algorithm is not the same thing as that reasoning.

And in your case, it clearly doesn't involve sound deductive reasoning
since it gives the *wrong* answer.

H(P, P) is tasked with reporting on whether int main() { P(P); } halts.
That computation does indeed halt. Your H claims otherwise. Therefore it
is wrong.

André

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

On 11/26/2021 10:46 AM, André G. Isaak wrote:
> On 2021-11-26 08:29, olcott wrote:
>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>
>>> Where is this 'formal proof' of which you speak?
>>>
>>
>> The formal proof that I mean is every single step of the behavior of
>> the input that leads to the last instruction of this input or some
>> kind of repeating cycle.
>
> <snip pointless trace>
>
> That was a *trace*. A trace is no even remotely a formal proof. It is
> simply a trace. You should review what a proof actually looks like.
>
> <snip definition of Turing Machine -- we already know what a TM is>
>
>> The input to H(x,y) is a finite string pair where x is a list of
>> quintuples of Turing machine instructions and y is a finite string.
>>
>> The formal proof of the behavior of N steps of x applied to y is the
>> sequence of configurations derived when a UTM is applied to x on input
>> y for N steps of configurations.
>>
>>> Do you even know what a formal proof is?
>>
>> I am defining it more broadly as every inference step in sound
>> deduction leading to a true conclusion.
>
> You are 'defining' it in a way which bears no resemblance to the actual
> definition of 'proof'. And a trace does not constitute a 'sound
> deduction' either, nor does it include 'inference steps'.
>

So you are saying the the correct pure simulation of N steps of the
input to H(P,P) by H has no relationship what-so-ever to the actual
behavior of P(P)?

I say that the correct pure simulation of N steps of the input to H(x,y)
is the only correct halt deciding basis that any C/x86/TM halt decider
can possibly have.

> There must be some sound deductive reasoning *underlying* an algorithm,
> but the algorithm is not the same thing as that reasoning.
>
> And in your case, it clearly doesn't involve sound deductive reasoning
> since it gives the *wrong* answer.
>
> H(P, P) is tasked with reporting on whether int main() { P(P); } halts.
> That computation does indeed halt. Your H claims otherwise. Therefore it
> is wrong.
>
> André
>
>

--
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 2021-11-26 11:40, olcott wrote:
> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>> On 2021-11-26 08:29, olcott wrote:
>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>
>>>> Where is this 'formal proof' of which you speak?
>>>>
>>>
>>> The formal proof that I mean is every single step of the behavior of
>>> the input that leads to the last instruction of this input or some
>>> kind of repeating cycle.
>>
>> <snip pointless trace>
>>
>> That was a *trace*. A trace is no even remotely a formal proof. It is
>> simply a trace. You should review what a proof actually looks like.
>>
>> <snip definition of Turing Machine -- we already know what a TM is>
>>
>>> The input to H(x,y) is a finite string pair where x is a list of
>>> quintuples of Turing machine instructions and y is a finite string.
>>>
>>> The formal proof of the behavior of N steps of x applied to y is the
>>> sequence of configurations derived when a UTM is applied to x on
>>> input y for N steps of configurations.
>>>
>>>> Do you even know what a formal proof is?
>>>
>>> I am defining it more broadly as every inference step in sound
>>> deduction leading to a true conclusion.
>>
>> You are 'defining' it in a way which bears no resemblance to the
>> actual definition of 'proof'. And a trace does not constitute a 'sound
>> deduction' either, nor does it include 'inference steps'.
>>
>
> So you are saying the the correct pure simulation of N steps of the
> input to H(P,P) by H has no relationship what-so-ever to the actual
> behavior of P(P)?
>
> I say that the correct pure simulation of N steps of the input to H(x,y)
> is the only correct halt deciding basis that any C/x86/TM halt decider
> can possibly have.

Obviously it is not a 'correct pure simulation' since it gets the wrong
answer to the question.

You keep ignoring the specification of the problem.

André

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

On 11/26/21 1:40 PM, olcott wrote:
> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>> On 2021-11-26 08:29, olcott wrote:
>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>
>>>> Where is this 'formal proof' of which you speak?
>>>>
>>>
>>> The formal proof that I mean is every single step of the behavior of
>>> the input that leads to the last instruction of this input or some
>>> kind of repeating cycle.
>>
>> <snip pointless trace>
>>
>> That was a *trace*. A trace is no even remotely a formal proof. It is
>> simply a trace. You should review what a proof actually looks like.
>>
>> <snip definition of Turing Machine -- we already know what a TM is>
>>
>>> The input to H(x,y) is a finite string pair where x is a list of
>>> quintuples of Turing machine instructions and y is a finite string.
>>>
>>> The formal proof of the behavior of N steps of x applied to y is the
>>> sequence of configurations derived when a UTM is applied to x on
>>> input y for N steps of configurations.
>>>
>>>> Do you even know what a formal proof is?
>>>
>>> I am defining it more broadly as every inference step in sound
>>> deduction leading to a true conclusion.
>>
>> You are 'defining' it in a way which bears no resemblance to the
>> actual definition of 'proof'. And a trace does not constitute a 'sound
>> deduction' either, nor does it include 'inference steps'.
>>
>
> So you are saying the the correct pure simulation of N steps of the
> input to H(P,P) by H has no relationship what-so-ever to the actual
> behavior of P(P)?

If the N step simulation does not reach a final state, it says NOTHING
about the halting of the machine.

The machine might halt in some M steps, M>N, or it might never stop.

(And you 'logic' makes the false assumption that H never aborts its
simulation and returns, when in fact you do have H abort its simulation
and return).

In fact, we know that for your H and the provided P, that for any H that
ends up aborting its simulation in the computation of H(P,P), and
returning the 0 value after N steps, that the P based on that H will
actually halt in N+k steps, where k is the number of steps in P not
counting the behavior of H that it uses (sum of those before and after
the call).

Thus for you H to be able to get the right answer it needs to simulate
for a value N steps where N > N + k, for k being some positive integer.

There is no such value, so there is no such H.

>
> I say that the correct pure simulation of N steps of the input to H(x,y)
> is the only correct halt deciding basis that any C/x86/TM halt decider
> can possibly have.

WRONG. BY DEFINITION, the correct answer is based on the INFINITE step
simulation of the input.

The fact that H can't do that is irrelevant, that is the correct answer.

All you are doing is showing that the task is, in fact, impossible.

You are making the logical error of ASSUMING, your conclusion.

You are asserting that you can make a correct halt decider by saying you
need to change the rules to make it possible.

FAIL.

>
>> There must be some sound deductive reasoning *underlying* an
>> algorithm, but the algorithm is not the same thing as that reasoning.
>>
>> And in your case, it clearly doesn't involve sound deductive reasoning
>> since it gives the *wrong* answer.
>>
>> H(P, P) is tasked with reporting on whether int main() { P(P); }
>> halts. That computation does indeed halt. Your H claims otherwise.
>> Therefore it is wrong.
>>
>> André
>>
>>
>
>

On 11/26/2021 1:16 PM, André G. Isaak wrote:
> On 2021-11-26 11:40, olcott wrote:
>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>> On 2021-11-26 08:29, olcott wrote:
>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>
>>>>> Where is this 'formal proof' of which you speak?
>>>>>
>>>>
>>>> The formal proof that I mean is every single step of the behavior of
>>>> the input that leads to the last instruction of this input or some
>>>> kind of repeating cycle.
>>>
>>> <snip pointless trace>
>>>
>>> That was a *trace*. A trace is no even remotely a formal proof. It is
>>> simply a trace. You should review what a proof actually looks like.
>>>
>>> <snip definition of Turing Machine -- we already know what a TM is>
>>>
>>>> The input to H(x,y) is a finite string pair where x is a list of
>>>> quintuples of Turing machine instructions and y is a finite string.
>>>>
>>>> The formal proof of the behavior of N steps of x applied to y is the
>>>> sequence of configurations derived when a UTM is applied to x on
>>>> input y for N steps of configurations.
>>>>
>>>>> Do you even know what a formal proof is?
>>>>
>>>> I am defining it more broadly as every inference step in sound
>>>> deduction leading to a true conclusion.
>>>
>>> You are 'defining' it in a way which bears no resemblance to the
>>> actual definition of 'proof'. And a trace does not constitute a
>>> 'sound deduction' either, nor does it include 'inference steps'.
>>>
>>
>> So you are saying the the correct pure simulation of N steps of the
>> input to H(P,P) by H has no relationship what-so-ever to the actual
>> behavior of P(P)?
>>
>> I say that the correct pure simulation of N steps of the input to
>> H(x,y) is the only correct halt deciding basis that any C/x86/TM halt
>> decider can possibly have.
>
> Obviously it is not a 'correct pure simulation' since it gets the wrong
> answer to the question.
>

If you do not comprehend that there is a correct pure simulation of N
steps of the input to H(P,P) by H then you are insufficiently
technically competent.

> You keep ignoring the specification of the problem.
>
> André
>

--
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/26/21 2:43 PM, olcott wrote:
> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>> On 2021-11-26 11:40, olcott wrote:
>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>> On 2021-11-26 08:29, olcott wrote:
>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>
>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>
>>>>>
>>>>> The formal proof that I mean is every single step of the behavior
>>>>> of the input that leads to the last instruction of this input or
>>>>> some kind of repeating cycle.
>>>>
>>>> <snip pointless trace>
>>>>
>>>> That was a *trace*. A trace is no even remotely a formal proof. It
>>>> is simply a trace. You should review what a proof actually looks like.
>>>>
>>>> <snip definition of Turing Machine -- we already know what a TM is>
>>>>
>>>>> The input to H(x,y) is a finite string pair where x is a list of
>>>>> quintuples of Turing machine instructions and y is a finite string.
>>>>>
>>>>> The formal proof of the behavior of N steps of x applied to y is
>>>>> the sequence of configurations derived when a UTM is applied to x
>>>>> on input y for N steps of configurations.
>>>>>
>>>>>> Do you even know what a formal proof is?
>>>>>
>>>>> I am defining it more broadly as every inference step in sound
>>>>> deduction leading to a true conclusion.
>>>>
>>>> You are 'defining' it in a way which bears no resemblance to the
>>>> actual definition of 'proof'. And a trace does not constitute a
>>>> 'sound deduction' either, nor does it include 'inference steps'.
>>>>
>>>
>>> So you are saying the the correct pure simulation of N steps of the
>>> input to H(P,P) by H has no relationship what-so-ever to the actual
>>> behavior of P(P)?
>>>
>>> I say that the correct pure simulation of N steps of the input to
>>> H(x,y) is the only correct halt deciding basis that any C/x86/TM halt
>>> decider can possibly have.
>>
>> Obviously it is not a 'correct pure simulation' since it gets the
>> wrong answer to the question.
>>
>
> If you do not comprehend that there is a correct pure simulation of N
> steps of the input to H(P,P) by H then you are insufficiently
> technically competent.