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.

Read your definition of what P does, P asks H about what it does with
its input, and you coded that as H(P,P).

That means, that if the input to H(P,P) doesn't actually represent P(P),
you need to fix your definitoin of P to actually ask H about P(P).

If you can't ask H about P(P), then it can't be giving the correct
halting problem answer for that machine, can it.

Remember, the Halting Problem is DEFINED based on H answering about A
MACHINE and its INPUT, based on being given a representation of that
machine and input.

If there is a machine you can't give it, it just fails to be the needed
decider for that machine, and thus CAN'T be the decider that decides for
ALL MACHINES AND INPUTS.

Note the input domain is all machines and inputs, not every input you
could legally give to H.

One of the steps we have glossed over is showing that you decider can be
given representation of all machines/input combinations, because you
would fail that test (maybe you can find some unusual wording for your
definition of a machine to pass) as you can't give it as an input any
machine that has some other code besides H at the addresses that H uses.

This actually gives you problems with your claim that the x86 assembly
is the actual definition of the machines (and not the source code) as
clearly there are machines that could be designed that can't be given to H.