On 1/20/24 9:51 PM, olcott wrote:
> On 1/20/2024 8:40 PM, Richard Damon wrote:
>> On 1/20/24 9:00 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 HH
>>>> can not return an answer.
>>>>
>>>
>>> When N steps of Infinite_Recursion are correctly simulated by H
>>> then H matches its {infinite recursion behavior} pattern correctly
>>> recognizing that a full simulation "takes an unbounded number of steps".
>>>
>>> When N steps of D are correctly simulated by H then H matches its
>>> {recursive simulation} behavior pattern correctly recognizing that
>>> a full simulation "takes an unbounded number of steps".
>>>
>>>
>>
>> But the pattern can not have been correct
>
> *Too late you already admitted that*
> "a correct simulation of that input takes an unbounded number of steps"

On 1/20/2024 9:20 PM, Richard Damon wrote:
> On 1/20/24 9:51 PM, olcott wrote:
>> On 1/20/2024 8:40 PM, Richard Damon wrote:
>>> On 1/20/24 9:00 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 HH
>>>>> can not return an answer.
>>>>>
>>>>
>>>> When N steps of Infinite_Recursion are correctly simulated by H
>>>> then H matches its {infinite recursion behavior} pattern correctly
>>>> recognizing that a full simulation "takes an unbounded number of
>>>> steps".
>>>>
>>>> When N steps of D are correctly simulated by H then H matches its
>>>> {recursive simulation} behavior pattern correctly recognizing that
>>>> a full simulation "takes an unbounded number of steps".
>>>>
>>>>
>>>
>>> But the pattern can not have been correct
>>
>> *Too late you already admitted that*
>> "a correct simulation of that input takes an unbounded number of steps"
>
> Right, when D is built on an H that does an actual correct simulation,

On 1/21/24 02:00, olcott wrote:
> On 1/20/2024 6:54 PM, immibis wrote:
>> On 1/21/24 01:20, olcott wrote:
>>> On 1/20/2024 6:11 PM, immibis wrote:
>>>> On 1/21/24 00:26, olcott wrote:
>>>>> On 1/20/2024 4:34 PM, immibis wrote:
>>>>>> On 1/20/24 23:21, olcott wrote:
>>>>>>> On 1/20/2024 4:10 PM, Alan Mackenzie wrote:
>>>>>>>>
>>>>>>>> It's not a matter of opinion, it's a matter of analysing these
>>>>>>>> words,
>>>>>>>> which I have done, and you have not.  "If I correctly state that
>>>>>>>> pigs can
>>>>>>>> fly, then bacon will correctly go up." is a sentence of the same
>>>>>>>> form as
>>>>>>>> your (a).  They are both vacuous nonsense.
>>>>>>>>
>>>>>>>
>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>>  > verbatim paragraph is correct
>>>>>>>  >
>>>>>>>  > If simulating halt decider H correctly simulates its input D
>>>>>>>  > until H correctly determines that its simulated D would never
>>>>>>>  > stop running unless aborted then H can abort its simulation
>>>>>>>  > of D and correctly report that D specifies a non-halting
>>>>>>>  > sequence of configurations.
>>>>>>>
>>>>>>> After careful review by many people it was agreed that the
>>>>>>> above words are true and correct and thus not vacuous nonsense.
>>>>>>> No one even hinted that Professor Sipser agreed to vacuous nonsense.
>>>>>>> When this possibility was proposed it was rejected.
>>>>>>>
>>>>>>
>>>>>> You don't understand what Alan just said.
>>>>>
>>>>> You and Alan don't seem to know the difference between
>>>>> vacuous truths:
>>>>>
>>>>> (a) All the living T-rexes in my living room have orange and blue
>>>>> stripes
>>>>>
>>>>> and Non vacuous truths:
>>>>>
>>>>> (b) 2 + 3 = 5.
>>>>>
>>>>
>>>> You don't seem to know the difference between vacuous truths:
>>>>
>>>> (a) All the simulating halt deciders that correctly determine that
>>>> their simulated input would never stop running unless aborted can
>>>> abort their simulations and correctly report that they specify a
>>>> non-halting sequence of configurations.
>>>>
>>>> and Non vacuous truths:
>>>>
>>>> (b) There is a keyboard on my desk.
>>>
>>> Simulating termination analyzer is a more accurate term
>>> because it is only required to get at least one input
>>> correctly.
>>
>> It does get at least one input correctly. But not D. It gets D wrong.
>
> That proves that simulating halt decider is not a vacuous term.

