On 1/21/24 3:24 PM, olcott wrote:
> On 1/20/2024 7:50 PM, Richard Damon wrote:
>> On 1/20/24 8:30 PM, olcott wrote:
>>> On 1/20/2024 7:24 PM, Richard Damon wrote:
>>>> On 1/20/24 8:15 PM, olcott wrote:
>>>>> On 1/20/2024 6:53 PM, Richard Damon wrote:
>>>>>> On 1/20/24 3:47 PM, olcott wrote:
>>>>>>> On 1/20/2024 2:28 PM, Richard Damon wrote:
>>>>>>>> On 1/20/24 1:21 PM, olcott wrote:
>>>>>>>>> On 1/20/2024 11:52 AM, Richard Damon wrote:
>>>>>>>>>> On 1/20/24 12:47 PM, olcott wrote:
>>>>>>>>>>> On 1/20/2024 11:39 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/20/24 10:12 AM, olcott wrote:
>>>>>>>>>>>>> On 1/20/2024 6:22 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/19/24 11:29 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/19/2024 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/19/24 10:28 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/19/2024 9:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/19/24 9:55 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/19/2024 8:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/19/24 9:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2024-01-19 18:26, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The full state of D was repeated.
>>>>>>>>>>>>>>>>>>>>>>> The only thing that changed was the stack address.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The contents of the stack and the stack address
>>>>>>>>>>>>>>>>>>>>>> are *part* of the state of the machine. If they
>>>>>>>>>>>>>>>>>>>>>> change, you are not repeating the same state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Everything is identical across recursive
>>>>>>>>>>>>>>>>>>>>> simulations besides
>>>>>>>>>>>>>>>>>>>>> the stack address. The stack address is irrelevant
>>>>>>>>>>>>>>>>>>>>> to whether
>>>>>>>>>>>>>>>>>>>>> or not DD halts.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope, and part of the problem is you stopped looking
>>>>>>>>>>>>>>>>>>>> at the actual simulaiton of the input.  The
>>>>>>>>>>>>>>>>>>>> simulator being simulated at the first call will be
>>>>>>>>>>>>>>>>>>>> in a different state at the second call to H then it
>>>>>>>>>>>>>>>>>>>> was when it started, just like the outer HH doing
>>>>>>>>>>>>>>>>>>>> the simulation has built up the history shown.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That means that, if we continued an actual correct
>>>>>>>>>>>>>>>>>>>> simulation of this exact input (and thus didn't
>>>>>>>>>>>>>>>>>>>> change HH, but gave the input to a proper UTM
>>>>>>>>>>>>>>>>>>>> simulator) we would see that the first simulated HH
>>>>>>>>>>>>>>>>>>>> would run one more level of simulation, and then
>>>>>>>>>>>>>>>>>>>> abort its simulation, and then return to DD and it
>>>>>>>>>>>>>>>>>>>> would halt.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thus, your simulation just isn't showing the actual
>>>>>>>>>>>>>>>>>>>> "state" of the program (in fact, you arn't even
>>>>>>>>>>>>>>>>>>>> showing the state of the program, since the key
>>>>>>>>>>>>>>>>>>>> state for this program is what is happening in the
>>>>>>>>>>>>>>>>>>>> HH that DD is calling)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The "recursive" layer SHOULD be showing up as the
>>>>>>>>>>>>>>>>>>>> instruction sequence of the simulator simulating
>>>>>>>>>>>>>>>>>>>> those instructions, and thus showing that state
>>>>>>>>>>>>>>>>>>>> being generated.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That second layer never actually shows as a direct
>>>>>>>>>>>>>>>>>>>> simulation in the proper simulation of the input,
>>>>>>>>>>>>>>>>>>>> except maybe as interspresed comment of the
>>>>>>>>>>>>>>>>>>>> simulated HH just simulated this instruction.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If you are going to try to abstract out that
>>>>>>>>>>>>>>>>>>>> simulation, you need to do it properly, and that
>>>>>>>>>>>>>>>>>>>> means that the simulation level IS part of state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The easily verified fact that DD simulated by HH
>>>>>>>>>>>>>>>>>>>>> cannot possibly
>>>>>>>>>>>>>>>>>>>>> reach its own simulated final state conclusively
>>>>>>>>>>>>>>>>>>>>> proves that DD
>>>>>>>>>>>>>>>>>>>>> does not halt.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, that only hold *IF* HH correctly simulates the
>>>>>>>>>>>>>>>>>>>> input, which means that HH can NEVER abort its
>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation
>>>>>>>>>>>>>>>>>>>>> Execution Trace Stored at:113027
>>>>>>>>>>>>>>>>>>>>> [00001c42][00113013][00113017] 55          push ebp
>>>>>>>>>>>>>>>>>>>>> [00001c43][00113013][00113017] 8bec        mov ebp,esp
>>>>>>>>>>>>>>>>>>>>> [00001c45][0011300f][00102fe3] 51          push ecx
>>>>>>>>>>>>>>>>>>>>> [00001c46][0011300f][00102fe3] 8b4508      mov
>>>>>>>>>>>>>>>>>>>>> eax,[ebp+08] ; DD
>>>>>>>>>>>>>>>>>>>>> [00001c49][0011300b][00001c42] 50          push eax
>>>>>>>>>>>>>>>>>>>>> ; DD
>>>>>>>>>>>>>>>>>>>>> [00001c4a][0011300b][00001c42] 8b4d08      mov
>>>>>>>>>>>>>>>>>>>>> ecx,[ebp+08] ; DD
>>>>>>>>>>>>>>>>>>>>> [00001c4d][00113007][00001c42] 51          push ecx
>>>>>>>>>>>>>>>>>>>>> ; DD
>>>>>>>>>>>>>>>>>>>>> [00001c4e][00113003][00001c53] e80ff7ffff  call
>>>>>>>>>>>>>>>>>>>>> 00001362 ; HH
>>>>>>>>>>>>>>>>>>>>> New slave_stack at:14da47
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Note. error in simulation here. Call to HH should be
>>>>>>>>>>>>>>>>>>>> showing the states of operation of HH
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Tell me how the behavior of HH can possibly show that
>>>>>>>>>>>>>>>>>>> DD reaches its final state and I will provide a link
>>>>>>>>>>>>>>>>>>> with the 151 pages of the execution trace of HH.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It can't in its simulation, but an actually correct
>>>>>>>>>>>>>>>>>> simulation of the input, which HH doesn't do, can.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *When I challenge you to show what the correct detailed*
>>>>>>>>>>>>>>>>> *line-by-line machine address by machine address steps*
>>>>>>>>>>>>>>>>> *SHOULD BE you consistently utterly fail because you
>>>>>>>>>>>>>>>>> really*
>>>>>>>>>>>>>>>>> *don't know Jack about these things and are just bluffing*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> i.e. I'm not falling for your strawman and are panicing
>>>>>>>>>>>>>>>> as badly as your buddy Trump.
>>>>>>>>>>>>>>> Trump is a Hitler wanna bee.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yep, and you are no better.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You use the same lying techniques as he does, even though
>>>>>>>>>>>>>> you CLAIM to be fighting those techniques (that makes you
>>>>>>>>>>>>>> the Hypocrite)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *You failed try again*
>>>>>>>>>>>>>>> I show 16 lines of machine code
>>>>>>>>>>>>>>> *you must show ever detail of your corrected machine code*
>>>>>>>>>>>>>>> *This must include the machine address and the assembly
>>>>>>>>>>>>>>> language*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> NOPE!!!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> YOU have failed, but are apparently so brain dead the news
>>>>>>>>>>>>>> can't get to you.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *When I challenge you to show what the correct detailed*
>>>>>>>>>>>>>>> *line-by-line machine address by machine address steps*
>>>>>>>>>>>>>>> *SHOULD BE you consistently utterly fail because you really*
>>>>>>>>>>>>>>> *don't know Jack about these things and are just bluffing*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And why do YOU have the power to dictate how I argue?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tell me what was wrong with what I said?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I gave you a complete 16 line execution trace with every
>>>>>>>>>>>>> single
>>>>>>>>>>>>> detail 100% fully specified. You must show exactly which
>>>>>>>>>>>>> details
>>>>>>>>>>>>> of this trace are wrong by correcting these exact details.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, HH is undefined.
>>>>>>>>>>>>
>>>>>>>>>>>> In fact, and HH that correctly simulates the input and
>>>>>>>>>>>> answer just doesn't exist.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *I need to see column (1) and column (5) exact and complete
>>>>>>>>>>>>> details*
>>>>>>>>>>>>> cut-and-paste would also preserve column(4)
>>>>>>>>>>>>
>>>>>>>>>>>> WHy? Are you that stupid?
>>>>>>>>>>>>
>>>>>>>>>>>> I described exactly what needs to happen.
>>>>>>>>>>>>
>>>>>>>>>>>> If HH can't generate that (which it can't) then it is just
>>>>>>>>>>>> the error in HH
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The trace that you provide must correspond to the provided
>>>>>>>>>>>>> assembly language/machine-code of DD at the bottom.
>>>>>>>>>>>>
>>>>>>>>>>>> You must believe in the existance of Russel's Teapot then,
>>>>>>>>>>>> and the Barber that shave everyone who doesn't shave
>>>>>>>>>>>> themselves.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> YOU SAY THAT DD IS NOT CORRECTLY SIMULATED BY HH
>>>>>>>>>>>>> I SAY PROVE IT
>>>>>>>>>>>>
>>>>>>>>>>>> I did.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The only acceptable proof must be a cut-and-paste of the
>>>>>>>>>>> execution trace shown below with corrections to this
>>>>>>>>>>> execution trace showing what the correct simulation of
>>>>>>>>>>> DD by HH should be.
>>>>>>>>>>
>>>>>>>>>> Nope.
>>>>>>>>>
>>>>>>>>> You said "Nope" only because you already know that I am
>>>>>>>>> correct and want to continue to persist with bullshit
>>>>>>>>> and double-talk.
>>>>>>>>
>>>>>>>> Nope, why don't you answer my questions?
>>>>>>>>
>>>>>>>
>>>>>>> *I will not tolerate your persistent misdirection*
>>>>>>>
>>>>>>> If you can't copy the execution trace shown below
>>>>>>> and change it so that it is correct then you are
>>>>>>> admitting that it is correct.
>>>>>>
>>>>>> If you are willing for an EDIT, and not an actual run
>>>>>>
>>>>>> The CORRECT SIMULATION of the input to HH(DD,DD)
>>>>>>
>>>>>> Note, there can not be a correct simulation by HH
>>>>>
>>>>> More double-talk excuse for not showing exactly how this is wrong.
>>>>
>>>> Yes, what was wrong with my correct simulation trace.
>>>>
>>>> It seem you are just admitting to using double-talk
>>>>
>>>>
>>>>> BECAUSE IT IS NOT WRONG
>>>>> BECAUSE IT IS NOT WRONG
>>>>> BECAUSE IT IS NOT WRONG
>>>>> BECAUSE IT IS NOT WRONG
>>>>
>>>> Then why does it not agree with the direct execution, as REQURED by
>>>> the definiton of CORRECT SIMULATION?
>>>>
>>>
>>> int Infinite_Recursion(u32 N)
>>> {
>>>    Infinite_Recursion(N);
>>>    return 1;
>>> }
>>>
>>> It is the same as if infinite recursion was aborted on its second
>>> recursive call. This would provide the illusion that infinite
>>> recursion halts because the first call reaches its final state
>>> when the second call has been aborted.
>>>
>>
>> NOPE.
>>
>> HH STILL Can't do a correct simulation of that input, as a correct
>> simulation of that input takes an unbounded number of steps, so
>
> We know that D correctly simulated by H never reaches its final state
> in 1 to ∞ steps of correct simulation.
>
> And it we did not need to simulate an infinite number of steps to know
> this.
>
>

