On 8/2/22 8:49 AM, olcott wrote:
> On 8/2/2022 7:17 AM, Paul N wrote:
>> On Tuesday, August 2, 2022 at 12:54:32 AM UTC+1, olcott wrote:
>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>> But that's apparently not the same as the halt status of the machine
>>>> the input represents, specifically Pa(Pa), as per the definition of
>>>> the function a halt decider is required to compute:
>>>>
>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>
>>> The behavior of directly executed P(P) is NOT the same behavior
>>> as when H(P,P) correctly simulates its input because the execution
>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>> void P(ptr x)
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> P(P);
>>> }
>>>
>>> When P calls H(P,P) this is essentially the first call of
>>> infinite recursion. When H(P,P) simulates its input this
>>> is essentially the second call of infinite recursion.
>>>
>>> H can see the infinite recursion specified by its input and
>>> aborts its simulation on that basis. As with all infinite
>>> recursion when any call is aborted the whole sequence stops.
>>> In this case when H(P,P) aborts its simulation it returns to
>>> its caller.
>>>
>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>> the the simulation never stops unless aborted) therefore H did
>>> correctly determine the halt status of this input.
>>>
>>> That is was supposed to determine the halt status of a non-input
>>> seems absurd and is rejected on the basis that software engineering
>>> won't allow it.
>>
>> So you accept that your H does not report on what happens when P(P) is
>> executed?
>
> P(P) halts and the correctly simulated input to H(P,P) by H never halts
> because they specify two different sequences of instructions:
> one begins with the invocation of H and the other begins with the
> invocation of P. In the first case H(P,P) returns 0 to P in the second
> case because H is called in infinite recursion it never returns to P.
>
>> Your H only predicts what will happen when your H simulates a call of
>> P(P)?
>
> Likewise sum(3,4) does not report the sum of 4+5 that would violate
> software engineering.
>
> *Do you understand that this is true*?
> H(P,P) does correctly determine the halt status of the sequence of
> instructions that it is presented with.
>
> H(P,P) does not, cannot, should not, and must not report on any sequence
> of instructions that it was *NOT* presented with. This violates software
> engineering.
>
>
>

No, it doesn't, as the sequence of instruction it has been presented
with is EXACTLY the representation of P(P).

Note, the input it the sequence of instruction as they are IN MEMORY,
not the execution trace that derives from it.

That "sequence of instructions" is the FULL assembly code of P, and H,
and ANYTHING that H calls.

If you think the input is the trace generated by H, then you are totally
confused, the trace generation is part of the behavior of H.

What is a CORRECT execution trace of the sequence of instructions is
FULLY defined by those instructions (ALL OF THEM, that includes the
instructions in H).

This is why you are wrong about the "behavior" of the input to H(P,P)
and the behavior of P(P), as BY DEFINITION they are the same, if H is a
Halt Decider (and thus establishing the definition of the behavior of
the "string" input).

If you say that H hasn't been given the EXACT set of x86 instructions
that make up the program P(P), then why didn't P pass that to it?

IF the input to H(P,P) doesn't represent the computation P(P), then YOU
are the one that has made a mistake, as YOU wrote your P to make that
call to decide on that computation.

All you have actually proved over the past 18 years seems to be that you
just don't understand how anything actually works.

How to actually PROVE something.

What is a Turing Machine.

What is a Computation.

What is Correct.

What is Simulation.

What it Truth.

You total lack of understanding, while at the same time insisting that
you have made some wonderful discover just shows what a FOOL you are, as
you seem to believe your own lies.

On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
> On 8/1/2022 8:40 PM, Dennis Bush wrote:
> > On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
> >> On 8/1/2022 8:17 PM, Dennis Bush wrote:
> >>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
> >>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
> >>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> >>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> >>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
> >>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
> >>>>>>>>>>>>>>>>>>>>>>>> will never
> >>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>> emulator...
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
> >>>>>>>>>>>>>>>>>>>>>>> ever
> >>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Good, I agree.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
> >>>>>>>>>>>>>>>>>>>>>>> that its
> >>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
> >>>>>>>>>>>>>>>>>>>>>>> will NEVER
> >>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
> >>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
> >>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
> >>>>>>>>>>>>>>>>>>>>>>> stops its
> >>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
> >>>>>>>>>>>>>>>>>>>>>>> Halt.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
> >>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
> >>>>>>>>>>>>>>>>>>>>>>> return 0
> >>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
> >>>>>>>>>>>>>>>>>>>>>>> Halting.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>> generate a
> >>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
> >>>>>>>>>>>>>>>>>>>>>>> provide the
> >>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
> >>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
> >>>>>>>>>>>>>>>>>>>>>>> "proof"
> >>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
> >>>>>>>>>>>>>>>>>>>>>>> invalid, and
> >>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
> >>>>>>>>>>>>>>>>>>>>>>> into the
> >>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
> >>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
> >>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
> >>>>>>>>>>>>>>>>>>>>>> reviewers will
> >>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
> >>>>>>>>>>>>>>>>>>>>>> reviewer.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
> >>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
> >>>>>>>>>>>>>>>>>>>>>> no longer
> >>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
> >>>>>>>>>>>>>>>>>>>>>> its "ret"
> >>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
> >>>>>>>>>>>>>>>>>>>>>> before ever
> >>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
> >>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction..
> >>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
> >>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>> simulated by H
> >>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
> >>>>>>>>>>>>>>>>>>>> whether
> >>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
> >>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
> >>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
> >>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
> >>>>>>>>>>>>>>>>> behavior of the program the input represents,
> >>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
> >>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
> >>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
> >>>>>>>>>>>>>>>> simulation.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
> >>>>>>>>>>>>>>> the input. The COMPLETE part is important.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
> >>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
> >>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>>>>>>>> H(P,P) aborts its simulation.
> >>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>>>>>>>
> >>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>>>>>>>> everything that I say out-of-hand without even looking at it and
> >>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>>>>>>>> pay any attention to what I say.
> >>>>>>>>>
> >>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>>>>>>>
> >>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>>>>>>>
> >>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Where I point out you're answering the wrong question.
> >>>>>>>>>
> >>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>>>>>>>
> >>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
> >>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
> >>>>>>>>>> void P(ptr x)
> >>>>>>>>>> {
> >>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>> if (Halt_Status)
> >>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>> return;
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> int main()
> >>>>>>>>>> {
> >>>>>>>>>> P(P);
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> When P calls H(P,P) this is essentially the first call of
> >>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
> >>>>>>>>>> is essentially the second call of infinite recursion.
> >>>>>>>>>>
> >>>>>>>>>> H can see the infinite recursion specified by its input and
> >>>>>>>>>> aborts its simulation on that basis. As with all infinite
> >>>>>>>>>> recursion when any call is aborted the whole sequence stops.
> >>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
> >>>>>>>>>> its caller.
> >>>>>>>>>>
> >>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>>>>>>>> the the simulation never stops unless aborted) therefore H did
> >>>>>>>>>> correctly determine the halt status of this input.
> >>>>>>>>>>
> >>>>>>>>>> That is was supposed to determine the halt status of a non-input
> >>>>>>>>>> seems absurd and is rejected on the basis that software engineering
> >>>>>>>>>> won't allow it.
> >>>>>>>>>
> >>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>>>>>>>
> >>>>>>>> You know that never said anything like that:
> >>>>>>>>
> >>>>>>>> Try and find a date-and-time stamped quote of me
> >>>>>>>> saying anything like that.
> >>>>>>>
> >>>>>>> That's precisely what the comment I've been quoting is saying:
> >>>>>>>
> >>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> >>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
> >>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
> >>>>>>>
> >>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >>>>>>>
> >>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> >>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> >>>>>
> >>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> >>>>> of Hn it is essentially the same as a UTM.
> >>>>>
> >>>>>> A simulating halt decider is always correct to abort the simulation of
> >>>>>> any input that it correctly predicts would never otherwise never stop
> >>>>>> running.
> >>>>>
> >>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
> >>>>>
> >>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>
> >>>> Yet in the case of H and P that would require a software function to
> >>>> return the result of analyzing a non-input which from a software
> >>>> engineering perspective is pure nonsense.
> >>>
> >>> You don't get to change the question.
> >> When the question is WRONG, I do get to change the question.
> >
> > Are you saying that it's impossible for a function H to implement the following specification?
> >
> > H(X,Y)==1 if and only if X(Y) halts, and
> > H(X,Y)==0 if and only if X(Y) does not halt
> >
> main()
> {
> H(P,P);
> P(P);
> }
>
> If H(P,P) reports on the behavior of a sequence of instructions where P
> has been executed first and H has not yet been executed then H is
> reporting incorrectly, directly against the verified facts.

On 8/2/22 9:56 AM, olcott wrote:
> On 8/2/2022 8:19 AM, Paul N wrote:
>> On Tuesday, August 2, 2022 at 1:49:39 PM UTC+1, olcott wrote:
>>> On 8/2/2022 7:17 AM, Paul N wrote:
>>>> On Tuesday, August 2, 2022 at 12:54:32 AM UTC+1, olcott wrote:
>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>> But that's apparently not the same as the halt status of the
>>>>>> machine the input represents, specifically Pa(Pa), as per the
>>>>>> definition of the function a halt decider is required to compute:
>>>>>>
>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>
>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>> void P(ptr x)
>>>>> {
>>>>> int Halt_Status = H(x, x);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> P(P);
>>>>> }
>>>>>
>>>>> When P calls H(P,P) this is essentially the first call of
>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>> is essentially the second call of infinite recursion.
>>>>>
>>>>> H can see the infinite recursion specified by its input and
>>>>> aborts its simulation on that basis. As with all infinite
>>>>> recursion when any call is aborted the whole sequence stops.
>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>> its caller.
>>>>>
>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>> the the simulation never stops unless aborted) therefore H did
>>>>> correctly determine the halt status of this input.
>>>>>
>>>>> That is was supposed to determine the halt status of a non-input
>>>>> seems absurd and is rejected on the basis that software engineering
>>>>> won't allow it.
>>>>
>>>> So you accept that your H does not report on what happens when P(P)
>>>> is executed?
>>> P(P) halts and the correctly simulated input to H(P,P) by H never halts
>>> because they specify two different sequences of instructions:
>>> one begins with the invocation of H and the other begins with the
>>> invocation of P. In the first case H(P,P) returns 0 to P in the second
>>> case because H is called in infinite recursion it never returns to P.
>>
>> If a simulation is correct, then it is possible to work out what will
>> happen in the real case by looking at what happens in the simulated case.
>
> You are saying that if the simulation of the sequence of instructions
> specified by X is correct then we can use this correct simulation of X
> to determine what the behavior sequence of instructions specified by Y.
>
> How does that make any sense?