It's still vacuous. Getting one answer right doesn't make it a
simulating halt decider.

It's very easy to make a termination analyzer that gets at least one
input correctly:

int H(string P, string I) {return 1;}

On 1/21/24 02:30, olcott wrote:
>
> 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.
>

No, because you have dishonestly deleted the infinite recursion checker.

On 1/21/24 03:00, 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 HH can
>> not return an answer.
>>
>
> When N steps of Infinite_Recursion are correctly simulated by H
> then H matches its {infinite recursion behavior} pattern correctly
> recognizing that a full simulation "takes an unbounded number of steps".
>
> When N steps of D are correctly simulated by H then H matches its
> {recursive simulation} behavior pattern correctly recognizing that
> a full simulation "takes an unbounded number of steps".
>
>
>

On 1/20/24 10:36 PM, olcott wrote:
> On 1/20/2024 9:20 PM, Richard Damon wrote:
>> On 1/20/24 9:51 PM, olcott wrote:
>>> On 1/20/2024 8:40 PM, Richard Damon wrote:
>>>> On 1/20/24 9:00 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 HH
>>>>>> can not return an answer.
>>>>>>
>>>>>
>>>>> When N steps of Infinite_Recursion are correctly simulated by H
>>>>> then H matches its {infinite recursion behavior} pattern correctly
>>>>> recognizing that a full simulation "takes an unbounded number of
>>>>> steps".
>>>>>
>>>>> When N steps of D are correctly simulated by H then H matches its
>>>>> {recursive simulation} behavior pattern correctly recognizing that
>>>>> a full simulation "takes an unbounded number of steps".
>>>>>
>>>>>
>>>>
>>>> But the pattern can not have been correct
>>>
>>> *Too late you already admitted that*
>>> "a correct simulation of that input takes an unbounded number of steps"
>>
>> Right, when D is built on an H that does an actual correct simulation,
>
> int Infinite_Recursion(u32 N)
> {
>   Infinite_Recursion(N);
>   return;
> }
>
> D correctly simulated by H never reaches its final state
> in 1 to ∞ steps of correct simulation. H correctly recognizes
> this after N steps of correct simulation.

On 1/21/2024 6:44 AM, Richard Damon wrote:
> On 1/20/24 10:36 PM, olcott wrote:
>> On 1/20/2024 9:20 PM, Richard Damon wrote:
>>> On 1/20/24 9:51 PM, olcott wrote:
>>>> On 1/20/2024 8:40 PM, Richard Damon wrote:
>>>>> On 1/20/24 9:00 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 HH can not return an answer.
>>>>>>>
>>>>>>
>>>>>> When N steps of Infinite_Recursion are correctly simulated by H
>>>>>> then H matches its {infinite recursion behavior} pattern correctly
>>>>>> recognizing that a full simulation "takes an unbounded number of
>>>>>> steps".
>>>>>>
>>>>>> When N steps of D are correctly simulated by H then H matches its
>>>>>> {recursive simulation} behavior pattern correctly recognizing that
>>>>>> a full simulation "takes an unbounded number of steps".
>>>>>>
>>>>>>
>>>>>
>>>>> But the pattern can not have been correct
>>>>
>>>> *Too late you already admitted that*
>>>> "a correct simulation of that input takes an unbounded number of steps"
>>>
>>> Right, when D is built on an H that does an actual correct simulation,
>>
>> int Infinite_Recursion(u32 N)
>> {
>>    Infinite_Recursion(N);
>>    return;
>> }
>>
>> D correctly simulated by H never reaches its final state
>> in 1 to ∞ steps of correct simulation. H correctly recognizes
>> this after N steps of correct simulation.
>
> No, the only D
>

On 1/21/2024 5:17 AM, immibis wrote:
> On 1/21/24 03:00, 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 HH
>>> can not return an answer.
>>>
>>
>> When N steps of Infinite_Recursion are correctly simulated by H
>> then H matches its {infinite recursion behavior} pattern correctly
>> recognizing that a full simulation "takes an unbounded number of steps".
>>
>> When N steps of D are correctly simulated by H then H matches its
>> {recursive simulation} behavior pattern correctly recognizing that
>> a full simulation "takes an unbounded number of steps".
>>
>>
>>
>
> Correctly simulated DD can't halt or abort.