On 1/21/2024 2:35 PM, Richard Damon wrote:
> On 1/21/24 3:24 PM, olcott wrote:
>> On 1/20/2024 7:50 PM, Richard Damon wrote:
>>> On 1/20/24 8:30 PM, olcott wrote:
>>>> On 1/20/2024 7:24 PM, Richard Damon wrote:
>>>>> On 1/20/24 8:15 PM, olcott wrote:
>>>>>> On 1/20/2024 6:53 PM, Richard Damon wrote:
>>>>>>> On 1/20/24 3:47 PM, olcott wrote:
>>>>>>>> On 1/20/2024 2:28 PM, Richard Damon wrote:
>>>>>>>>> On 1/20/24 1:21 PM, olcott wrote:
>>>>>>>>>> On 1/20/2024 11:52 AM, Richard Damon wrote:
>>>>>>>>>>> On 1/20/24 12:47 PM, olcott wrote:
>>>>>>>>>>>> On 1/20/2024 11:39 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/20/24 10:12 AM, olcott wrote:
>>>>>>>>>>>>>> On 1/20/2024 6:22 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/19/24 11:29 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/19/2024 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/19/24 10:28 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/19/2024 9:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/19/24 9:55 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/19/2024 8:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/19/24 9:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 2024-01-19 18:26, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The full state of D was repeated.
>>>>>>>>>>>>>>>>>>>>>>>> The only thing that changed was the stack address.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The contents of the stack and the stack address
>>>>>>>>>>>>>>>>>>>>>>> are *part* of the state of the machine. If they
>>>>>>>>>>>>>>>>>>>>>>> change, you are not repeating the same state.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Everything is identical across recursive
>>>>>>>>>>>>>>>>>>>>>> simulations besides
>>>>>>>>>>>>>>>>>>>>>> the stack address. The stack address is irrelevant
>>>>>>>>>>>>>>>>>>>>>> to whether
>>>>>>>>>>>>>>>>>>>>>> or not DD halts.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nope, and part of the problem is you stopped
>>>>>>>>>>>>>>>>>>>>> looking at the actual simulaiton of the input.  The
>>>>>>>>>>>>>>>>>>>>> simulator being simulated at the first call will be
>>>>>>>>>>>>>>>>>>>>> in a different state at the second call to H then
>>>>>>>>>>>>>>>>>>>>> it was when it started, just like the outer HH
>>>>>>>>>>>>>>>>>>>>> doing the simulation has built up the history shown.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That means that, if we continued an actual correct
>>>>>>>>>>>>>>>>>>>>> simulation of this exact input (and thus didn't
>>>>>>>>>>>>>>>>>>>>> change HH, but gave the input to a proper UTM
>>>>>>>>>>>>>>>>>>>>> simulator) we would see that the first simulated HH
>>>>>>>>>>>>>>>>>>>>> would run one more level of simulation, and then
>>>>>>>>>>>>>>>>>>>>> abort its simulation, and then return to DD and it
>>>>>>>>>>>>>>>>>>>>> would halt.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thus, your simulation just isn't showing the actual
>>>>>>>>>>>>>>>>>>>>> "state" of the program (in fact, you arn't even
>>>>>>>>>>>>>>>>>>>>> showing the state of the program, since the key
>>>>>>>>>>>>>>>>>>>>> state for this program is what is happening in the
>>>>>>>>>>>>>>>>>>>>> HH that DD is calling)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The "recursive" layer SHOULD be showing up as the
>>>>>>>>>>>>>>>>>>>>> instruction sequence of the simulator simulating
>>>>>>>>>>>>>>>>>>>>> those instructions, and thus showing that state
>>>>>>>>>>>>>>>>>>>>> being generated.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That second layer never actually shows as a direct
>>>>>>>>>>>>>>>>>>>>> simulation in the proper simulation of the input,
>>>>>>>>>>>>>>>>>>>>> except maybe as interspresed comment of the
>>>>>>>>>>>>>>>>>>>>> simulated HH just simulated this instruction.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If you are going to try to abstract out that
>>>>>>>>>>>>>>>>>>>>> simulation, you need to do it properly, and that
>>>>>>>>>>>>>>>>>>>>> means that the simulation level IS part of state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The easily verified fact that DD simulated by HH
>>>>>>>>>>>>>>>>>>>>>> cannot possibly
>>>>>>>>>>>>>>>>>>>>>> reach its own simulated final state conclusively
>>>>>>>>>>>>>>>>>>>>>> proves that DD
>>>>>>>>>>>>>>>>>>>>>> does not halt.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, that only hold *IF* HH correctly simulates the
>>>>>>>>>>>>>>>>>>>>> input, which means that HH can NEVER abort its
>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation Execution
>>>>>>>>>>>>>>>>>>>>>> Trace Stored at:113027
>>>>>>>>>>>>>>>>>>>>>> [00001c42][00113013][00113017] 55          push ebp
>>>>>>>>>>>>>>>>>>>>>> [00001c43][00113013][00113017] 8bec        mov
>>>>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>>>>> [00001c45][0011300f][00102fe3] 51          push ecx
>>>>>>>>>>>>>>>>>>>>>> [00001c46][0011300f][00102fe3] 8b4508      mov
>>>>>>>>>>>>>>>>>>>>>> eax,[ebp+08] ; DD
>>>>>>>>>>>>>>>>>>>>>> [00001c49][0011300b][00001c42] 50          push
>>>>>>>>>>>>>>>>>>>>>> eax ; DD
>>>>>>>>>>>>>>>>>>>>>> [00001c4a][0011300b][00001c42] 8b4d08      mov
>>>>>>>>>>>>>>>>>>>>>> ecx,[ebp+08] ; DD
>>>>>>>>>>>>>>>>>>>>>> [00001c4d][00113007][00001c42] 51          push
>>>>>>>>>>>>>>>>>>>>>> ecx ; DD
>>>>>>>>>>>>>>>>>>>>>> [00001c4e][00113003][00001c53] e80ff7ffff  call
>>>>>>>>>>>>>>>>>>>>>> 00001362 ; HH
>>>>>>>>>>>>>>>>>>>>>> New slave_stack at:14da47
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note. error in simulation here. Call to HH should
>>>>>>>>>>>>>>>>>>>>> be showing the states of operation of HH
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Tell me how the behavior of HH can possibly show that
>>>>>>>>>>>>>>>>>>>> DD reaches its final state and I will provide a link
>>>>>>>>>>>>>>>>>>>> with the 151 pages of the execution trace of HH.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It can't in its simulation, but an actually correct
>>>>>>>>>>>>>>>>>>> simulation of the input, which HH doesn't do, can.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *When I challenge you to show what the correct detailed*
>>>>>>>>>>>>>>>>>> *line-by-line machine address by machine address steps*
>>>>>>>>>>>>>>>>>> *SHOULD BE you consistently utterly fail because you
>>>>>>>>>>>>>>>>>> really*
>>>>>>>>>>>>>>>>>> *don't know Jack about these things and are just
>>>>>>>>>>>>>>>>>> bluffing*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> i.e. I'm not falling for your strawman and are panicing
>>>>>>>>>>>>>>>>> as badly as your buddy Trump.
>>>>>>>>>>>>>>>> Trump is a Hitler wanna bee.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yep, and you are no better.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You use the same lying techniques as he does, even though
>>>>>>>>>>>>>>> you CLAIM to be fighting those techniques (that makes you
>>>>>>>>>>>>>>> the Hypocrite)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *You failed try again*
>>>>>>>>>>>>>>>> I show 16 lines of machine code
>>>>>>>>>>>>>>>> *you must show ever detail of your corrected machine code*
>>>>>>>>>>>>>>>> *This must include the machine address and the assembly
>>>>>>>>>>>>>>>> language*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> NOPE!!!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> YOU have failed, but are apparently so brain dead the
>>>>>>>>>>>>>>> news can't get to you.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *When I challenge you to show what the correct detailed*
>>>>>>>>>>>>>>>> *line-by-line machine address by machine address steps*
>>>>>>>>>>>>>>>> *SHOULD BE you consistently utterly fail because you
>>>>>>>>>>>>>>>> really*
>>>>>>>>>>>>>>>> *don't know Jack about these things and are just bluffing*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And why do YOU have the power to dictate how I argue?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tell me what was wrong with what I said?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I gave you a complete 16 line execution trace with every
>>>>>>>>>>>>>> single
>>>>>>>>>>>>>> detail 100% fully specified. You must show exactly which
>>>>>>>>>>>>>> details
>>>>>>>>>>>>>> of this trace are wrong by correcting these exact details.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, HH is undefined.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In fact, and HH that correctly simulates the input and
>>>>>>>>>>>>> answer just doesn't exist.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *I need to see column (1) and column (5) exact and
>>>>>>>>>>>>>> complete details*
>>>>>>>>>>>>>> cut-and-paste would also preserve column(4)
>>>>>>>>>>>>>
>>>>>>>>>>>>> WHy? Are you that stupid?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I described exactly what needs to happen.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If HH can't generate that (which it can't) then it is just
>>>>>>>>>>>>> the error in HH
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The trace that you provide must correspond to the provided
>>>>>>>>>>>>>> assembly language/machine-code of DD at the bottom.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You must believe in the existance of Russel's Teapot then,
>>>>>>>>>>>>> and the Barber that shave everyone who doesn't shave
>>>>>>>>>>>>> themselves.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> YOU SAY THAT DD IS NOT CORRECTLY SIMULATED BY HH
>>>>>>>>>>>>>> I SAY PROVE IT
>>>>>>>>>>>>>
>>>>>>>>>>>>> I did.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The only acceptable proof must be a cut-and-paste of the
>>>>>>>>>>>> execution trace shown below with corrections to this
>>>>>>>>>>>> execution trace showing what the correct simulation of
>>>>>>>>>>>> DD by HH should be.
>>>>>>>>>>>
>>>>>>>>>>> Nope.
>>>>>>>>>>
>>>>>>>>>> You said "Nope" only because you already know that I am
>>>>>>>>>> correct and want to continue to persist with bullshit
>>>>>>>>>> and double-talk.
>>>>>>>>>
>>>>>>>>> Nope, why don't you answer my questions?
>>>>>>>>>
>>>>>>>>
>>>>>>>> *I will not tolerate your persistent misdirection*
>>>>>>>>
>>>>>>>> If you can't copy the execution trace shown below
>>>>>>>> and change it so that it is correct then you are
>>>>>>>> admitting that it is correct.
>>>>>>>
>>>>>>> If you are willing for an EDIT, and not an actual run
>>>>>>>
>>>>>>> The CORRECT SIMULATION of the input to HH(DD,DD)
>>>>>>>
>>>>>>> Note, there can not be a correct simulation by HH
>>>>>>
>>>>>> More double-talk excuse for not showing exactly how this is wrong.
>>>>>
>>>>> Yes, what was wrong with my correct simulation trace.
>>>>>
>>>>> It seem you are just admitting to using double-talk
>>>>>
>>>>>
>>>>>> BECAUSE IT IS NOT WRONG
>>>>>> BECAUSE IT IS NOT WRONG
>>>>>> BECAUSE IT IS NOT WRONG
>>>>>> BECAUSE IT IS NOT WRONG
>>>>>
>>>>> Then why does it not agree with the direct execution, as REQURED by
>>>>> the definiton of CORRECT SIMULATION?
>>>>>
>>>>
>>>> int Infinite_Recursion(u32 N)
>>>> {
>>>>    Infinite_Recursion(N);
>>>>    return 1;
>>>> }
>>>>
>>>> It is the same as if infinite recursion was aborted on its second
>>>> recursive call. This would provide the illusion that infinite
>>>> recursion halts because the first call reaches its final state
>>>> when the second call has been aborted.
>>>>
>>>
>>> NOPE.
>>>
>>> HH STILL Can't do a correct simulation of that input, as a correct
>>> simulation of that input takes an unbounded number of steps, so
>>
>> We know that D correctly simulated by H never reaches its final state
>> in 1 to ∞ steps of correct simulation.
>>
>> And it we did not need to simulate an infinite number of steps to know
>> this.
>>
>>
>
> But if H DOES correctly simulate D, then it DOESN'T ABORT.