What INSTRUCTION is different, what is the FIRST difference.

What ACTUAL INSTUCTION CORRECTLY SIMULATE is different, what is the
first difference?

Your "Proof" of the difference doesn't actual show either of these
cases. It sees P(P) calling H(P,P) and that running and eventually
returning 0.

It sees the input of H(P,P) being simuated to the point of calling
H(P,P), just like the above, and then H makes the UNSOUND judgement that
this means the input is non-halting.

We KNOW the behavior of a call to H(P,P), because H has been programmed
to incorrectly abort it simulation, it will return 0 and P(P) will Halt.

H can't just assume that the copy of H it sees will do the "right"
thing, while it actually doesn't do that. H makes a mistake because it
presumes without proof that it will be correct.

You CAN'T assume correctness, you have to prove it without first
assuming it. You can't do that for H and P(P).

>
>> This is part of the point of doing simulations. However, you have said
>> yourself that P(P) behaves differently from your simulation. Thus I do
>> not accept that your simulation is a correct simulation.
>
> The line-by-line execution trace of the x86 emulation of the input to
> H(P,P) by H exactly matches the line-by-line x86 source-code of P.

Untill you get to the call to H, which when executed goes into a
function that we know empirically returns 0 (because it does that later
in the trace) while in the simulation H just incorrectly and unsoundly
assumes that H will never return.

There ISN'T a "difference" in the correct simulation, there is unsound
logic being done by H.

>
> There are few things that annoy me more than when people ignore the
> verified facts so that they can hold onto their opinion.
>
> int main()
> {
>   H(P,P);
>   P(P);
> }
>
> At the C level we can see that one sequence begins with H and the other
> begins with P. To rigidly assume that two different sequences must have
> the same behavior is ridiculous.

Which doesn't matter if H is a pure function!

H(P,P), if H is a pure function, MUST ALWAY behave the same,
irregardless of how it has been called.

You don't seem to understand that.

>
>> You seem to think that your simulation is "even better than the real
>> thing" in that you are prepared to trust the results of your
>> simulation even when you know that the actual program being simulated
>> acts differently.
>
> The correct simulation (as verified line-by-line) of the input to H(P))
> by H conclusively proves that it will never stop running unless aborted.

Nope, it never actually proves that. It makes an UNSOUND and INVALID
arguement that leads to that INCORRECT conclusion.

>
> *You can verify this yourself here is the whole system*:
> Simply build the project and Halt7.c is automatically compiled with the
> command line compiler. This way you can comment out the code that aborts
> the simulation and see that it would run forever.

But that give a DIFFERENT P, as each version of H give a different
PROGRAM P.

We need to run SIMULATE(P,P) to see if the input to H(P,P) is halting or
not. We can't change the P (by changing the code of H that is calls) to
do that.

>
> https://www.liarparadox.org/2022_07_22.zip
> This is the complete system that compiles under:
>
> Microsoft Visual Studio Community 2017
> https://visualstudio.microsoft.com/vs/older-downloads/
>
>>
>>>> Your H only predicts what will happen when your H simulates a call
>>>> of P(P)?
>>> Likewise sum(3,4) does not report the sum of 4+5 that would violate
>>> software engineering.
>>
>> sum(3, 4) must return 3+4 because 3 and 4 are the arguments provided.
>> 4 and 5 are not.
>>
>> Likewise, H(P, P) must report on the behaviour of P(P) because P and P
>> are the two arguments provided.
>>
>>> *Do you understand that this is true*?
>>> H(P,P) does correctly determine the halt status of the sequence of
>>> instructions that it is presented with.
>>
>> No it doesn't - you say that H(P, P) is zero, but that P(P) halts.
>>
>>> H(P,P) does not, cannot, should not, and must not report on any sequence
>>> of instructions that it was *NOT* presented with. This violates software
>>> engineering.
>>
>> Yes, it must report on what P(P) actually does. You claim it does not.
>
> When computer science theory contradicts software engineering facts the
> theory must be revised in light of these facts.

Except is DOESN'T contradict it. YOUR MISUNDERSTAND is what is wrong.

>
> H(P,P) does correctly report on the sequence of instructions that it was
> presented with that begins with itself. H is run and then P is run.
> H cannot report on the sequence where P is run first and then H is run
> second.
>
> H1(P,P) (an identical copy of H at a different machine address) returns 1.
>
>
>

And that H1 becomes the equivalent of Simulate, and PROVES that H(P,P)
returning 0 was WRONG.

There can be only ONE correcgt answer to any Halt_Decider(M, x), ALL
correct halt deciders must give the same answer, as M(x) will either
Halt or Not.

The fact that H(P,P) gets the answer wrong for the P built on IT, just
shows that H isn't a Halt Decider, and since that works for ANY Halt
decider you might try to create, it shows there are no Universally
Correct Halt Deciders.

On 8/2/22 8:42 PM, olcott wrote:
> On 8/2/2022 1:18 PM, Andy Walker wrote:
>> On 02/08/2022 18:54, Jeff Barnett wrote:
>>> Once again, the proof shows there is no right answer, but there is
>>> one more step to complete the proof: "If there is no right answer for
>>> some problems, then an actual decider simply cannot exist." [...]
>>
>>      Just to be clear, /given/ a program and its input, there /is/ a
>> "right answer" to the HP question applied to that program and input.
>> What the "usual" proof shows is not that there is no right answer, but
>> that no one TM can always find it.
>>
>>> Assume that you have an H(TM,INPUT) that properly returns a value in
>>> {halts, pathological, infinite-loop} [...].
>>
>>      Neither PO nor Flibble has ever given a sensible definition of
>> what they mean by "pathological",
>
> For any program H that might determine if programs halt,
> a "pathological" program P, called with some input, can
> pass its own source and its input to H and then specifically
> do the opposite of what H predicts P will do.
> *No H can exist that handles this case*
> https://en.wikipedia.org/wiki/Halting_problem
>
> Sipser says the same thing yet does not use the term "pathological".
>
> "Now we construct a new Turing machine D with H as a subroutine.
> This new TM calls H to determine what M does when the input to
> M is its own description <M>. Once D has determined this information,
> it does the opposite."
> https://www.liarparadox.org/Sipser_165_167.pdf