On 1/21/2024 5:16 AM, immibis wrote:
> On 1/21/24 02:30, olcott wrote:
>>
>> 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.
>>
>
> No, because you have dishonestly deleted the infinite recursion checker.

When you said stupid things like this I am just ignoring what you say.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 1/21/2024 5:16 AM, immibis wrote:
> On 1/21/24 02:00, olcott wrote:
>> On 1/20/2024 6:54 PM, immibis wrote:
>>> On 1/21/24 01:20, olcott wrote:
>>>> On 1/20/2024 6:11 PM, immibis wrote:
>>>>> On 1/21/24 00:26, olcott wrote:
>>>>>> On 1/20/2024 4:34 PM, immibis wrote:
>>>>>>> On 1/20/24 23:21, olcott wrote:
>>>>>>>> On 1/20/2024 4:10 PM, Alan Mackenzie wrote:
>>>>>>>>>
>>>>>>>>> It's not a matter of opinion, it's a matter of analysing these
>>>>>>>>> words,
>>>>>>>>> which I have done, and you have not.  "If I correctly state
>>>>>>>>> that pigs can
>>>>>>>>> fly, then bacon will correctly go up." is a sentence of the
>>>>>>>>> same form as
>>>>>>>>> your (a).  They are both vacuous nonsense.
>>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>>>  > verbatim paragraph is correct
>>>>>>>>  >
>>>>>>>>  > If simulating halt decider H correctly simulates its input D
>>>>>>>>  > until H correctly determines that its simulated D would never
>>>>>>>>  > stop running unless aborted then H can abort its simulation
>>>>>>>>  > of D and correctly report that D specifies a non-halting
>>>>>>>>  > sequence of configurations.
>>>>>>>>
>>>>>>>> After careful review by many people it was agreed that the
>>>>>>>> above words are true and correct and thus not vacuous nonsense.
>>>>>>>> No one even hinted that Professor Sipser agreed to vacuous
>>>>>>>> nonsense.
>>>>>>>> When this possibility was proposed it was rejected.
>>>>>>>>
>>>>>>>
>>>>>>> You don't understand what Alan just said.
>>>>>>
>>>>>> You and Alan don't seem to know the difference between
>>>>>> vacuous truths:
>>>>>>
>>>>>> (a) All the living T-rexes in my living room have orange and blue
>>>>>> stripes
>>>>>>
>>>>>> and Non vacuous truths:
>>>>>>
>>>>>> (b) 2 + 3 = 5.
>>>>>>
>>>>>
>>>>> You don't seem to know the difference between vacuous truths:
>>>>>
>>>>> (a) All the simulating halt deciders that correctly determine that
>>>>> their simulated input would never stop running unless aborted can
>>>>> abort their simulations and correctly report that they specify a
>>>>> non-halting sequence of configurations.
>>>>>
>>>>> and Non vacuous truths:
>>>>>
>>>>> (b) There is a keyboard on my desk.
>>>>
>>>> Simulating termination analyzer is a more accurate term
>>>> because it is only required to get at least one input
>>>> correctly.
>>>
>>> It does get at least one input correctly. But not D. It gets D wrong.
>>
>> That proves that simulating halt decider is not a vacuous term.
>
> It's still vacuous. Getting one answer right doesn't make it a
> simulating halt decider.
>

I call it a simulating termination analyzer.
They only have to get one answer right.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