On 1/21/24 3:39 PM, olcott wrote:
> On 1/21/2024 2:35 PM, Richard Damon wrote:
>> On 1/21/24 3:24 PM, olcott wrote:
>>> On 1/20/2024 7:50 PM, Richard Damon wrote:
>>>> On 1/20/24 8:30 PM, olcott wrote:
>>>>> On 1/20/2024 7:24 PM, Richard Damon wrote:
>>>>>> On 1/20/24 8:15 PM, olcott wrote:
>>>>>>> On 1/20/2024 6:53 PM, Richard Damon wrote:
>>>>>>>> On 1/20/24 3:47 PM, olcott wrote:
>>>>>>>>> On 1/20/2024 2:28 PM, Richard Damon wrote:
>>>>>>>>>> On 1/20/24 1:21 PM, olcott wrote:
>>>>>>>>>>> On 1/20/2024 11:52 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/20/24 12:47 PM, olcott wrote:
>>>>>>>>>>>>> On 1/20/2024 11:39 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/20/24 10:12 AM, olcott wrote:
>>>>>>>>>>>>>>> On 1/20/2024 6:22 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/19/24 11:29 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/19/2024 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/19/24 10:28 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/19/2024 9:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/19/24 9:55 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/19/2024 8:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/19/24 9:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2024-01-19 18:26, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The full state of D was repeated.
>>>>>>>>>>>>>>>>>>>>>>>>> The only thing that changed was the stack address.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The contents of the stack and the stack address
>>>>>>>>>>>>>>>>>>>>>>>> are *part* of the state of the machine. If they
>>>>>>>>>>>>>>>>>>>>>>>> change, you are not repeating the same state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Everything is identical across recursive
>>>>>>>>>>>>>>>>>>>>>>> simulations besides
>>>>>>>>>>>>>>>>>>>>>>> the stack address. The stack address is
>>>>>>>>>>>>>>>>>>>>>>> irrelevant to whether
>>>>>>>>>>>>>>>>>>>>>>> or not DD halts.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, and part of the problem is you stopped
>>>>>>>>>>>>>>>>>>>>>> looking at the actual simulaiton of the input.
>>>>>>>>>>>>>>>>>>>>>> The simulator being simulated at the first call
>>>>>>>>>>>>>>>>>>>>>> will be in a different state at the second call to
>>>>>>>>>>>>>>>>>>>>>> H then it was when it started, just like the outer
>>>>>>>>>>>>>>>>>>>>>> HH doing the simulation has built up the history
>>>>>>>>>>>>>>>>>>>>>> shown.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That means that, if we continued an actual correct
>>>>>>>>>>>>>>>>>>>>>> simulation of this exact input (and thus didn't
>>>>>>>>>>>>>>>>>>>>>> change HH, but gave the input to a proper UTM
>>>>>>>>>>>>>>>>>>>>>> simulator) we would see that the first simulated
>>>>>>>>>>>>>>>>>>>>>> HH would run one more level of simulation, and
>>>>>>>>>>>>>>>>>>>>>> then abort its simulation, and then return to DD
>>>>>>>>>>>>>>>>>>>>>> and it would halt.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thus, your simulation just isn't showing the
>>>>>>>>>>>>>>>>>>>>>> actual "state" of the program (in fact, you arn't
>>>>>>>>>>>>>>>>>>>>>> even showing the state of the program, since the
>>>>>>>>>>>>>>>>>>>>>> key state for this program is what is happening in
>>>>>>>>>>>>>>>>>>>>>> the HH that DD is calling)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The "recursive" layer SHOULD be showing up as the
>>>>>>>>>>>>>>>>>>>>>> instruction sequence of the simulator simulating
>>>>>>>>>>>>>>>>>>>>>> those instructions, and thus showing that state
>>>>>>>>>>>>>>>>>>>>>> being generated.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That second layer never actually shows as a direct
>>>>>>>>>>>>>>>>>>>>>> simulation in the proper simulation of the input,
>>>>>>>>>>>>>>>>>>>>>> except maybe as interspresed comment of the
>>>>>>>>>>>>>>>>>>>>>> simulated HH just simulated this instruction.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If you are going to try to abstract out that
>>>>>>>>>>>>>>>>>>>>>> simulation, you need to do it properly, and that
>>>>>>>>>>>>>>>>>>>>>> means that the simulation level IS part of state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The easily verified fact that DD simulated by HH
>>>>>>>>>>>>>>>>>>>>>>> cannot possibly
>>>>>>>>>>>>>>>>>>>>>>> reach its own simulated final state conclusively
>>>>>>>>>>>>>>>>>>>>>>> proves that DD
>>>>>>>>>>>>>>>>>>>>>>> does not halt.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No, that only hold *IF* HH correctly simulates the
>>>>>>>>>>>>>>>>>>>>>> input, which means that HH can NEVER abort its
>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation Execution
>>>>>>>>>>>>>>>>>>>>>>> Trace Stored at:113027
>>>>>>>>>>>>>>>>>>>>>>> [00001c42][00113013][00113017] 55          push ebp
>>>>>>>>>>>>>>>>>>>>>>> [00001c43][00113013][00113017] 8bec        mov
>>>>>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>>>>>> [00001c45][0011300f][00102fe3] 51          push ecx
>>>>>>>>>>>>>>>>>>>>>>> [00001c46][0011300f][00102fe3] 8b4508      mov
>>>>>>>>>>>>>>>>>>>>>>> eax,[ebp+08] ; DD
>>>>>>>>>>>>>>>>>>>>>>> [00001c49][0011300b][00001c42] 50          push
>>>>>>>>>>>>>>>>>>>>>>> eax ; DD
>>>>>>>>>>>>>>>>>>>>>>> [00001c4a][0011300b][00001c42] 8b4d08      mov
>>>>>>>>>>>>>>>>>>>>>>> ecx,[ebp+08] ; DD
>>>>>>>>>>>>>>>>>>>>>>> [00001c4d][00113007][00001c42] 51          push
>>>>>>>>>>>>>>>>>>>>>>> ecx ; DD
>>>>>>>>>>>>>>>>>>>>>>> [00001c4e][00113003][00001c53] e80ff7ffff  call
>>>>>>>>>>>>>>>>>>>>>>> 00001362 ; HH
>>>>>>>>>>>>>>>>>>>>>>> New slave_stack at:14da47
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Note. error in simulation here. Call to HH should
>>>>>>>>>>>>>>>>>>>>>> be showing the states of operation of HH
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Tell me how the behavior of HH can possibly show that
>>>>>>>>>>>>>>>>>>>>> DD reaches its final state and I will provide a link
>>>>>>>>>>>>>>>>>>>>> with the 151 pages of the execution trace of HH.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It can't in its simulation, but an actually correct
>>>>>>>>>>>>>>>>>>>> simulation of the input, which HH doesn't do, can.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *When I challenge you to show what the correct detailed*
>>>>>>>>>>>>>>>>>>> *line-by-line machine address by machine address steps*
>>>>>>>>>>>>>>>>>>> *SHOULD BE you consistently utterly fail because you
>>>>>>>>>>>>>>>>>>> really*
>>>>>>>>>>>>>>>>>>> *don't know Jack about these things and are just
>>>>>>>>>>>>>>>>>>> bluffing*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> i.e. I'm not falling for your strawman and are
>>>>>>>>>>>>>>>>>> panicing as badly as your buddy Trump.
>>>>>>>>>>>>>>>>> Trump is a Hitler wanna bee.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yep, and you are no better.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You use the same lying techniques as he does, even
>>>>>>>>>>>>>>>> though you CLAIM to be fighting those techniques (that
>>>>>>>>>>>>>>>> makes you the Hypocrite)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *You failed try again*
>>>>>>>>>>>>>>>>> I show 16 lines of machine code
>>>>>>>>>>>>>>>>> *you must show ever detail of your corrected machine code*
>>>>>>>>>>>>>>>>> *This must include the machine address and the assembly
>>>>>>>>>>>>>>>>> language*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Why?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> NOPE!!!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> YOU have failed, but are apparently so brain dead the
>>>>>>>>>>>>>>>> news can't get to you.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *When I challenge you to show what the correct detailed*
>>>>>>>>>>>>>>>>> *line-by-line machine address by machine address steps*
>>>>>>>>>>>>>>>>> *SHOULD BE you consistently utterly fail because you
>>>>>>>>>>>>>>>>> really*
>>>>>>>>>>>>>>>>> *don't know Jack about these things and are just bluffing*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And why do YOU have the power to dictate how I argue?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tell me what was wrong with what I said?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I gave you a complete 16 line execution trace with every
>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>> detail 100% fully specified. You must show exactly which
>>>>>>>>>>>>>>> details
>>>>>>>>>>>>>>> of this trace are wrong by correcting these exact details.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, HH is undefined.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In fact, and HH that correctly simulates the input and
>>>>>>>>>>>>>> answer just doesn't exist.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *I need to see column (1) and column (5) exact and
>>>>>>>>>>>>>>> complete details*
>>>>>>>>>>>>>>> cut-and-paste would also preserve column(4)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WHy? Are you that stupid?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I described exactly what needs to happen.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If HH can't generate that (which it can't) then it is just
>>>>>>>>>>>>>> the error in HH
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The trace that you provide must correspond to the provided
>>>>>>>>>>>>>>> assembly language/machine-code of DD at the bottom.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You must believe in the existance of Russel's Teapot then,
>>>>>>>>>>>>>> and the Barber that shave everyone who doesn't shave
>>>>>>>>>>>>>> themselves.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> YOU SAY THAT DD IS NOT CORRECTLY SIMULATED BY HH
>>>>>>>>>>>>>>> I SAY PROVE IT
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I did.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only acceptable proof must be a cut-and-paste of the
>>>>>>>>>>>>> execution trace shown below with corrections to this
>>>>>>>>>>>>> execution trace showing what the correct simulation of
>>>>>>>>>>>>> DD by HH should be.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope.
>>>>>>>>>>>
>>>>>>>>>>> You said "Nope" only because you already know that I am
>>>>>>>>>>> correct and want to continue to persist with bullshit
>>>>>>>>>>> and double-talk.
>>>>>>>>>>
>>>>>>>>>> Nope, why don't you answer my questions?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *I will not tolerate your persistent misdirection*
>>>>>>>>>
>>>>>>>>> If you can't copy the execution trace shown below
>>>>>>>>> and change it so that it is correct then you are
>>>>>>>>> admitting that it is correct.
>>>>>>>>
>>>>>>>> If you are willing for an EDIT, and not an actual run
>>>>>>>>
>>>>>>>> The CORRECT SIMULATION of the input to HH(DD,DD)
>>>>>>>>
>>>>>>>> Note, there can not be a correct simulation by HH
>>>>>>>
>>>>>>> More double-talk excuse for not showing exactly how this is wrong.
>>>>>>
>>>>>> Yes, what was wrong with my correct simulation trace.
>>>>>>
>>>>>> It seem you are just admitting to using double-talk
>>>>>>
>>>>>>
>>>>>>> BECAUSE IT IS NOT WRONG
>>>>>>> BECAUSE IT IS NOT WRONG
>>>>>>> BECAUSE IT IS NOT WRONG
>>>>>>> BECAUSE IT IS NOT WRONG
>>>>>>
>>>>>> Then why does it not agree with the direct execution, as REQURED
>>>>>> by the definiton of CORRECT SIMULATION?
>>>>>>
>>>>>
>>>>> int Infinite_Recursion(u32 N)
>>>>> {
>>>>>    Infinite_Recursion(N);
>>>>>    return 1;
>>>>> }
>>>>>
>>>>> It is the same as if infinite recursion was aborted on its second
>>>>> recursive call. This would provide the illusion that infinite
>>>>> recursion halts because the first call reaches its final state
>>>>> when the second call has been aborted.
>>>>>
>>>>
>>>> NOPE.
>>>>
>>>> HH STILL Can't do a correct simulation of that input, as a correct
>>>> simulation of that input takes an unbounded number of steps, so
>>>
>>> We know that D correctly simulated by H never reaches its final state
>>> in 1 to ∞ steps of correct simulation.
>>>
>>> And it we did not need to simulate an infinite number of steps to know
>>> this.
>>>
>>>
>>
>> But if H DOES correctly simulate D, then it DOESN'T ABORT.
>
> Yes of course the correct simulation of ten steps can't
> possibly be the correct simulation of ten steps.
>
> By this same reasoning no thing is itself.
>