THe key point is that in the first, if you note, "pathological" was
quoted, because the program P doesn't actually meet the formal
definition of "patholgical" as there is nothing "wrong" or "diseased"
about it. P is a perfectly valid program that a Halt Decider, if it
existed, should be able to decide on.

THe only "pathology" in P, is that it kills DEAD the idea that a Halt
Decider could exists, as the fact that we CAN make this program P for
ANY machine that claims to be a Halt Decider, and we can show that that
machine just can not give the right answer.

Remember the definition of a Halt Decider is that:

H(M,x) must accept, if M(x) will Halt, but if H(P,P) accepts, then P(P)
will loop forever and never halt, and
H(M,x) must reject, if M(x) will never halt, but if H(P,P) reject, then
P(P) will Halt.

Thus, whatever answer H returns for H(P,P) will be wrong by the design of P.

The only other possible behavior is to just never accept or reject
(since either makes H wrong) but then H fails to be a decider, so fails
to be a Halt Decider.

>
>> and of course if they do they will
>> fall foul of Rice's Theorem.
>
> It is my possibly incorrect understanding that Rice is anchored in the
> halting problem such that when the HP proofs are correctly refuted this
> refutation causes Rice to fail in that Rice could be reduced to the
> refuted HP.

Rice is not "Anchored" in the halting problem, but is sort of a more
general version of it, being based not on the specific behavior of
"Halting", but on a more generalized definition of Semantic Behavior, of
which Halting is just one example.

>
>> Further, there seems somehow to be an
>> assumption that "infinite loop" is the only way that a program can
>> fail to halt.  If only it was so simple!
>>
>
>

On 8/2/22 8:45 PM, olcott wrote:
> On 8/2/2022 1:56 PM, Mikko wrote:
>> On 2022-08-02 18:44:24 +0000, Mr Flibble said:
>>
>>> On Tue, 2 Aug 2022 21:41:54 +0300
>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>
>>>> On 2022-08-02 16:11:54 +0000, Mr Flibble said:
>>>>
>>>>> On Tue, 2 Aug 2022 19:07:33 +0300
>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>
>>>>>> On 2022-08-01 12:54:04 +0000, olcott said:
>>>>>>
>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>> actually specified by these inputs.
>>>>>>
>>>>>> The halting problem does not require that. It merely says (or
>>>>>> implies -- each author uses different words but they aways mean
>>>>>> the same) that
>>>>>> - if H(M, I) returns false and M(I) halts then H is not a halt
>>>>>> decider
>>>>>> - if H(M, I) returns true and M(I) doesn't halt then H is not a
>>>>>> halt decider
>>>>>> - if H(M, I) returns something else then H is not a halt decider
>>>>>> - if H(M, I) does not return then H is not a halt decider
>>>>>> - otherwise H is a halt decider
>>>>>
>>>>> I can add to that (my key insight):
>>>>>
>>>>> - if H(M, I) doesn't signal an exception on pathological
>>>>> ("Impossible Program") input then H is not a halt decider.
>>>>
>>>> No, you can't. The problem definition is what it is and you
>>>> can't add anything to it, and it says or at least imlies that
>>>> if H(M, I) signals an exception it is not a halt decider.
>>>
>>> Yes I can and I have. I have extended the definition of a halt decider.
>>>
>>> /Flibble
>>
>> If there is two conflicting definitions for the same term the definition
>> published earlier is the valid one.
>>
>> Mikko
>>
>
> >
> main()
> {
>   H(P,P);
>   P(P);
> }
>
> If H(P,P) reports on the behavior of a sequence of instructions where P
> has been executed first and H has not yet been executed then H is
> reporting incorrectly, directly against the verified facts.
>
>

The sequence of instruction that H gets are the same either way. What
has happend before the call to H can not affect its behavior if H is a
pure function.

Maybe you don't understand the meaning of a Pure Funciton.

The sequence of instruction being given to H to decide on is the
sequence of instruction in the FULL program P, starting at a call to
P(P), as that is what the input to H(P,P) represents, as indicated by
your program P.

THus, the "sequence of instructions" that H goes through doesn't matter
if the call stack to H is:

main
H(P,P)

or

main
P(P)
H(P,P)

in both cases, H is being asked to decide on what P(P) will do, and if H
is a pure function, then so is P, so the behavior of P(P) doesn't depend
on the conditions it is called in, so both calls to H need to generate
the same answer as they are being asked the same question.

On 8/2/22 2:17 PM, Mr Flibble wrote:
> On Tue, 2 Aug 2022 11:54:34 -0600
> Jeff Barnett <jbb@notatt.com> wrote:
>
>> On 8/2/2022 10:11 AM, Mr Flibble wrote:
>>> On Tue, 2 Aug 2022 19:07:33 +0300
>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>
>>>> On 2022-08-01 12:54:04 +0000, olcott said:
>>>>
>>>>> A halt decider must compute the mapping from its inputs to an
>>>>> accept or reject state on the basis of the actual behavior that is
>>>>> actually specified by these inputs.
>>>>
>>>> The halting problem does not require that. It merely says (or
>>>> implies -- each author uses different words but they aways mean
>>>> the same) that
>>>> - if H(M, I) returns false and M(I) halts then H is not a halt
>>>> decider
>>>> - if H(M, I) returns true and M(I) doesn't halt then H is not a
>>>> halt decider
>>>> - if H(M, I) returns something else then H is not a halt decider
>>>> - if H(M, I) does not return then H is not a halt decider
>>>> - otherwise H is a halt decider
>>>
>>> I can add to that (my key insight):
>>>
>>> - if H(M, I) doesn't signal an exception on pathological
>>> ("Impossible Program") input then H is not a halt decider.
>> You, like PO, seem to think that a proper H uses some sort of
>> simulation and signals exceptions. That isn't true. Take the
>> impossible program used in the proof that there is no right answer.
>> That result can be derived by simple analysis - everybody still
>> stroking the mega maniac by contributing to these threads has done
>> that by studying the symbolic code.
>>
>> Once again, the proof shows there is no right answer, but there is
>> one more step to complete the proof: "If there is no right answer for
>> some problems, then an actual decider simply cannot exist." That
>> proof is not the only one however. There are a ton of them (proofs)
>> and many show that desirable deciders about problems of great
>> interest to Software Engineers, Mathematicians, and Logicians don't
>> exist either.
>>
>> The results apply to any claim about Universal Deciders which are
>> really the same class as Deciders.
>>
>> Assume that you have an H(TM,INPUT) that properly returns a value in
>> {halts, pathological, infinite-loop} with the stipulation that H
>> halts for any arguments, i.e., H is the POOP decider that PO has wet
>> dreams about. QUESTION: What happens if you build H' and H^ from this
>> H? Run it through the same proof structure that is in Linz and tell
>> us all what happens. Will PO die a fool or find a place in history?
>> The curious want to know!
>
> You are wrong: I am extending the definition of what constitutes a
> halt decider which is my right as both a computer scientist and a
> software engineer.
>
> If the only way to detect pathological input is through the use of a
> simulating halt decider then so be it.
>
> /Flibble
>

No, you CAN NOT change the definition of the existing Halting Function.

You can create a NEW property, Flibble-Halting, and define what a
Flibble-Halt Decider is, but that is NOT changing the actual definiton
of Halting.

That is the same mistake that Olcott is doing. He thinks he has the
power to change what is.

Maybe Flibble-Halting has some interesting properties, but likely not.

If the Flibble-Simulation of the input deviates from what the true
behavior of that input, then things get non-interesting rapidly, and it
just becomes a toy, and this seems to be the problem.

