Halting problem proofs refuted on the basis of software engineering ?

[olcott]

This is an explanation of a possible new insight into the halting
problem provided in the language of software engineering. Technical
computer science terms are explained using software engineering terms.
No knowledge of the halting problem is required.

When the conventional “pathological” input (that does the opposite of
whatever the halt decider decides) is the first argument to a simulating
halt decider then this input becomes decidable as specifying infinitely
recursive simulation.

This paper is based on fully operational software executed in the x86utm
operating system. The x86utm operating system (based on an excellent
open source x86 emulator) was created to study the details of the
halting problem proof counter-examples at the much higher level of
abstraction of C/x86.

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

// P does the opposite of whatever H decides
void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status) // if H(P,P) reports that its input halts
HERE: goto HERE; // P loops and never halts
return; // else P halts
}

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

// This H(P,P) specifies the direct execution of P(P)
// which obviously never stops running
int H(ptr x, ptr y)
{
x(y);
}

Halting: is defined as:
*reaching the last instruction (AKA final state) and stopping*

When an H is defined that correctly determines that the above direct
execution of P(P) would never reach its “return” instruction (AKA final
state) the conventional halting problem proofs are refuted.

All halt deciders are intended to predict the behavior of their inputs
without actually executing these inputs because the halt decider itself
must always halt. The method used to determine that the above P(P) never
halts is a slight adaptation of a similar method that correctly detects
infinite recursion.

When a correct non-halting behavior pattern is matched a simulating halt
decider (SHD) aborts its simulation and returns 0. Halting does not mean
stops running, halting only means reaching the last instruction and
stops running.

Because we can see that the direct execution of P(P) from H would never
reach the last “return” instruction of P we know that no complete or
partial simulation of P by H would ever reach this last instruction of
P. From this we know that P is non-halting.

*Complete halt deciding system including*
*(a) x86utm operating system*
*(b) complete x86 emulator*
*(c) Several halt deciders and their inputs contained within Halt7.c*
https://liarparadox.org/2022_09_07.zip

*Currently compiles under*
Microsoft Visual Studio Community 2017
https://visualstudio.microsoft.com/vs/older-downloads/




--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[olcott]

On 9/22/2022 8:09 PM, Richard Damon wrote:
> On 9/22/22 7:33 PM, olcott wrote:
>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>> On 9/22/22 12:23 PM, olcott wrote:
>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:

>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided in
>>>>>>>>>>>>>>>>>>>>>>>>>> the language of software engineering.
>>>>>>>>>>>>>>>>>>>>>>>>>> Technical computer science terms are explained
>>>>>>>>>>>>>>>>>>>>>>>>>> using software engineering terms. No knowledge
>>>>>>>>>>>>>>>>>>>>>>>>>> of the halting problem is required.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the halt
>>>>>>>>>>>>>>>>>>>>>>>>>> decider decides) is the first argument to a
>>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider then this input
>>>>>>>>>>>>>>>>>>>>>>>>>> becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it
>>>>>>>>>>>>>>>>>>>>>>>>> can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its
>>>>>>>>>>>>>>>>>>>>>>>> own final state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it
>>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run

>>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is
>>>>>>>>>>>>>>>>>>>>> supposed to be an halt
>>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such
>>>>>>>>>>>>>>>>>>>>> an H not to
>>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you
>>>>>>>>>>>>>>>>>>>>> much.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its input
>>>>>>>>>>>>>>>>>>>> even though it does not perform a direct execution
>>>>>>>>>>>>>>>>>>>> of this input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>>>>> would happen if something does something that it
>>>>>>>>>>>>>>>>>>> doesn't do.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>>>>> loop never halts without executing it. That you act
>>>>>>>>>>>>>>>>>> like you keep forgetting this is either dishonest or
>>>>>>>>>>>>>>>>>> you actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>>>>> independent computaitons.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>>
>>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>>
>>>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>>>> input to an accept or reject state based on the actual
>>>>>>>>>> behavior specified by the direct execution of this input.
>>>>>>>>>
>>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>>
>>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>>> independent machine.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>>>> int main() { P(P); }
>>>>>>>>>
>>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>>
>>>>>>>> Because this is not the actual input to H, and its behavior is
>>>>>>>> not the same as the behavior of this actual input to H then it
>>>>>>>> violates the principle that a halt decider must report on the
>>>>>>>> actual behavior of its actual input.
>>>>>>>
>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>> All that "representation" actually means is that the halt decider
>>>>>> examines a finite string encoding of a Turing Machine thus not the
>>>>>> Turing machine itself.
>>>>>>
>>>>>> It certainly does not mean that the halt decider must examine the
>>>>>> mental idea that you have about what the input does.
>>>>>>
>>>>>
>>>>> Except that it does.
>>>>>
>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>
>>>>
>>>> The actual behavior of the actual input is not specified by the
>>>> behavior of non-inputs.
>>>
>>> Thus not by the simulation of the input with a different version of
>>> H, like your "Set of H" does.
>> Zero elements of Hx/Px pairs correctly simulated by Hx reach their
>> final state thus zero elements of the Hx/Px pairs halt.
>>
>>
>
> SO?
>

void Px(ptr x)
{
int Halt_Status = Hx(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

Zero Px elements of Hx/Px pairs correctly simulated by Hx reach their
final state thus zero Px elements of the Hx/Px pairs halt.

Thus the conventional "impossible" input is correctly determined to be
non-halting, thus not proof of HP undecidability.