On 1/21/24 21:39, olcott wrote:
> On 1/21/2024 2:35 PM, Richard Damon wrote:
>> On 1/21/24 3:24 PM, olcott wrote:
>>> On 1/20/2024 7:50 PM, Richard Damon wrote:
>>>> On 1/20/24 8:30 PM, olcott wrote:
>>>>> On 1/20/2024 7:24 PM, Richard Damon wrote:
>>>>>> On 1/20/24 8:15 PM, olcott wrote:
>>>>>>> On 1/20/2024 6:53 PM, Richard Damon wrote:
>>>>>>>> On 1/20/24 3:47 PM, olcott wrote:
>>>>>>>>> On 1/20/2024 2:28 PM, Richard Damon wrote:
>>>>>>>>>> On 1/20/24 1:21 PM, olcott wrote:
>>>>>>>>>>> On 1/20/2024 11:52 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/20/24 12:47 PM, olcott wrote:
>>>>>>>>>>>>> On 1/20/2024 11:39 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/20/24 10:12 AM, olcott wrote:
>>>>>>>>>>>>>>> On 1/20/2024 6:22 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/19/24 11:29 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/19/2024 10:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/19/24 10:28 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/19/2024 9:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/19/24 9:55 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/19/2024 8:39 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/19/24 9:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2024-01-19 18:26, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The full state of D was repeated.
>>>>>>>>>>>>>>>>>>>>>>>>> The only thing that changed was the stack address.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The contents of the stack and the stack address
>>>>>>>>>>>>>>>>>>>>>>>> are *part* of the state of the machine. If they
>>>>>>>>>>>>>>>>>>>>>>>> change, you are not repeating the same state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Everything is identical across recursive
>>>>>>>>>>>>>>>>>>>>>>> simulations besides
>>>>>>>>>>>>>>>>>>>>>>> the stack address. The stack address is
>>>>>>>>>>>>>>>>>>>>>>> irrelevant to whether
>>>>>>>>>>>>>>>>>>>>>>> or not DD halts.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, and part of the problem is you stopped
>>>>>>>>>>>>>>>>>>>>>> looking at the actual simulaiton of the input.
>>>>>>>>>>>>>>>>>>>>>> The simulator being simulated at the first call
>>>>>>>>>>>>>>>>>>>>>> will be in a different state at the second call to
>>>>>>>>>>>>>>>>>>>>>> H then it was when it started, just like the outer
>>>>>>>>>>>>>>>>>>>>>> HH doing the simulation has built up the history
>>>>>>>>>>>>>>>>>>>>>> shown.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That means that, if we continued an actual correct
>>>>>>>>>>>>>>>>>>>>>> simulation of this exact input (and thus didn't
>>>>>>>>>>>>>>>>>>>>>> change HH, but gave the input to a proper UTM
>>>>>>>>>>>>>>>>>>>>>> simulator) we would see that the first simulated
>>>>>>>>>>>>>>>>>>>>>> HH would run one more level of simulation, and
>>>>>>>>>>>>>>>>>>>>>> then abort its simulation, and then return to DD
>>>>>>>>>>>>>>>>>>>>>> and it would halt.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thus, your simulation just isn't showing the
>>>>>>>>>>>>>>>>>>>>>> actual "state" of the program (in fact, you arn't
>>>>>>>>>>>>>>>>>>>>>> even showing the state of the program, since the
>>>>>>>>>>>>>>>>>>>>>> key state for this program is what is happening in
>>>>>>>>>>>>>>>>>>>>>> the HH that DD is calling)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The "recursive" layer SHOULD be showing up as the
>>>>>>>>>>>>>>>>>>>>>> instruction sequence of the simulator simulating
>>>>>>>>>>>>>>>>>>>>>> those instructions, and thus showing that state
>>>>>>>>>>>>>>>>>>>>>> being generated.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That second layer never actually shows as a direct
>>>>>>>>>>>>>>>>>>>>>> simulation in the proper simulation of the input,
>>>>>>>>>>>>>>>>>>>>>> except maybe as interspresed comment of the
>>>>>>>>>>>>>>>>>>>>>> simulated HH just simulated this instruction.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If you are going to try to abstract out that
>>>>>>>>>>>>>>>>>>>>>> simulation, you need to do it properly, and that
>>>>>>>>>>>>>>>>>>>>>> means that the simulation level IS part of state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The easily verified fact that DD simulated by HH
>>>>>>>>>>>>>>>>>>>>>>> cannot possibly
>>>>>>>>>>>>>>>>>>>>>>> reach its own simulated final state conclusively
>>>>>>>>>>>>>>>>>>>>>>> proves that DD
>>>>>>>>>>>>>>>>>>>>>>> does not halt.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No, that only hold *IF* HH correctly simulates the
>>>>>>>>>>>>>>>>>>>>>> input, which means that HH can NEVER abort its
>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation Execution
>>>>>>>>>>>>>>>>>>>>>>> Trace Stored at:113027
>>>>>>>>>>>>>>>>>>>>>>> [00001c42][00113013][00113017] 55          push ebp
>>>>>>>>>>>>>>>>>>>>>>> [00001c43][00113013][00113017] 8bec        mov
>>>>>>>>>>>>>>>>>>>>>>> ebp,esp
>>>>>>>>>>>>>>>>>>>>>>> [00001c45][0011300f][00102fe3] 51          push ecx
>>>>>>>>>>>>>>>>>>>>>>> [00001c46][0011300f][00102fe3] 8b4508      mov
>>>>>>>>>>>>>>>>>>>>>>> eax,[ebp+08] ; DD
>>>>>>>>>>>>>>>>>>>>>>> [00001c49][0011300b][00001c42] 50          push
>>>>>>>>>>>>>>>>>>>>>>> eax ; DD
>>>>>>>>>>>>>>>>>>>>>>> [00001c4a][0011300b][00001c42] 8b4d08      mov
>>>>>>>>>>>>>>>>>>>>>>> ecx,[ebp+08] ; DD
>>>>>>>>>>>>>>>>>>>>>>> [00001c4d][00113007][00001c42] 51          push
>>>>>>>>>>>>>>>>>>>>>>> ecx ; DD
>>>>>>>>>>>>>>>>>>>>>>> [00001c4e][00113003][00001c53] e80ff7ffff  call
>>>>>>>>>>>>>>>>>>>>>>> 00001362 ; HH
>>>>>>>>>>>>>>>>>>>>>>> New slave_stack at:14da47
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Note. error in simulation here. Call to HH should
>>>>>>>>>>>>>>>>>>>>>> be showing the states of operation of HH
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Tell me how the behavior of HH can possibly show that
>>>>>>>>>>>>>>>>>>>>> DD reaches its final state and I will provide a link
>>>>>>>>>>>>>>>>>>>>> with the 151 pages of the execution trace of HH.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It can't in its simulation, but an actually correct
>>>>>>>>>>>>>>>>>>>> simulation of the input, which HH doesn't do, can.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *When I challenge you to show what the correct detailed*
>>>>>>>>>>>>>>>>>>> *line-by-line machine address by machine address steps*
>>>>>>>>>>>>>>>>>>> *SHOULD BE you consistently utterly fail because you
>>>>>>>>>>>>>>>>>>> really*
>>>>>>>>>>>>>>>>>>> *don't know Jack about these things and are just
>>>>>>>>>>>>>>>>>>> bluffing*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> i.e. I'm not falling for your strawman and are
>>>>>>>>>>>>>>>>>> panicing as badly as your buddy Trump.
>>>>>>>>>>>>>>>>> Trump is a Hitler wanna bee.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yep, and you are no better.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You use the same lying techniques as he does, even
>>>>>>>>>>>>>>>> though you CLAIM to be fighting those techniques (that
>>>>>>>>>>>>>>>> makes you the Hypocrite)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *You failed try again*
>>>>>>>>>>>>>>>>> I show 16 lines of machine code
>>>>>>>>>>>>>>>>> *you must show ever detail of your corrected machine code*
>>>>>>>>>>>>>>>>> *This must include the machine address and the assembly
>>>>>>>>>>>>>>>>> language*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Why?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>>> *OR YOU FAIL*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> NOPE!!!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> YOU have failed, but are apparently so brain dead the
>>>>>>>>>>>>>>>> news can't get to you.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *When I challenge you to show what the correct detailed*
>>>>>>>>>>>>>>>>> *line-by-line machine address by machine address steps*
>>>>>>>>>>>>>>>>> *SHOULD BE you consistently utterly fail because you
>>>>>>>>>>>>>>>>> really*
>>>>>>>>>>>>>>>>> *don't know Jack about these things and are just bluffing*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And why do YOU have the power to dictate how I argue?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tell me what was wrong with what I said?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I gave you a complete 16 line execution trace with every
>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>> detail 100% fully specified. You must show exactly which
>>>>>>>>>>>>>>> details
>>>>>>>>>>>>>>> of this trace are wrong by correcting these exact details.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, HH is undefined.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In fact, and HH that correctly simulates the input and
>>>>>>>>>>>>>> answer just doesn't exist.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *I need to see column (1) and column (5) exact and
>>>>>>>>>>>>>>> complete details*
>>>>>>>>>>>>>>> cut-and-paste would also preserve column(4)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WHy? Are you that stupid?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I described exactly what needs to happen.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If HH can't generate that (which it can't) then it is just
>>>>>>>>>>>>>> the error in HH
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The trace that you provide must correspond to the provided
>>>>>>>>>>>>>>> assembly language/machine-code of DD at the bottom.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You must believe in the existance of Russel's Teapot then,
>>>>>>>>>>>>>> and the Barber that shave everyone who doesn't shave
>>>>>>>>>>>>>> themselves.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> YOU SAY THAT DD IS NOT CORRECTLY SIMULATED BY HH
>>>>>>>>>>>>>>> I SAY PROVE IT
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I did.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only acceptable proof must be a cut-and-paste of the
>>>>>>>>>>>>> execution trace shown below with corrections to this
>>>>>>>>>>>>> execution trace showing what the correct simulation of
>>>>>>>>>>>>> DD by HH should be.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope.
>>>>>>>>>>>
>>>>>>>>>>> You said "Nope" only because you already know that I am
>>>>>>>>>>> correct and want to continue to persist with bullshit
>>>>>>>>>>> and double-talk.
>>>>>>>>>>
>>>>>>>>>> Nope, why don't you answer my questions?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *I will not tolerate your persistent misdirection*
>>>>>>>>>
>>>>>>>>> If you can't copy the execution trace shown below
>>>>>>>>> and change it so that it is correct then you are
>>>>>>>>> admitting that it is correct.
>>>>>>>>
>>>>>>>> If you are willing for an EDIT, and not an actual run
>>>>>>>>
>>>>>>>> The CORRECT SIMULATION of the input to HH(DD,DD)
>>>>>>>>
>>>>>>>> Note, there can not be a correct simulation by HH
>>>>>>>
>>>>>>> More double-talk excuse for not showing exactly how this is wrong.
>>>>>>
>>>>>> Yes, what was wrong with my correct simulation trace.
>>>>>>
>>>>>> It seem you are just admitting to using double-talk
>>>>>>
>>>>>>
>>>>>>> BECAUSE IT IS NOT WRONG
>>>>>>> BECAUSE IT IS NOT WRONG
>>>>>>> BECAUSE IT IS NOT WRONG
>>>>>>> BECAUSE IT IS NOT WRONG
>>>>>>
>>>>>> Then why does it not agree with the direct execution, as REQURED
>>>>>> by the definiton of CORRECT SIMULATION?
>>>>>>
>>>>>
>>>>> int Infinite_Recursion(u32 N)
>>>>> {
>>>>>    Infinite_Recursion(N);
>>>>>    return 1;
>>>>> }
>>>>>
>>>>> It is the same as if infinite recursion was aborted on its second
>>>>> recursive call. This would provide the illusion that infinite
>>>>> recursion halts because the first call reaches its final state
>>>>> when the second call has been aborted.
>>>>>
>>>>
>>>> NOPE.
>>>>
>>>> HH STILL Can't do a correct simulation of that input, as a correct
>>>> simulation of that input takes an unbounded number of steps, so
>>>
>>> We know that D correctly simulated by H never reaches its final state
>>> in 1 to ∞ steps of correct simulation.
>>>
>>> And it we did not need to simulate an infinite number of steps to know
>>> this.
>>>
>>>
>>
>> But if H DOES correctly simulate D, then it DOESN'T ABORT.
>
> Yes of course the correct simulation of ten steps can't
> possibly be the correct simulation of ten steps.
>
> By this same reasoning no thing is itself.
>