On 8/2/2022 7:40 PM, Jeff Barnett wrote:
> On 8/2/2022 5:06 PM, Andy Walker wrote:
>> On 02/08/2022 22:13, Jeff Barnett wrote:
>>> [...]  All the standard proof shows is that
>>> there is no consistent answer for a problem and that is a
>>> contradiction so the (set of) assumptions are inconsistent.
>>
>>      No, that's /not/ what the standard proof shows in relation
>> to the HP.  What it shows is that given any program "H" there are
>> instances of programs and data that "H" fails with, and therefore
>> "H" is not a correct halt decider.  It doesn't show [and how could
>> it?] that those instances are in any way inconsistent, pathological
>> or even difficult to analyse.  Any given program+data combination
>> either halts or fails to halt;  there is no third [or fourth!]
>> possible outcome.
>
> Try it again. I've said nothing about inconsistent or pathological
> instances. What I said and you quoted me above is that the (set of)
> assumptions are inconsistent since they lead to contradictions. One such
> contradiction is shown in the proof and that is enough. Besides the
> assumption that the h, a halt decider, itself always halts there are
> many other assumptions including the very definition of TM. I've never
> seen a proof that the definition of TM, with or without a halt decider
> definition included, are consistent. In fact the Linz proof definitely
> shows that there is no correct, consistent value to return.

Yes all the proof shows that, Linz does it the best.

*THIS IS THE ENTIRE GIST OF MY KEY BREAKTHROUGH*
What none of the proofs show that that when H is a
simulating halt decider that the conventional undecidable
inputs are decidable on the basis that no function called
in what is essentially infinite recursion ever returns any
value to its caller. Because correct software engineering
prevents H from returning any value to its simulated P this
simulated P cannot possibly do the opposite of whatever H decides.

< It really
> doesn't point out which subset of definitions and axioms contain the
> inconsistency.
>
> If you have proved or believe (as I do) that everything before
> introducing the formal definition of h is consistent, then we can point
> the finger at the introduction of h as the problem source. But the proof
> itself only shows that no answer is correct (i.e., any answer is
> inconsistent). I think at this point we leap out of FOL and start a
> different sort of discussion.

--
Copyright 2022 Pete Olcott

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

On 8/2/22 10:35 PM, olcott wrote:
> On 8/2/2022 7:40 PM, Jeff Barnett wrote:
>> On 8/2/2022 5:06 PM, Andy Walker wrote:
>>> On 02/08/2022 22:13, Jeff Barnett wrote:
>>>> [...]  All the standard proof shows is that
>>>> there is no consistent answer for a problem and that is a
>>>> contradiction so the (set of) assumptions are inconsistent.
>>>
>>>      No, that's /not/ what the standard proof shows in relation
>>> to the HP.  What it shows is that given any program "H" there are
>>> instances of programs and data that "H" fails with, and therefore
>>> "H" is not a correct halt decider.  It doesn't show [and how could
>>> it?] that those instances are in any way inconsistent, pathological
>>> or even difficult to analyse.  Any given program+data combination
>>> either halts or fails to halt;  there is no third [or fourth!]
>>> possible outcome.
>>
>> Try it again. I've said nothing about inconsistent or pathological
>> instances. What I said and you quoted me above is that the (set of)
>> assumptions are inconsistent since they lead to contradictions. One
>> such contradiction is shown in the proof and that is enough. Besides
>> the assumption that the h, a halt decider, itself always halts there
>> are many other assumptions including the very definition of TM. I've
>> never seen a proof that the definition of TM, with or without a halt
>> decider definition included, are consistent. In fact the Linz proof
>> definitely shows that there is no correct, consistent value to return.
>
> Yes all the proof shows that, Linz does it the best.
>
> *THIS IS THE ENTIRE GIST OF MY KEY BREAKTHROUGH*
> What none of the proofs show that that when H is a
> simulating halt decider that the conventional undecidable
> inputs are decidable on the basis that no function called
> in what is essentially infinite recursion ever returns any
> value to its caller. Because correct software engineering
> prevents H from returning any value to its simulated P this
> simulated P cannot possibly do the opposite of whatever H decides.

Except that this "essentially infinite recursion" that you are detecting
is not ACTUAL infinite recursion, becuase the H in the loop of the
recursion break the recursion.

Since H just saw something that looks sort of like infinte recursion,
but not actual infinte recursion, it is WRONG to say it IS infinite
recursion.

Ulitmately, you problem is that H presumes behavior out of the H that is
sees that doesn't match the actual behavior that H generates.

H is looking at a hypothetical version of the input that doesn't
actually exist.

This is proved by the fact that if H(P,P) returns 0, then P(P) will
ALWAYS halt, so H(P,P) returning 0 is an incorrect answer, BECAUSE it
aborting its simulation and returning 0 is what makes P halt, but it is
the H that P calls that does this, so P gets "credit" for it as it is a
part of the algorithm of P, and not just the algorithm of the thing
trying to decide on it.

H needs to decide on the P that IS, that uses the H that IS, not some
idealized description of what H is supposed to be if it was correct.

H can't start with an assumption that it is correct, and then use that
to prove that it is, in fact, correct. That is a fallacy.

It may look similar to proof by contradiction, where you prove something
is FALSE, by first presuming that something is true, and then show that
as a necessary consequence of this assumption, a contradiction occurs,
but there are crucial differences.

>
> < It really
>> doesn't point out which subset of definitions and axioms contain the
>> inconsistency.
>>
>> If you have proved or believe (as I do) that everything before
>> introducing the formal definition of h is consistent, then we can
>> point the finger at the introduction of h as the problem source. But
>> the proof itself only shows that no answer is correct (i.e., any
>> answer is inconsistent). I think at this point we leap out of FOL and
>> start a different sort of discussion.
>
>

On 8/2/2022 7:52 PM, Dennis Bush wrote:
> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>
>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>>>>>
>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>
>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>>>>>
>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> P(P);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>
>>>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>>>> its caller.
>>>>>>>>>>>>
>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>
>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>
>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>>>>>
>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>
>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>> saying anything like that.
>>>>>>>>>
>>>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>>>
>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>>>
>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>>>>>
>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>
>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>
>>>>>>>> A simulating halt decider is always correct to abort the simulation of
>>>>>>>> any input that it correctly predicts would never otherwise never stop
>>>>>>>> running.
>>>>>>>
>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
>>>>>>>
>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>
>>>>>> Yet in the case of H and P that would require a software function to
>>>>>> return the result of analyzing a non-input which from a software
>>>>>> engineering perspective is pure nonsense.
>>>>>
>>>>> You don't get to change the question.
>>>> When the question is WRONG, I do get to change the question.
>>>
>>> Are you saying that it's impossible for a function H to implement the following specification?
>>>
>>> H(X,Y)==1 if and only if X(Y) halts, and
>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>
>> main()
>> {
>> H(P,P);
>> P(P);
>> }
>>
>> If H(P,P) reports on the behavior of a sequence of instructions where P
>> has been executed first and H has not yet been executed then H is
>> reporting incorrectly, directly against the verified facts.
>
> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
>
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt

On 8/2/2022 12:17 PM, Mr Flibble wrote:
> On Tue, 2 Aug 2022 11:54:34 -0600
<SNIP>
> You are wrong: I am extending the definition of what constitutes a
> halt decider which is my right as both a computer scientist and a
> software engineer.

The only reasonable definition I ever heard for a "Software Engineer"
was someone who cannot write code, doesn't do well with math, and has
learned that telling others how to do technology is easier than making a
fool of themself to make a living." Not an impressive professional
allegiance; hell you might get lumped with PO who is the quintessential
software engineer. As a computer scientist, you need to be better at
math and logic. Your idea of a logical argument is "Look at me, I have a
credential!".

I was senior research staff at one of the large universities in Los
Angeles and was asked to give a few lectures to a friend's compiler
class. (It was his first year teaching so he invited various people to
give lectures of which he made copious notes to give him a variety of
material for the coming years.) Some of the kids seemed rather good and
another contingent seemed like arrogant dunderheads.

When we talked about this, he said that he had been informed that there
were "real" students who were graded according to ability and work they
did; there was a second group of entitled snots who were semiofficially
classed as "cash cows". Most were sons (a few daughters?) of rich or
important foreign families who sent their kids to the US for status and
there was no chance that they would ever be employed in the field. Given
there citizenship and presumed wealth, they were soaked monetarily.
Europeans sent entitled children abroad, in the old days, for similar
reasons.

When I read your notes here, I frequently have flashes of that compiler
class. Does any of this description fit?