On 1/21/24 16:41, olcott wrote:
> On 1/21/2024 5:16 AM, immibis wrote:
>> On 1/21/24 02:00, olcott wrote:
>>> On 1/20/2024 6:54 PM, immibis wrote:
>>>> On 1/21/24 01:20, olcott wrote:
>>>>> On 1/20/2024 6:11 PM, immibis wrote:
>>>>>> On 1/21/24 00:26, olcott wrote:
>>>>>>> On 1/20/2024 4:34 PM, immibis wrote:
>>>>>>>> On 1/20/24 23:21, olcott wrote:
>>>>>>>>> On 1/20/2024 4:10 PM, Alan Mackenzie wrote:
>>>>>>>>>>
>>>>>>>>>> It's not a matter of opinion, it's a matter of analysing these
>>>>>>>>>> words,
>>>>>>>>>> which I have done, and you have not.  "If I correctly state
>>>>>>>>>> that pigs can
>>>>>>>>>> fly, then bacon will correctly go up." is a sentence of the
>>>>>>>>>> same form as
>>>>>>>>>> your (a).  They are both vacuous nonsense.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>>>>  > verbatim paragraph is correct
>>>>>>>>>  >
>>>>>>>>>  > If simulating halt decider H correctly simulates its input D
>>>>>>>>>  > until H correctly determines that its simulated D would never
>>>>>>>>>  > stop running unless aborted then H can abort its simulation
>>>>>>>>>  > of D and correctly report that D specifies a non-halting
>>>>>>>>>  > sequence of configurations.
>>>>>>>>>
>>>>>>>>> After careful review by many people it was agreed that the
>>>>>>>>> above words are true and correct and thus not vacuous nonsense.
>>>>>>>>> No one even hinted that Professor Sipser agreed to vacuous
>>>>>>>>> nonsense.
>>>>>>>>> When this possibility was proposed it was rejected.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You don't understand what Alan just said.
>>>>>>>
>>>>>>> You and Alan don't seem to know the difference between
>>>>>>> vacuous truths:
>>>>>>>
>>>>>>> (a) All the living T-rexes in my living room have orange and blue
>>>>>>> stripes
>>>>>>>
>>>>>>> and Non vacuous truths:
>>>>>>>
>>>>>>> (b) 2 + 3 = 5.
>>>>>>>
>>>>>>
>>>>>> You don't seem to know the difference between vacuous truths:
>>>>>>
>>>>>> (a) All the simulating halt deciders that correctly determine that
>>>>>> their simulated input would never stop running unless aborted can
>>>>>> abort their simulations and correctly report that they specify a
>>>>>> non-halting sequence of configurations.
>>>>>>
>>>>>> and Non vacuous truths:
>>>>>>
>>>>>> (b) There is a keyboard on my desk.
>>>>>
>>>>> Simulating termination analyzer is a more accurate term
>>>>> because it is only required to get at least one input
>>>>> correctly.
>>>>
>>>> It does get at least one input correctly. But not D. It gets D wrong.
>>>
>>> That proves that simulating halt decider is not a vacuous term.
>>
>> It's still vacuous. Getting one answer right doesn't make it a
>> simulating halt decider.
>>
>
> I call it a simulating termination analyzer.
> They only have to get one answer right.
>

Even programs that aren't supposed to decide halting get one answer
right. Even prime number deciders get some halting answers right.

On 1/21/2024 11:57 AM, immibis wrote:
> On 1/21/24 16:41, olcott wrote:
>> On 1/21/2024 5:16 AM, immibis wrote:
>>> On 1/21/24 02:00, olcott wrote:
>>>> On 1/20/2024 6:54 PM, immibis wrote:
>>>>> On 1/21/24 01:20, olcott wrote:
>>>>>> On 1/20/2024 6:11 PM, immibis wrote:
>>>>>>> On 1/21/24 00:26, olcott wrote:
>>>>>>>> On 1/20/2024 4:34 PM, immibis wrote:
>>>>>>>>> On 1/20/24 23:21, olcott wrote:
>>>>>>>>>> On 1/20/2024 4:10 PM, Alan Mackenzie wrote:
>>>>>>>>>>>
>>>>>>>>>>> It's not a matter of opinion, it's a matter of analysing
>>>>>>>>>>> these words,
>>>>>>>>>>> which I have done, and you have not.  "If I correctly state
>>>>>>>>>>> that pigs can
>>>>>>>>>>> fly, then bacon will correctly go up." is a sentence of the
>>>>>>>>>>> same form as
>>>>>>>>>>> your (a).  They are both vacuous nonsense.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>>>>>  > verbatim paragraph is correct
>>>>>>>>>>  >
>>>>>>>>>>  > If simulating halt decider H correctly simulates its input D
>>>>>>>>>>  > until H correctly determines that its simulated D would never
>>>>>>>>>>  > stop running unless aborted then H can abort its simulation
>>>>>>>>>>  > of D and correctly report that D specifies a non-halting
>>>>>>>>>>  > sequence of configurations.
>>>>>>>>>>
>>>>>>>>>> After careful review by many people it was agreed that the
>>>>>>>>>> above words are true and correct and thus not vacuous nonsense.
>>>>>>>>>> No one even hinted that Professor Sipser agreed to vacuous
>>>>>>>>>> nonsense.
>>>>>>>>>> When this possibility was proposed it was rejected.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You don't understand what Alan just said.
>>>>>>>>
>>>>>>>> You and Alan don't seem to know the difference between
>>>>>>>> vacuous truths:
>>>>>>>>
>>>>>>>> (a) All the living T-rexes in my living room have orange and
>>>>>>>> blue stripes
>>>>>>>>
>>>>>>>> and Non vacuous truths:
>>>>>>>>
>>>>>>>> (b) 2 + 3 = 5.
>>>>>>>>
>>>>>>>
>>>>>>> You don't seem to know the difference between vacuous truths:
>>>>>>>
>>>>>>> (a) All the simulating halt deciders that correctly determine
>>>>>>> that their simulated input would never stop running unless
>>>>>>> aborted can abort their simulations and correctly report that
>>>>>>> they specify a non-halting sequence of configurations.
>>>>>>>
>>>>>>> and Non vacuous truths:
>>>>>>>
>>>>>>> (b) There is a keyboard on my desk.
>>>>>>
>>>>>> Simulating termination analyzer is a more accurate term
>>>>>> because it is only required to get at least one input
>>>>>> correctly.
>>>>>
>>>>> It does get at least one input correctly. But not D. It gets D wrong.
>>>>
>>>> That proves that simulating halt decider is not a vacuous term.
>>>
>>> It's still vacuous. Getting one answer right doesn't make it a
>>> simulating halt decider.
>>>
>>
>> I call it a simulating termination analyzer.
>> They only have to get one answer right.
>>
>
> Even programs that aren't supposed to decide halting get one answer
> right. Even prime number deciders get some halting answers right.

