On 8/1/22 9:31 PM, olcott wrote:
> On 8/1/2022 8:06 PM, Richard Damon wrote:
>> On 8/1/22 7:38 PM, olcott wrote:
>>> On 8/1/2022 6:06 PM, Paul N wrote:
>>>> On Monday, August 1, 2022 at 11:34:37 PM UTC+1, olcott wrote:
>>>>> 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) ?
>>>>
>>>> The first argument in the call H(P, P) is P. The second argument is
>>>> also P. Thus H(P, P) is supposed to determine whether P(P) halts or
>>>> not. That is the "input" to H.
>>>
>>> No it is not the input to H.
>>>
>>> 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.
>>
>> Maybe "essentially", but only in the sense of not quite. It WOULD be
>> infiite recursion if H(P,P) doesn't abort its simulation, but since it
>> does, it isn't.
>>
>> Not because H aborted its simulation, but because it returns 0 to its
>> caller, which might be P(P), which makes P(P) Halting.
>>
>>>
>>> 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.
>>
>> No, H THINKS it sees infinite recursion because it isn't smart enough
>> to see that the H that it sees being called WILL abort its simulation
>> too (if this one does) and thus breaks the recursion that it thinks it
>> sees.
>>
>>>
>>> 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.
>>
>> Nope, your using the wrong definition. Once H(P,P) includes the
>> instructions to abort its simulation then because of the
>> "pathological" self-reference, the input it is simulating will do so
>> also, just after the point that H simulates.
> The correctly simulated input to H(P,P) cannot possibly reach is "ret"
> instruction (final state) and halt even when its simulation is aborted.

Right, which doesn't prove your conclusion, because, as you next
statement shows, halting isn't defined by simulation, but by the actual
execution of the machine.

Only a simulation that actually replicates the machine directly show
halting or non-halting. Thus, an aborted simulation doesn't, in and of
itself, show non-halting.

Yes, it is possible to prove from SOME partial simulations that the
input actually is non-halting, but such a proof needs to be sound and valid.

The fact that P(P) Halts if H(P,P) returns 0, says that ANY proof that
tries to show that H(P,P) returning 0 is correct, MUST be flawed. I have
pointed out the error in the "proof" that you have presented. Your
continuing to make the claim shows that you either are too stupid to
understand the logic, or are just a pathological liar and don't care
what is actually true.

You seem to not understand the difference between actually executing a
Turing Machine and conditionally simulating one, or refuese to let that
difference get in your way of lying about what you are talking about.

>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>

Right, THE TURING MACHINE, that is P(P), which HALTS if H(P,P) returns
0, so that can't be the correct answer.

On 8/1/22 9:37 PM, 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.

On 8/1/2022 8:26 PM, Richard Damon wrote:
>
> On 8/1/22 9:05 PM, 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.
>
> But it ISN'T a "non-input", or you have just defined that NO Halt
> decider could exist.
>

On 8/1/22 9:50 PM, olcott wrote:
> On 8/1/2022 8:26 PM, Richard Damon wrote:
>>
>> On 8/1/22 9:05 PM, 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.
>>
>> But it ISN'T a "non-input", or you have just defined that NO Halt
>> decider could exist.
>>
>
> int main()
> {
>   H(P,P); // H is invoked first
>   P(P);   // P is invoked first
> }
>
> Thus the input to H(P,P) specifies a different sequence of instructions
> than the direct execution of P(P).

On Tuesday, 2 August 2022 at 03:50:20 UTC+2, olcott wrote:

> int main()
> {
> H(P,P); // H is invoked first
> P(P); // P is invoked first
> }
>
> Thus the input to H(P,P) specifies a different sequence of instructions
> than the direct execution of P(P).

No, it doesn’t.

A(B) means “apply A to B”
B(A(C))) means “Apply B to (apply A to C))”
B(A,C) means the same thing as B(A(C))

Currying. You don’t understand it.

https://en.wikipedia.org/wiki/Currying

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? Your H only predicts what will happen when your H simulates a call of P(P)?

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.

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

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

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?

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

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.

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

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

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.

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.

--
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 Tuesday, August 2, 2022 at 9:57:01 AM UTC-4, 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?

Because both are the same sequence.

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

And the line-by-line execution trace of the x86 emulation of the input to Ha3(N,5) by Ha3 exactly matches the line-by-line x86 source-code of N.

Ha3(N,5)==0 is obviously incorrect, so the above claim doesn't prove anything.

>
> There are few things that annoy me more than when people ignore the
> verified facts so that they can hold onto their opinion.

You mean like the fact that Ha(Pa,Pa) is required to report if Pa(Pa) halts?

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

