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.

And then in 5, we are talking about the direct execution of P(P)
(perhaps by a call to it in main) and H can't abort THAT invocation of P
without ending up not answering when main calls H(P,P), unless your H
fails to be a Pure Function.

Your mind just isn't thinking but throwing out rote responses that just
don't make sense.

WHO is acting ROTELY. Not us "Learned by Rote" people who understand
what we are talking about.

>
>> 3) P, as the impossible program, is defined to as H about the behavior
>> or itself with its input
>>
>> 4) This means the call to H(P,P) is defined to be asking H about the
>> behavor of P(P)
>>
>> 5) The ACTUAL program P(P) when run, will return (aka Halt) if H(P,P)
>> returns 0.  You have admited this and even posted traces of this.
>>
>
> So again you reject that a UTM is a coherent concept.
> The correct simulation of a machine <is> computationally equivalent to
> the underlying computation.

Not at all, but a UTM is only defined in terms of it matching the actual
behavior of the actual machine.

or, is the problem that in your world we don't actually have any actual
machhines, but only simuations of them?

Are you disagreeing that you actually posted a trace of the running of
main calling P(P), and that P(P) calling H(P,P) and then that H
returning the value 0 to that P that called it and it returning?

THAT TRACE shows the actual behavior of P (within the errors that you
don't actually trace what happens in H, but summarize it).

BY DEFINITION, UTM(P,P) must generate the same results as P(P), or it
isn't a UTM. You seem to have a problem with that definition.

>
>> 6) The definition of a correct simulation is a simulation that matches
>> the behavior of the thing it is simulationg.
>>
>> 7) Therefore, since the input to H(P,P) refers to P(P) (by 4), and
>> P(P) is proved to halt if H(P,P) returns 0 (by 5), by the definition
>> of correct simulation, the correct simulation of the input to H(P,P)
>> must halt.
>>
>> 8) Thus, by either the REAL definition that H needs to answer based on
>> the behavior of the actual machine, or by the alternate acceptable
>> definition that looks at a correct and complete simulation of the
>> input, the input to H(P,P) Halts, and thus the CORRECT answer is
>> Accept/Halitng/1 not the 0 it provided.
>
>
>
>>
>> Your problem is that you say "Once" the non-halting pattern is
>> correctly detected, which implies that there IS a finite non-halting
>> pattern in the simulation of P(P) that can be detected.
>>
>> It has be PROVEN that ANY pattern ih the simulation of P(P) by H that
>> is added to H as a claimed non-halting pattern, then that make the
>> behavior of that P(P) (and the correct simulation of the input to
>> H(P,P)) to be Halting, as when H detects that pattern in its
>> simulation of P(P), and returns to P, P will return (aka halt) and
>> then when we look at the CORRECT AND COMPLETE simulation of the input,
>> we see that shortly after H INCORRECTLY gave up convinced that the
>> input was non-halting, that the simulation then sees (as it simulates
>> H) the simulated H making that decision, and returning to the P that
>> called that simulated H, and that P then returning (aka Halting).
>>
>> Thus, there does not exist a finite pattern that H can reach in finite
>> time to detect.
>>
>> Thus, H either simulates forever and fails to be a decider, or uses an
>> invalid pattern and incorrectly determines non-halting and gives the
>> wrong anwwer.
>>
>> You are presuming the existance of something not known to exist (and
>> in fact proven to not exist).
>
> That you simply don't have the technical skills to understand what I am
> saying is no rebuttal at all.

So, no errors actually pointed out in what I said, just your own
perverted rambings about things you don't understand.

No refutation, therefore my proof still stands and you are show to be
wrong and have created an inconsistent logic system with you added
erroneous rules.

Or, are you saying in your first comment that the source code of P, when
given the parameter P doesn't actually call H(P,P)?

>
> This has been updated to include the complete execution trace of
> main() { P(P); } which also includes H(P,P) correctly returning 0 to P(P);
>
> *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 your AGREE that P(P) Halts (it dopesn't matter why!) and thus BY
DEFINITION H(P,P) needs to accept/return 1

Remember the DEFINITION of a Halt Decider:

H(M,w) accepts in M(w) Halts and rejects if M(w) never halts.

Since you have just shown that P(P) Halts (and the above defintion
doesn't put limits on WHY it halts, it just is a fact that it does
halt), then the ONLY correct answer from H(P,P) is to accept.