When a simulating termination analyzer gets one answer correctly
by determining that its input cannot possibly reach its own final
state in 1 to ∞ steps of correct simulation this conclusively proves
that the term {simulating termination analyzer} is not vacuous.

People stuck in rebuttal mode seem to have no problem with directly
contradicting verified facts.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 1/21/24 11:39 AM, 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
>
> D correctly simulated by H never reaches its final state
> in 1 to ∞ steps of correct simulation.
>

On 1/21/24 10:31 AM, olcott wrote:
> On 1/21/2024 6:44 AM, Richard Damon wrote:
>> On 1/20/24 10:36 PM, olcott wrote:
>>> On 1/20/2024 9:20 PM, Richard Damon wrote:
>>>> On 1/20/24 9:51 PM, olcott wrote:
>>>>> On 1/20/2024 8:40 PM, Richard Damon wrote:
>>>>>> On 1/20/24 9:00 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 HH can not return an answer.
>>>>>>>>
>>>>>>>
>>>>>>> When N steps of Infinite_Recursion are correctly simulated by H
>>>>>>> then H matches its {infinite recursion behavior} pattern correctly
>>>>>>> recognizing that a full simulation "takes an unbounded number of
>>>>>>> steps".
>>>>>>>
>>>>>>> When N steps of D are correctly simulated by H then H matches its
>>>>>>> {recursive simulation} behavior pattern correctly recognizing that
>>>>>>> a full simulation "takes an unbounded number of steps".
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> But the pattern can not have been correct
>>>>>
>>>>> *Too late you already admitted that*
>>>>> "a correct simulation of that input takes an unbounded number of
>>>>> steps"
>>>>
>>>> Right, when D is built on an H that does an actual correct simulation,
>>>
>>> int Infinite_Recursion(u32 N)
>>> {
>>>    Infinite_Recursion(N);
>>>    return;
>>> }
>>>
>>> D correctly simulated by H never reaches its final state
>>> in 1 to ∞ steps of correct simulation. H correctly recognizes
>>> this after N steps of correct simulation.
>>
>> No, the only D
>>
>
> This is a gibberish answer.
> You might as well have said D dee doo dee doo.
>