> If the only way to detect pathological input is through the use of a
> simulating halt decider then so be it.
It isn't. Times up on that nonsense. PO says he's dying. That's his
mantra too and it's bad for him. It's at the point where his tombstone
will no longer read "Earnest Student". The new etching says "Ignorant
and dumb by choice".

By the way, I started a new thread a few minutes ago on a halt decider
with three possible results: the usual two and pathological. You might
want to look at it and use your Software Engineering background to tear
it apart.
--
Jeff Barnett

On 2022-08-02 19:08:55 +0000, Skep Dick said:

> On Tuesday, 2 August 2022 at 20:56:22 UTC+2, Mikko wrote:
>> If there is two conflicting definitions for the same term the definition
>> published earlier is the valid one.

> Equivalent definitions are equivalent.

Conflicting definitions are not equivalent.

Mikko

On Wednesday, 3 August 2022 at 07:19:33 UTC+1, Jeff Barnett wrote:
> On 8/2/2022 12:17 PM, Mr Flibble wrote:
> > On Tue, 2 Aug 2022 11:54:34 -0600
> <SNIP>
> > You are wrong: I am extending the definition of what constitutes a
> > halt decider which is my right as both a computer scientist and a
> > software engineer.
> The only reasonable definition I ever heard for a "Software Engineer"
> was someone who cannot write code, doesn't do well with math, and has
> learned that telling others how to do technology is easier than making a
> fool of themself to make a living."
>
The economic problem was that software projects were delivered late and
over-budget, often abandoned, and when delivered they were full of bugs
which sometimes had a catastrophic impact on the customer.
So what to do about it? A quick analysis would have shown that the problem
wasn't that the programmers didn't know the programming language, or
even that their maths wasn't up to scratch.
The problem was rooted in management. What was much harder was defining
what strong management looked like. For a long time, most people thought
that the solution was to impose from the top down a "formal method". If
everyone adhered to the method, work would be delivered bug free, and on time.
When this gave disappointing results, the reason was that the formal method
wasn't adhered to strictly enough.
It was gradually realised that many successful projects were not build by teams
which followed these formal methods. Now the methods are much better. They
are less bureaucratic, they give more control to programmers or immediate
product managers wanting to add features quickly in response to a proposal or
request, the tolls for controlling changes to source code are much better, the
languages we use are higher-level.
We're still not there yet. Software is still notorious for being expensive to produce
and faulty. You still read of horror stories where many millions of pounds are
wasted.
But realising that the computer science side of the problem is usually the easy
part, and the integration, testing, and deployment the part that goes wrong, and
that it's not just about knocking out code but a much broader problem than that,
is what distinguishes "software engineering" from just "programming".

On 03/08/2022 00:35, Skep Dick wrote:
> On Wednesday, 3 August 2022 at 01:06:16 UTC+2, Andy Walker wrote:
>> Any given program+data combination
>> either halts or fails to halt; there is no third [or fourth!]
>> possible outcome.
> That's just a tautology of Classical logic. It's not true constructively.
> Semi-decidability is the third possible outcome: you can't decide
> whether a given program+data combination will halt.

Yes, but that's not a "proper" outcome; it's just another way of
saying that a [correct] partial decider has the three outcomes "Halts",
"Doesn't halt" and "Don't know". That third category is not defined in
any useful way, only by reference to the capabilities of a particular
partial decider.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Rubinstein

On 03/08/2022 00:46, olcott wrote:
> *So you believe the this Wikipedia article is flat out wrong*?
>   For any program H that might determine if programs halt, a
>   "pathological" program P, called with some input, can pass
>   its own source and its input to H and then specifically do
>   the opposite of what H predicts P will do.
>   *No H can exist that handles this case*
>   https://en.wikipedia.org/wiki/Halting_problem

It's misleading rather than "flat out wrong", and you have been
misled. P is not a specific program; it is derived from H. Write a
different H, and the corresponding P changes. It is perfectly possible
that the "different H" resolves the case of the P that your initial H
failed with. So P is "pathological" [whatever that is supposed to mean]
only for that particular H, not as an intrinsic property of P. This is
disguised in the "impossible program" version because the /function/ P,
in the form "if H(P,P) then L: goto L endif", looks the same visually
for all H; but the full /program/ P includes the text of H.

