On 7/17/22 11:45 PM, olcott wrote:
> On 7/17/2022 9:53 PM, Richard Damon wrote:
>> On 7/17/22 9:48 PM, olcott wrote:
>>> On 7/17/2022 8:27 PM, Richard Damon wrote:
>>>>
>>>> On 7/17/22 8:56 PM, olcott wrote:
>>>>> On 7/17/2022 4:10 PM, Richard Damon wrote:
>>>>>> On 7/17/22 3:42 PM, olcott wrote:
>>>>>>> On 7/17/2022 2:20 PM, Richard Damon wrote:
>>>>>>>> On 7/17/22 2:15 PM, olcott wrote:
>>>>>>>>> On 7/17/2022 11:55 AM, Richard Damon wrote:
>>>>>>>>>> On 7/17/22 12:47 PM, olcott wrote:
>>>>>>>>>>> On 7/17/2022 11:41 AM, Richard Damon wrote:
>>>>>>>>>>>> On 7/17/22 9:23 AM, olcott wrote:
>>>>>>>>>>>>> On 7/17/2022 6:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/16/22 11:11 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/16/2022 10:54 AM, Mike Terry wrote:
>>>>>>>>>>>>>>>  > On 16/07/2022 12:23, Paul N wrote:
>>>>>>>>>>>>>>>  > PO's simulation is correct at the individual
>>>>>>>>>>>>>>> instruction level.
>>>>>>>>>>>>>>>  > His H steps the simulation forward a number of steps,
>>>>>>>>>>>>>>> and each
>>>>>>>>>>>>>>>  > of those steps exactly matches the P(P) calculation
>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can see from the x86 execution trace of the simulated
>>>>>>>>>>>>>>> P that the behavior of this simulated P exactly matches
>>>>>>>>>>>>>>> its x86 source-code, line-by-line.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What we can also see from this same execution trace is
>>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck
>>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever
>>>>>>>>>>>>>>> preventing this simulated P from ever terminating
>>>>>>>>>>>>>>> normally by reaching its C:"return" or x86:"ret"
>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except it doesn't because H is KNOWN to abort its
>>>>>>>>>>>>>> simulation when it sees that the simulation will reach the
>>>>>>>>>>>>>> first call to H in the simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You logic is based on the assumption that H actually won't
>>>>>>>>>>>>>> stop simulating its input, when in actual fact it will.
>>>>>>>>>>>>>> Thus you have a false premise in your logic, so H never
>>>>>>>>>>>>>> actually proved its fact considering the H that it is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, H can prove that IF H never aborts, that this makes a
>>>>>>>>>>>>>> P that never halts. But since this is NOT the definition
>>>>>>>>>>>>>> of H, that doesn't say anything about what the machine
>>>>>>>>>>>>>> where H does abort its simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Halting means terminated normally when the correctly
>>>>>>>>>>>>> simulated P reaches its last instruction. Even though I
>>>>>>>>>>>>> have corrected you on this many hundreds of times you still
>>>>>>>>>>>>> fail to understand that an aborted simulation does not mean
>>>>>>>>>>>>> that the simulated input halted. You are moronically stupid
>>>>>>>>>>>>> on this point.
>>>>>>>>>>>>
>>>>>>>>>>>> And YOU are the moron for thinking that just because a
>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that input
>>>>>>>>>>>> can't continue to reach the final state.
>>>>>>>>>>>
>>>>>>>>>>> Your replies are moronically stupid because they always make
>>>>>>>>>>> sure to maimtain the same false assumptions (utterly
>>>>>>>>>>> impervious to all reason) even when these false assumptions
>>>>>>>>>>> corrected hundreds of times.
>>>>>>>>>>
>>>>>>>>>> NAME ONE FALSE ASSUMPTION!
>>>>>>>>>>
>>>>>>>>> On 7/16/2022 2:28 PM, Mike Terry wrote:
>>>>>>>>>  > On 16/07/2022 17:40, Richard Damon wrote:
>>>>>>>>>  >> But "incomplete" is incorrect if your logic assumes that the
>>>>>>>>>  >> simulation not reaching the final state PROVES non-halting.
>>>>>>>>>  >
>>>>>>>>>  > I don't believe PO thinks that, irrespective of how badly he
>>>>>>>>> explains
>>>>>>>>>  > things.  I think he believes that the simulation would never
>>>>>>>>> halt
>>>>>>>>>  > *because his never-halting-abort test matched*, NOT simply as a
>>>>>>>>>  > consequence of aborting.  E.g. he seems to understand that a
>>>>>>>>> simulator
>>>>>>>>>  > that steps 10 steps then stops regardless, does not imply
>>>>>>>>> that the
>>>>>>>>>  > simulated computation does not halt.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> SO, whats wrong with my statement.
>>>>>>>>
>>>>>>>> An incomplete simulation not reaching a halting state does NOT
>>>>>>>> prove that the input is non-halting.
>>>>>>>>
>>>>>>> *Yes it does, this is simply over your head*
>>>>>>> Once a non-halting behavior pattern is correctly matched the
>>>>>>> simulation can be aborted and the input rejected as non-halting.
>>>>>>>
>>>>>>
>>>>>> No, you are totally wrong on that. If you say I am mistaken, which
>>>>>> of these statements, which PROVE my point, is in error? If none
>>>>>> are, then my statement is PROVEN. Note, these are based on the
>>>>>> well established definition of Computation Theory and statement
>>>>>> YOU have made about your program.
>>>>>>
>>>>>> Just claiming you have proven the opposite is NOT enough, as all
>>>>>> that does is show that your logic system is inconsistent, because
>>>>>> you have added inconsistent rules to your system (likely rules
>>>>>> that just aren't true).
>>>>>>
>>>>>> 1) You claim H(P,P) correctly returns 0, so H(P,P) must actually
>>>>>> be returning 0.
>>>>>>
>>>>>> 2) P calls H(P,P)
>>>>>>
>>>>>
>>>>> P is aborted before the call is ever made.
>>>>> This seems to be the key to overcome referential transparency.
>>>>
>>>> Just you proving your an idiot, and not reading?
>>>>
>>>> That was saying that the SOURCE CODE of P calls H(P,P)
>>>>
>>>> There IS no "Aborts" at the source code level.
>>> We have been talking about this for many months and you haven't
>>> noticed that H operates at the machine language level?
>>>
>>
>> But the code for P was still specified at a source code level.
>>
>> You keep on trying to say that the behavior of the input to H(P,P)
>> doesn't match the behavior of P(P), but the point you miss is that
>> then your code for P is wrong.
>
> You are simply too stupid to verify that facts to prove that it is correct.
>
> *Halting problem proofs refuted on the basis of software engineering*
>
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>
>

So, you are admitting that there is no error in my claim and it IS a
fact that H does not correctly determine to Halting of P(P)?

Then who is the one too stupid to verify facts?

Note, if my proof is correct, and your proof is corret, all this proves
is that the extra rules you added to your logic make your logic system
inconsistent, by the basic definition of inconsistency.