On 1/21/24 10:38 AM, olcott wrote:
> On 1/21/2024 5:17 AM, immibis wrote:
>> On 1/21/24 03:00, 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 HH
>>>> can not return an answer.
>>>>
>>>
>>> When N steps of Infinite_Recursion are correctly simulated by H
>>> then H matches its {infinite recursion behavior} pattern correctly
>>> recognizing that a full simulation "takes an unbounded number of steps".
>>>
>>> When N steps of D are correctly simulated by H then H matches its
>>> {recursive simulation} behavior pattern correctly recognizing that
>>> a full simulation "takes an unbounded number of steps".
>>>
>>>
>>>
>>
>> Correctly simulated DD can't halt or abort.
>
> int Infinite_Recursion(u32 N)
> {
>   Infinite_Recursion(N);
>   return;
> }
>
> D correctly simulated by H never reaches its final state
> in 1 to ∞ steps of correct simulation. H correctly recognizes
> this after N steps of correct simulation.

On 1/21/24 10:39 AM, olcott wrote:
> On 1/21/2024 5:16 AM, immibis wrote:
>> On 1/21/24 02:30, olcott wrote:
>>>
>>> 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.
>>>
>>
>> No, because you have dishonestly deleted the infinite recursion checker.
>
> When you said stupid things like this I am just ignoring what you say.
>

So, we should just ignore everything you say? Since Stupid is a good
description of everything you say, showing that is a apt description of you?

On 1/21/24 10:41 AM, olcott wrote:
> On 1/21/2024 5:16 AM, immibis wrote:
>> On 1/21/24 02:00, olcott wrote:
>>> On 1/20/2024 6:54 PM, immibis wrote:
>>>> On 1/21/24 01:20, olcott wrote:
>>>>> On 1/20/2024 6:11 PM, immibis wrote:
>>>>>> On 1/21/24 00:26, olcott wrote:
>>>>>>> On 1/20/2024 4:34 PM, immibis wrote:
>>>>>>>> On 1/20/24 23:21, olcott wrote:
>>>>>>>>> On 1/20/2024 4:10 PM, Alan Mackenzie wrote:
>>>>>>>>>>
>>>>>>>>>> It's not a matter of opinion, it's a matter of analysing these
>>>>>>>>>> words,
>>>>>>>>>> which I have done, and you have not.  "If I correctly state
>>>>>>>>>> that pigs can
>>>>>>>>>> fly, then bacon will correctly go up." is a sentence of the
>>>>>>>>>> same form as
>>>>>>>>>> your (a).  They are both vacuous nonsense.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>>>>  > verbatim paragraph is correct
>>>>>>>>>  >
>>>>>>>>>  > If simulating halt decider H correctly simulates its input D
>>>>>>>>>  > until H correctly determines that its simulated D would never
>>>>>>>>>  > stop running unless aborted then H can abort its simulation
>>>>>>>>>  > of D and correctly report that D specifies a non-halting
>>>>>>>>>  > sequence of configurations.
>>>>>>>>>
>>>>>>>>> After careful review by many people it was agreed that the
>>>>>>>>> above words are true and correct and thus not vacuous nonsense.
>>>>>>>>> No one even hinted that Professor Sipser agreed to vacuous
>>>>>>>>> nonsense.
>>>>>>>>> When this possibility was proposed it was rejected.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You don't understand what Alan just said.
>>>>>>>
>>>>>>> You and Alan don't seem to know the difference between
>>>>>>> vacuous truths:
>>>>>>>
>>>>>>> (a) All the living T-rexes in my living room have orange and blue
>>>>>>> stripes
>>>>>>>
>>>>>>> and Non vacuous truths:
>>>>>>>
>>>>>>> (b) 2 + 3 = 5.
>>>>>>>
>>>>>>
>>>>>> You don't seem to know the difference between vacuous truths:
>>>>>>
>>>>>> (a) All the simulating halt deciders that correctly determine that
>>>>>> their simulated input would never stop running unless aborted can
>>>>>> abort their simulations and correctly report that they specify a
>>>>>> non-halting sequence of configurations.
>>>>>>
>>>>>> and Non vacuous truths:
>>>>>>
>>>>>> (b) There is a keyboard on my desk.
>>>>>
>>>>> Simulating termination analyzer is a more accurate term
>>>>> because it is only required to get at least one input
>>>>> correctly.
>>>>
>>>> It does get at least one input correctly. But not D. It gets D wrong.
>>>
>>> That proves that simulating halt decider is not a vacuous term.
>>
>> It's still vacuous. Getting one answer right doesn't make it a
>> simulating halt decider.
>>
>
> I call it a simulating termination analyzer.
> They only have to get one answer right.
>