[In particular, if you emulate H, including an "abort" facility,
then you have a different H, consisting of the emulator and its abort
facility applied to the original H, and this may possibly be able to
resolve the original P. But it can't resolve the new P, derived from
the emulating H.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Rubinstein

On 8/3/22 1:11 AM, olcott wrote:
> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt
>>>>>>>>>>>>>>>>>>>>>>>>>>> decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with
>>>>>>>>>>>>>>>>>>>>>>>>>>> an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do
>>>>>>>>>>>>>>>>>>>>>>>>>>> this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with
>>>>>>>>>>>>>>>>>>>>>>>>>>> an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do
>>>>>>>>>>>>>>>>>>>>>>>>>>> this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with
>>>>>>>>>>>>>>>>>>>>>>>>>>> an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its
>>>>>>>>>>>>>>>>>>>>>>>>>> simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what
>>>>>>>>>>>>>>>>>>>>>>>>>> happens.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can
>>>>>>>>>>>>>>>>>>>>>>>>>> CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern,
>>>>>>>>>>>>>>>>>>>>>>>>>> because it
>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly
>>>>>>>>>>>>>>>>>>>>>>>>>> prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined
>>>>>>>>>>>>>>>>>>>>>>>>>> (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the
>>>>>>>>>>>>>>>>>>>>>>>>>> simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual
>>>>>>>>>>>>>>>>>>>>>>>>>> program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the
>>>>>>>>>>>>>>>>>>>>>>>>>> question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is
>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting,
>>>>>>>>>>>>>>>>>>>>>>>>>> since it is
>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input
>>>>>>>>>>>>>>>>>>>>>>>>>> to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that
>>>>>>>>>>>>>>>>>>>>>>>>>> P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is
>>>>>>>>>>>>>>>>>>>>>>>>>> different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>> the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a
>>>>>>>>>>>>>>>>>>>>>>>>>> call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved
>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it,
>>>>>>>>>>>>>>>>>>>>>>>>>> and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>> that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>> "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its
>>>>>>>>>>>>>>>>>>>>>>>>>> simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>> simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even
>>>>>>>>>>>>>>>>>>>>>>>>> after it has been
>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically
>>>>>>>>>>>>>>>>>>>>>>>>> competent
>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently
>>>>>>>>>>>>>>>>>>>>>>>>> technically competent
>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and
>>>>>>>>>>>>>>>>>>>>>>>>>> complete
>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the
>>>>>>>>>>>>>>>>>>>>>>>>> simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution
>>>>>>>>>>>>>>>>>>>>>>>>> steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to
>>>>>>>>>>>>>>>>>>>>>>>>> stop running
>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and
>>>>>>>>>>>>>>>>>>>>>>>> COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return
>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is
>>>>>>>>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of
>>>>>>>>>>>>>>>>>>>>>>> this simulated P
>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of
>>>>>>>>>>>>>>>>>>>>>> the function H
>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a
>>>>>>>>>>>>>>>>>>>>>> final state. Which
>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt
>>>>>>>>>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa)
>>>>>>>>>>>>>>>>>>>>>> halts.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its
>>>>>>>>>>>>>>>>>>>>> inputs to an
>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual
>>>>>>>>>>>>>>>>>>>>> behavior that is
>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by
>>>>>>>>>>>>>>>>>>>> the actual
>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct
>>>>>>>>>>>>>>>>>>> simulation of an
>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of
>>>>>>>>>>>>>>>>>>> instructions that
>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the
>>>>>>>>>>>>>>>>>>> concept of UTM
>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate
>>>>>>>>>>>>>>>>>> the behavior of
>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly
>>>>>>>>>>>>>>>>> matches any
>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need
>>>>>>>>>>>>>>>>> to wait until
>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior
>>>>>>>>>>>>>>>> pattern if the
>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion,
>>>>>>>>>>>>>>>> which it doesn't if
>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the
>>>>>>>>>>>>>>> halt status of
>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its
>>>>>>>>>>>>>>> input instead
>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of
>>>>>>>>>>>>> reviewers reject
>>>>>>>>>>>>> everything that I say out-of-hand without even looking at
>>>>>>>>>>>>> it and
>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that
>>>>>>>>>>>>> they hardly
>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>
>>>>>>>>>>>> But is seems you're reading comprehension is failing you
>>>>>>>>>>>> again. I know that when you say "H(P,P) does correctly
>>>>>>>>>>>> determine the halt status of its input", what you really
>>>>>>>>>>>> mean is "there is no implementation of the function H that
>>>>>>>>>>>> can simulate the function call P(P) to a final state". And
>>>>>>>>>>>> that is true, and is what I was agreeing about. That become
>>>>>>>>>>>> more clear with what I said next:
>>>>>>>>>>>>
>>>>>>>>>>>>>> But that's apparently not the same as the halt status of
>>>>>>>>>>>>>> the machine the input represents, specifically Pa(Pa), as
>>>>>>>>>>>>>> per the definition of the function a halt decider is
>>>>>>>>>>>>>> required to compute:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>>
>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything
>>>>>>>>>>>> that follows from here down is bunk because it depends on
>>>>>>>>>>>> the wrong answer being right.
>>>>>>>>>>>>
>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same
>>>>>>>>>>>>> behavior
>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the
>>>>>>>>>>>>> execution
>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>> return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by
>>>>>>>>>>>>> the fact
>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is was supposed to determine the halt status of a
>>>>>>>>>>>>> non-input
>>>>>>>>>>>>> seems absurd and is rejected on the basis that software
>>>>>>>>>>>>> engineering
>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>
>>>>>>>>>>>> If determining the halt status of a non-input seems so
>>>>>>>>>>>> absurd, why do you claim that Ha(Pa,Pa) must report the halt
>>>>>>>>>>>> status of Pn(Pn)?
>>>>>>>>>>>>
>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>
>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>> saying anything like that.
>>>>>>>>>>
>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>>>>
>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate
>>>>>>>>>>> ever reach its
>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>>>>
>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is
>>>>>>>>>> Hn. That also means that Pa is no longer Pa since it's now
>>>>>>>>>> calling Hn. It is now Pn.
>>>>>>>>>>
>>>>>>>>>> So by postulating that Ha has different behavior, you change
>>>>>>>>>> the input. So the above is EXACTLY saying that Ha(Pa,Pa) must
>>>>>>>>>> report on the behavior of Pn(Pn).
>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>>
>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do
>>>>>>>> if its implementation is Hn, then Ha(Pa,Pa) is predicting the
>>>>>>>> behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same
>>>>>>>> behavior of Pn(Pn), and given the
>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>
>>>>>>>>> A simulating halt decider is always correct to abort the
>>>>>>>>> simulation of
>>>>>>>>> any input that it correctly predicts would never otherwise
>>>>>>>>> never stop
>>>>>>>>> running.
>>>>>>>>
>>>>>>>> A simulating halt decider, like any halt decider, is required to
>>>>>>>> map the halting function:
>>>>>>>>
>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>
>>>>>>> Yet in the case of H and P that would require a software function to
>>>>>>> return the result of analyzing a non-input which from a software
>>>>>>> engineering perspective is pure nonsense.
>>>>>>
>>>>>> You don't get to change the question.
>>>>> When the question is WRONG, I do get to change the question.
>>>>
>>>> Are you saying that it's impossible for a function H to implement
>>>> the following specification?
>>>>
>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>
>>> main()
>>> {
>>> H(P,P);
>>> P(P);
>>> }
>>>
>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>> has been executed first and H has not yet been executed then H is
>>> reporting incorrectly, directly against the verified facts.
>>
>> That doesn't answer my question.  Is it possible for to create an
>> algorithm H that implements the following specification?
>>
>> H(X,Y)==1 if and only if X(Y) halts, and
>> H(X,Y)==0 if and only if X(Y) does not halt
>
> *The above specification is incoherent on the basis that*
>
> main()
> {
>  H(P,P);
>  P(P);
> }
>
>  If H(P,P) reports on the behavior of a sequence of instructions
>  where it has been executed first and H has not yet been executed
>  then H is reporting incorrectly, directly against the verified facts.
>
>

On Wednesday, August 3, 2022 at 1:47:42 AM UTC+1, olcott wrote:
> main()
> {
> H(P,P);
> P(P);
> }
>
> If H(P,P) reports on the behavior of a sequence of instructions where P
> has been executed first and H has not yet been executed then H is
> reporting incorrectly, directly against the verified facts.

I think this also may be key to where you are going wrong. H is supposed to determine whether P(P) halts or not. You are now saying that the only behaviour of P that you are able to predict is when H is already running. Thus your answer involves itself in the question.

To take an analogy - suppose you have a voltmeter. It measures very accurately what the voltage across it is when it is connected. However, that voltage is very different from what the voltage would be across the two points when the voltmeter is not connected, due to the current drawn by the voltmeter itself. Most people would say that this was not a good voltmeter (at least for use in testing), no matter how accurately it did measure what it measured.

The same is true for your function H. By your own admission it can only measure what P does when H exists and is running. A halt detector needs to do more than that.

On Wednesday, August 3, 2022 at 11:52:33 AM UTC+1, Andy Walker wrote:
> On 03/08/2022 00:46, olcott wrote:
> > *So you believe the this Wikipedia article is flat out wrong*?
> > For any program H that might determine if programs halt, a
> > "pathological" program P, called with some input, can pass
> > its own source and its input to H and then specifically do
> > the opposite of what H predicts P will do.
> > *No H can exist that handles this case*
> > https://en.wikipedia.org/wiki/Halting_problem
> It's misleading rather than "flat out wrong", and you have been
> misled. P is not a specific program; it is derived from H. Write a
> different H, and the corresponding P changes. It is perfectly possible
> that the "different H" resolves the case of the P that your initial H
> failed with. So P is "pathological" [whatever that is supposed to mean]
> only for that particular H, not as an intrinsic property of P. This is
> disguised in the "impossible program" version because the /function/ P,
> in the form "if H(P,P) then L: goto L endif", looks the same visually
> for all H; but the full /program/ P includes the text of H.
>
> [In particular, if you emulate H, including an "abort" facility,
> then you have a different H, consisting of the emulator and its abort
> facility applied to the original H, and this may possibly be able to
> resolve the original P. But it can't resolve the new P, derived from
> the emulating H.]

Nice post, Andy! I was rather confused by the fact that Olcott appears to be accusing *other people* of disbelieving the Wikipedia page, when his big breakthrough seems to be that he thinks he has produced something which the page says is impossible.

On 8/3/22 7:23 AM, Paul N wrote:
> On Wednesday, August 3, 2022 at 1:47:42 AM UTC+1, olcott wrote:
>> main()
>> {
>> H(P,P);
>> P(P);
>> }
>>
>> If H(P,P) reports on the behavior of a sequence of instructions where P
>> has been executed first and H has not yet been executed then H is
>> reporting incorrectly, directly against the verified facts.
>
> I think this also may be key to where you are going wrong. H is supposed to determine whether P(P) halts or not. You are now saying that the only behaviour of P that you are able to predict is when H is already running. Thus your answer involves itself in the question.
>
> To take an analogy - suppose you have a voltmeter. It measures very accurately what the voltage across it is when it is connected. However, that voltage is very different from what the voltage would be across the two points when the voltmeter is not connected, due to the current drawn by the voltmeter itself. Most people would say that this was not a good voltmeter (at least for use in testing), no matter how accurately it did measure what it measured.
>
> The same is true for your function H. By your own admission it can only measure what P does when H exists and is running. A halt detector needs to do more than that.

The voltmeter analogy is somewhat apt. The CORRECT answer/reading for
the voltmeter exists, even without the voltmeter attached, as "Voltage"
is defined, not by the reading on a Voltmeter, but on a physical
property, the electro-motive potential.

A practical meter, to measure that potential will disturb it somewhat.
But better and better meters will disturbe it less.

In a similar way, the halting of a computation is sort of like a
physical property, the computation WILL either eventually halt or not.
The problem is might take forever to find out the answer that way.

I think this is the piece that Olcott misses, that Mathematics creates a
world with a rich rule set and the rules become "rich" enough that not
all "behaviors" are analytically provable, because our definition of an
analytic proof is a enumerable set of steps, while the richness of
Mathematics creates things which are unenumeratable, but whose ultimate
behavior is emperically demonstrable.

THis means that there CAN exist things that are emperically true, but
not analytically provable.

On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
> On 8/2/2022 7:52 PM, Dennis Bush wrote:
> > On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
> >> On 8/1/2022 8:40 PM, Dennis Bush wrote:
> >>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
> >>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
> >>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
> >>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
> >>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> >>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> >>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>> will never
> >>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
> >>>>>>>>>>>>>>>>>>>>>>>>> ever
> >>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
> >>>>>>>>>>>>>>>>>>>>>>>>> that its
> >>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
> >>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
> >>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
> >>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
> >>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
> >>>>>>>>>>>>>>>>>>>>>>>>> stops its
> >>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
> >>>>>>>>>>>>>>>>>>>>>>>>> Halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
> >>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
> >>>>>>>>>>>>>>>>>>>>>>>>> return 0
> >>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
> >>>>>>>>>>>>>>>>>>>>>>>>> Halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>>>> generate a
> >>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
> >>>>>>>>>>>>>>>>>>>>>>>>> provide the
> >>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
> >>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
> >>>>>>>>>>>>>>>>>>>>>>>>> "proof"
> >>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
> >>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
> >>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
> >>>>>>>>>>>>>>>>>>>>>>>>> into the
> >>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
> >>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
> >>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
> >>>>>>>>>>>>>>>>>>>>>>>> reviewers will
> >>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
> >>>>>>>>>>>>>>>>>>>>>>>> reviewer.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
> >>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
> >>>>>>>>>>>>>>>>>>>>>>>> no longer
> >>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
> >>>>>>>>>>>>>>>>>>>>>>>> its "ret"
> >>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
> >>>>>>>>>>>>>>>>>>>>>>>> before ever
> >>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
> >>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
> >>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>> simulated by H
> >>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
> >>>>>>>>>>>>>>>>>>>>>> whether
> >>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
> >>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
> >>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
> >>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
> >>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
> >>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
> >>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
> >>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
> >>>>>>>>>>>>>>>>>> simulation.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
> >>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
> >>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
> >>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts..
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>>>>>>>>>> H(P,P) aborts its simulation.
> >>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
> >>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>>>>>>>>>> pay any attention to what I say.
> >>>>>>>>>>>
> >>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>>>>>>>>>
> >>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Where I point out you're answering the wrong question.
> >>>>>>>>>>>
> >>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>>>>>>>>>
> >>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
> >>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first..
> >>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>> return;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> int main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> P(P);
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
> >>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
> >>>>>>>>>>>> is essentially the second call of infinite recursion.
> >>>>>>>>>>>>
> >>>>>>>>>>>> H can see the infinite recursion specified by its input and
> >>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
> >>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
> >>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
> >>>>>>>>>>>> its caller.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
> >>>>>>>>>>>> correctly determine the halt status of this input.
> >>>>>>>>>>>>
> >>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
> >>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
> >>>>>>>>>>>> won't allow it.
> >>>>>>>>>>>
> >>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>>>>>>>>>
> >>>>>>>>>> You know that never said anything like that:
> >>>>>>>>>>
> >>>>>>>>>> Try and find a date-and-time stamped quote of me
> >>>>>>>>>> saying anything like that.
> >>>>>>>>>
> >>>>>>>>> That's precisely what the comment I've been quoting is saying:
> >>>>>>>>>
> >>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> >>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
> >>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
> >>>>>>>>>
> >>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >>>>>>>>>
> >>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> >>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> >>>>>>>
> >>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> >>>>>>> of Hn it is essentially the same as a UTM.
> >>>>>>>
> >>>>>>>> A simulating halt decider is always correct to abort the simulation of
> >>>>>>>> any input that it correctly predicts would never otherwise never stop
> >>>>>>>> running.
> >>>>>>>
> >>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
> >>>>>>>
> >>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>
> >>>>>> Yet in the case of H and P that would require a software function to
> >>>>>> return the result of analyzing a non-input which from a software
> >>>>>> engineering perspective is pure nonsense.
> >>>>>
> >>>>> You don't get to change the question.
> >>>> When the question is WRONG, I do get to change the question.
> >>>
> >>> Are you saying that it's impossible for a function H to implement the following specification?
> >>>
> >>> H(X,Y)==1 if and only if X(Y) halts, and
> >>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>
> >> main()
> >> {
> >> H(P,P);
> >> P(P);
> >> }
> >>
> >> If H(P,P) reports on the behavior of a sequence of instructions where P
> >> has been executed first and H has not yet been executed then H is
> >> reporting incorrectly, directly against the verified facts.
> >
> > That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
> >
> > H(X,Y)==1 if and only if X(Y) halts, and
> > H(X,Y)==0 if and only if X(Y) does not halt
> *The above specification is incoherent

On 03/08/2022 01:40, Jeff Barnett wrote:
> On 8/2/2022 5:06 PM, Andy Walker wrote:
>> On 02/08/2022 22:13, Jeff Barnett wrote:
>>> [...]  All the standard proof shows is that
>>> there is no consistent answer for a problem and that is a
>>> contradiction so the (set of) assumptions are inconsistent.
>>      No, that's /not/ what the standard proof shows in relation
>> to the HP.  What it shows is that given any program "H" there are
>> instances of programs and data that "H" fails with, and therefore
>> "H" is not a correct halt decider.  It doesn't show [and how could
>> it?] that those instances are in any way inconsistent, pathological
>> or even difficult to analyse.  Any given program+data combination
>> either halts or fails to halt;  there is no third [or fourth!]
>> possible outcome.
> Try it again. I've said nothing about inconsistent or pathological
> instances. What I said and you quoted me above is that the (set of)
> assumptions are inconsistent since they lead to contradictions.