H doesn't start by simulating itself, it starts by simulating P. So the instructions of the direct execution of P are the same as the instructions that H(P,P) is simulating.

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

Correct but not complete, and you need both. The correct *and complete* simulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts.

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

The software engineering fact is that H is does not implement the required 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

You didn't answer before so I'll ask again: Is it possible to create an algorithm H that meets the above specification?

> H(P,P) does correctly report on the sequence of instructions that it was
> presented with that begins with itself.

No it doesn't. Contrary to the requirements, Ha(Pa,Pa) is reporting on Pn(Pn) instead of Pa(Pa).

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

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

Mikko

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.

/Flibble

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!
--
Jeff Barnett

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

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", and of course if they do they will
fall foul of Rice's Theorem. 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!

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

On Tuesday, 2 August 2022 at 20:17:07 UTC+2, Mr Flibble wrote:
> 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.

Redefining a shit as sugar won't make it taste any sweeter.

The issue is not about definitions. The issue is... argh. Never mind. You don't really care what the issue is. Do you?

On Tue, 2 Aug 2022 11:25:18 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Tuesday, 2 August 2022 at 20:17:07 UTC+2, Mr Flibble wrote:
> > 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.
>
> Redefining a shit as sugar won't make it taste any sweeter.
>
> The issue is not about definitions. The issue is... argh. Never mind.
> You don't really care what the issue is. Do you?

Actually at the moment the issue *is* about definitions. The only
rebuttal of my solution I have received so far is that my decider isn't
a halt decider because it defines a third outcome: invalid input.

/Flibble

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.

Mikko

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

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

On Tue, 2 Aug 2022 21:56:19 +0300
Mikko <mikko.levanto@iki.fi> 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.

Who says?

/Flibble

On Tuesday, 2 August 2022 at 20:38:53 UTC+2, Mr Flibble wrote:
> On Tue, 2 Aug 2022 11:25:18 -0700 (PDT)
> Skep Dick <skepd...@gmail.com> wrote:
>
> > On Tuesday, 2 August 2022 at 20:17:07 UTC+2, Mr Flibble wrote:
> > > 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.
> >
> > Redefining a shit as sugar won't make it taste any sweeter.
> >
> > The issue is not about definitions. The issue is... argh. Never mind.
> > You don't really care what the issue is. Do you?
> Actually at the moment the issue *is* about definitions. The only
> rebuttal of my solution I have received so far is that my decider isn't
> a halt decider because it defines a third outcome: invalid input.

No, it's not about definitions.

If it was about definitions then your "halt decider" needs one more output!

Your halting decider needs at least one more output: The output which signals "I am not going to halt on this input"

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.

Ehh? That's bullshit.

There are no preferential definitions. Equivalent definitions are equivalent. Lambda calculus and Turing machines are equivalent definitions of "computation".

Lambda Calculus and Turing machines are *NOT* equivalent definitions of "computation" to Infinite Time Turing Machines.

A more complete definition is a better definition. And more complete definitions ALWAYS come later.

On Tuesday, 2 August 2022 at 20:38:53 UTC+2, Mr Flibble wrote:
> Actually at the moment the issue *is* about definitions. The only
> rebuttal of my solution I have received so far is that my decider isn't
> a halt decider because it defines a third outcome: invalid input.

You keep making the exact same errors as Olcott. Probably because you are Olcott. He doesn't understand Currying either.

Having one function which answers two different questions( Does it halt? is it valid?) is the same as having two separate deciders.

bool check_validity(P);
bool check_halting(P);

bool answers[2] fibble_decider(P){
answers[0] = check_validity(P);
answers[1] = check_halting(P);
return answers;
}

On Tue, 2 Aug 2022 12:33:11 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Tuesday, 2 August 2022 at 20:38:53 UTC+2, Mr Flibble wrote:
> > Actually at the moment the issue *is* about definitions. The only
> > rebuttal of my solution I have received so far is that my decider
> > isn't a halt decider because it defines a third outcome: invalid
> > input.
>
> You keep making the exact same errors as Olcott. Probably because you
> are Olcott. He doesn't understand Currying either.
>
> Having one function which answers two different questions( Does it
> halt? is it valid?) is the same as having two separate deciders.
>
> bool check_validity(P);
> bool check_halting(P);
>
> bool answers[2] fibble_decider(P){
> answers[0] = check_validity(P);
> answers[1] = check_halting(P);
> return answers;
> }

How can it be the same? My solution has THREE outcomes whereas your
nonsense has FOUR outcomes. Last time I checked 3 != 4.

/Flibble