And if it isn't the actual problem at hand, it means nothing.

To be a counter example for the Halting Proof, it needs to be the same
EXACT program as that used, which your D isn't, by your own admission
(since you admit that you D isn't even an actual program).

On 1/21/24 1:12 PM, olcott wrote:
> On 1/21/2024 11:57 AM, immibis wrote:
>> On 1/21/24 16:41, olcott wrote:
>>> On 1/21/2024 5:16 AM, immibis wrote:
>>>> On 1/21/24 02:00, olcott wrote:
>>>>> On 1/20/2024 6:54 PM, immibis wrote:
>>>>>> On 1/21/24 01:20, olcott wrote:
>>>>>>> On 1/20/2024 6:11 PM, immibis wrote:
>>>>>>>> On 1/21/24 00:26, olcott wrote:
>>>>>>>>> On 1/20/2024 4:34 PM, immibis wrote:
>>>>>>>>>> On 1/20/24 23:21, olcott wrote:
>>>>>>>>>>> On 1/20/2024 4:10 PM, Alan Mackenzie wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> It's not a matter of opinion, it's a matter of analysing
>>>>>>>>>>>> these words,
>>>>>>>>>>>> which I have done, and you have not.  "If I correctly state
>>>>>>>>>>>> that pigs can
>>>>>>>>>>>> fly, then bacon will correctly go up." is a sentence of the
>>>>>>>>>>>> same form as
>>>>>>>>>>>> your (a).  They are both vacuous nonsense.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>>>>  > MIT Professor Michael Sipser has agreed that the following
>>>>>>>>>>>  > verbatim paragraph is correct
>>>>>>>>>>>  >
>>>>>>>>>>>  > If simulating halt decider H correctly simulates its input D
>>>>>>>>>>>  > until H correctly determines that its simulated D would never
>>>>>>>>>>>  > stop running unless aborted then H can abort its simulation
>>>>>>>>>>>  > of D and correctly report that D specifies a non-halting
>>>>>>>>>>>  > sequence of configurations.
>>>>>>>>>>>
>>>>>>>>>>> After careful review by many people it was agreed that the
>>>>>>>>>>> above words are true and correct and thus not vacuous nonsense.
>>>>>>>>>>> No one even hinted that Professor Sipser agreed to vacuous
>>>>>>>>>>> nonsense.
>>>>>>>>>>> When this possibility was proposed it was rejected.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You don't understand what Alan just said.
>>>>>>>>>
>>>>>>>>> You and Alan don't seem to know the difference between
>>>>>>>>> vacuous truths:
>>>>>>>>>
>>>>>>>>> (a) All the living T-rexes in my living room have orange and
>>>>>>>>> blue stripes
>>>>>>>>>
>>>>>>>>> and Non vacuous truths:
>>>>>>>>>
>>>>>>>>> (b) 2 + 3 = 5.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You don't seem to know the difference between vacuous truths:
>>>>>>>>
>>>>>>>> (a) All the simulating halt deciders that correctly determine
>>>>>>>> that their simulated input would never stop running unless
>>>>>>>> aborted can abort their simulations and correctly report that
>>>>>>>> they specify a non-halting sequence of configurations.
>>>>>>>>
>>>>>>>> and Non vacuous truths:
>>>>>>>>
>>>>>>>> (b) There is a keyboard on my desk.
>>>>>>>
>>>>>>> Simulating termination analyzer is a more accurate term
>>>>>>> because it is only required to get at least one input
>>>>>>> correctly.
>>>>>>
>>>>>> It does get at least one input correctly. But not D. It gets D wrong.
>>>>>
>>>>> That proves that simulating halt decider is not a vacuous term.
>>>>
>>>> It's still vacuous. Getting one answer right doesn't make it a
>>>> simulating halt decider.
>>>>
>>>
>>> I call it a simulating termination analyzer.
>>> They only have to get one answer right.
>>>
>>
>> Even programs that aren't supposed to decide halting get one answer
>> right. Even prime number deciders get some halting answers right.
>
> When a simulating termination analyzer gets one answer correctly
> by determining that its input cannot possibly reach its own final
> state in 1 to ∞ steps of correct simulation this conclusively proves
> that the term {simulating termination analyzer} is not vacuous.
>
> People stuck in rebuttal mode seem to have no problem with directly
> contradicting verified facts.
>