You said: "there is no consistent answer for a problem". But
that is not what the standard proof shows. Indeed, if we step back a
little, and remove "Let H be a halt decider" from the proof, then what
we are left with is a constructive proof that for any program "H" there
exists a program "P" that "H" fails to decide correctly [but now there
is no contradiction because we no longer claim that "H" does always
decide correctly]. So the contradiction can only come from the extra
claim. Whether a given "P+D" has a consistent answer is a different
problem, not addressed by the standard proof.

> One
> such contradiction is shown in the proof and that is enough. Besides
> the assumption that the h, a halt decider, itself always halts there
> are many other assumptions including the very definition of TM. I've
> never seen a proof that the definition of TM, with or without a halt
> decider definition included, are consistent.

You've also never seen a proof that the fundamental axioms of
arithmetic and logic are consistent, and if you did you would be in an
infinite regress of "provided that the logic used to prove this is
itself consistent". After that, we're in philosophy rather than maths
or computing, and somewhere before there I lose interest.

> In fact the Linz proof
> definitely shows that there is no correct, consistent value to
> return.

But it doesn't. It merely shows that the supposed decider "H"
doesn't return the correct value in this instance. To adapt one of
PO's examples, if you have a program that prints "9" as the answer to
"What is 3+4?", we ascribe that to a bug in the program rather than
to there being no correct consistent answer to the question.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Rubinstein

On 03/08/2022 12:27, Paul N wrote:
[...]
> Nice post, Andy! I was rather confused by the fact that Olcott
> appears to be accusing *other people* of disbelieving the Wikipedia
> page, when his big breakthrough seems to be that he thinks he has
> produced something which the page says is impossible.
Thanks, Paul. Yes, you have produced a concise summary of
what seems to be [one of] the root problem[s]. But people are too
easily side-tracked into whether something is a Proper Function,
when really it scarcely matters.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Rubinstein

On 8/3/2022 6:23 AM, Paul N wrote:
> On Wednesday, August 3, 2022 at 1:47:42 AM UTC+1, olcott wrote:
>> main()
>> {
>> H(P,P);
>> P(P);
>> }
>>
>> If H(P,P) reports on the behavior of a sequence of instructions where P
>> has been executed first and H has not yet been executed then H is
>> reporting incorrectly, directly against the verified facts.
>
> I think this also may be key to where you are going wrong. H is supposed
> to determine whether P(P) halts or not.

In computability theory, the halting problem is the problem
of determining, from a description of an arbitrary computer
program and an input, whether the program [*specified by this
description*] will finish running or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem

P(P) is not a "description of an arbitrary computer program and an
input" it is a running process.

int sum(int x, int y) { return x + y; }
sum(3,4) must return the sum of 3+4 and
its not allowed to return the sum of 4+5.

Likewise H must determine the behavior of its input and must not
determine the behavior of any non-input.

> You are now saying that the only behaviour of P that you are able to predict is when H is already running.

In other words when H(P,P) has not been run will it not return any result.

> Thus your answer involves itself in the question.
>
> To take an analogy - suppose you have a voltmeter. It measures very accurately what the voltage across it is when it is connected. However, that voltage is very different from what the voltage would be across the two points when the voltmeter is not connected, due to the current drawn by the voltmeter itself. Most people would say that this was not a good voltmeter (at least for use in testing), no matter how accurately it did measure what it measured.
>
> The same is true for your function H. By your own admission it can only measure what P does when H exists and is running. A halt detector needs to do more than that.

In other words you are saying that H(P,P) must return a result even if
it does not exist or before it has ever been run?

--
Copyright 2022 Pete Olcott

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

On 8/3/22 7:48 AM, Andy Walker wrote:
> On 03/08/2022 01:40, Jeff Barnett wrote:
>> On 8/2/2022 5:06 PM, Andy Walker wrote:
>>> On 02/08/2022 22:13, Jeff Barnett wrote:
>>>> [...]  All the standard proof shows is that
>>>> there is no consistent answer for a problem and that is a
>>>> contradiction so the (set of) assumptions are inconsistent.
>>>      No, that's /not/ what the standard proof shows in relation
>>> to the HP.  What it shows is that given any program "H" there are
>>> instances of programs and data that "H" fails with, and therefore
>>> "H" is not a correct halt decider.  It doesn't show [and how could
>>> it?] that those instances are in any way inconsistent, pathological
>>> or even difficult to analyse.  Any given program+data combination
>>> either halts or fails to halt;  there is no third [or fourth!]
>>> possible outcome.
>> Try it again. I've said nothing about inconsistent or pathological
>> instances. What I said and you quoted me above is that the (set of)
>> assumptions are inconsistent since they lead to contradictions.
>
>     You said: "there is no consistent answer for a problem".  But
> that is not what the standard proof shows.  Indeed, if we step back a
> little, and remove "Let H be a halt decider" from the proof, then what
> we are left with is a constructive proof that for any program "H" there
> exists a program "P" that "H" fails to decide correctly [but now there
> is no contradiction because we no longer claim that "H" does always
> decide correctly].  So the contradiction can only come from the extra
> claim.  Whether a given "P+D" has a consistent answer is a different
> problem, not addressed by the standard proof.
>
>>                                   One
>> such contradiction is shown in the proof and that is enough. Besides
>> the assumption that the h, a halt decider, itself always halts there
>> are many other assumptions including the very definition of TM. I've
>> never seen a proof that the definition of TM, with or without a halt
>> decider definition included, are consistent.
>
>     You've also never seen a proof that the fundamental axioms of
> arithmetic and logic are consistent, and if you did you would be in an
> infinite regress of "provided that the logic used to prove this is
> itself consistent".  After that, we're in philosophy rather than maths
> or computing, and somewhere before there I lose interest.
>
>>                            In fact the Linz proof
>> definitely shows that there is no correct, consistent value to
>> return.
>
>     But it doesn't.  It merely shows that the supposed decider "H"
> doesn't return the correct value in this instance.  To adapt one of
> PO's examples, if you have a program that prints "9" as the answer to
> "What is 3+4?", we ascribe that to a bug in the program rather than
> to there being no correct consistent answer to the question.
>

The key is that FOR A GIVEN FIXED DECIDER H, there always is a precise
answer for does P(P) Halt, when P is built on that decider.

THAT is the question of the Halting Problem, FOR A GIVEN MACHINE.

The question of What Can H return, isn't that problem, but a design
problem to try and find an H that might be able to work.

For THAT problem, P isn't a "Fixed" machine, but a machine that changes
everytime we change H, and yes, we can determine that there is no value
we can return that gives the right answer for this template.

This doesn't prove the "Halting Problem" question doesn't have a
consistent answer, because we weren't asking the halting problem question.

What we proved is that the is no machine that can correctly answer the
Halting problem for this form of question, not that the question doesn't
have an answer for any particular machine.

On 8/2/2022 8:40 PM, Richard Damon wrote:
>
> On 8/2/22 8:45 PM, olcott wrote:
>> On 8/2/2022 1:56 PM, Mikko wrote:
>>> On 2022-08-02 18:44:24 +0000, Mr Flibble said:
>>>
>>>> On Tue, 2 Aug 2022 21:41:54 +0300
>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>
>>>>> On 2022-08-02 16:11:54 +0000, Mr Flibble said:
>>>>>
>>>>>> On Tue, 2 Aug 2022 19:07:33 +0300
>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>
>>>>>>> On 2022-08-01 12:54:04 +0000, olcott said:
>>>>>>>
>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>> actually specified by these inputs.
>>>>>>>
>>>>>>> The halting problem does not require that. It merely says (or
>>>>>>> implies -- each author uses different words but they aways mean
>>>>>>> the same) that
>>>>>>> - if H(M, I) returns false and M(I) halts then H is not a halt
>>>>>>> decider
>>>>>>> - if H(M, I) returns true and M(I) doesn't halt then H is not a
>>>>>>> halt decider
>>>>>>> - if H(M, I) returns something else then H is not a halt decider
>>>>>>> - if H(M, I) does not return then H is not a halt decider
>>>>>>> - otherwise H is a halt decider
>>>>>>
>>>>>> I can add to that (my key insight):
>>>>>>
>>>>>> - if H(M, I) doesn't signal an exception on pathological
>>>>>> ("Impossible Program") input then H is not a halt decider.
>>>>>
>>>>> No, you can't. The problem definition is what it is and you
>>>>> can't add anything to it, and it says or at least imlies that
>>>>> if H(M, I) signals an exception it is not a halt decider.
>>>>
>>>> Yes I can and I have. I have extended the definition of a halt decider.
>>>>
>>>> /Flibble
>>>
>>> If there is two conflicting definitions for the same term the definition
>>> published earlier is the valid one.
>>>
>>> Mikko
>>>
>>
>>  >
>> main()
>> {
>>    H(P,P);
>>    P(P);
>> }
>>
>> If H(P,P) reports on the behavior of a sequence of instructions where
>> P has been executed first and H has not yet been executed then H is
>> reporting incorrectly, directly against the verified facts.
>>
>>
>
> The sequence of instruction that H gets are the same either way. What
> has happend before the call to H can not affect its behavior if H is a
> pure function.
When a "pathological" relationship between H and P has been defined this
necessitates that the order of execution of H and P makes a difference.
To ignore this necessity is simply ignorance.

My pure function version of H always returns the same value for the same
inputs every time that it is invoked. In this pure function version of H
(where the infinite recursion is more difficult to see) the simulation
of P is aborted before H is ever invoked.

--
Copyright 2022 Pete Olcott

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

On 8/3/2022 6:46 AM, Dennis Bush wrote:
> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>>>>>>>
>>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>>
>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>>> saying anything like that.
>>>>>>>>>>>
>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>>>>>
>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>>>>>
>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>>>>>>>
>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>>>
>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>>
>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
>>>>>>>>>> running.
>>>>>>>>>
>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
>>>>>>>>>
>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>
>>>>>>>> Yet in the case of H and P that would require a software function to
>>>>>>>> return the result of analyzing a non-input which from a software
>>>>>>>> engineering perspective is pure nonsense.
>>>>>>>
>>>>>>> You don't get to change the question.
>>>>>> When the question is WRONG, I do get to change the question.
>>>>>
>>>>> Are you saying that it's impossible for a function H to implement the following specification?
>>>>>
>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>
>>>> main()
>>>> {
>>>> H(P,P);
>>>> P(P);
>>>> }
>>>>
>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>>> has been executed first and H has not yet been executed then H is
>>>> reporting incorrectly, directly against the verified facts.
>>>
>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
>>>
>>> H(X,Y)==1 if and only if X(Y) halts, and
>>> H(X,Y)==0 if and only if X(Y) does not halt
>> *The above specification is incoherent
>
> So you're saying that it's impossible to create an H that meets this specification?