On 1/20/24 15:59, olcott wrote:
> On 1/20/2024 4:41 AM, Alan Mackenzie wrote:
>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>> When you ignore what I say THIS DOES NOT COUNT AS ME NOT SAYING IT.
>>> Professor Sipser agreed that the following definition of a simulating
>>> halt decider is correct
>>
>> It's like the good professor agreeing that if pigs had wings, they
>> would fly.
>
> Not at all. He would not risk his credibility that way.
> He gave me permission to quote him.

There is no risk to your credibility by saying that if pigs had wings,
they would fly. It is most likely true that if pigs had wings, they
would fly. However, pigs do not have wings, and simulating halt decider
H does not correctly simulate its input until H correctly determines
that its simulated D would never stop running unless aborted.

>>
>> Yes.  But you haven't yet noticed that little word "if" at the beginning
>> of his sentence.  There is no such thing as a halt decider, simulating or
>> otherwise, so you could just as well write "If simulating halt decider H
>> correctly simulates its input D, then pigs would fly.", and it would be
>> just as true.  But just as meaningless and not at all sensible.
>>
>
> Technically in my case it is a partial halt decider or a termination
> analyzer. Professor Sipser knew that he was only agreeing that a
> specific H/D pair would be decidable as non-halting when the criteria
> has been met.

It gives the wrong answer on the program it's designed to give a right
answer for.

>
> Here is my updated paraphrase of (a)
> (a) If simulating termination analyzer H correctly determines that D
> correctly simulated by H cannot possibly reach its own simulated final
> state and terminate normally then

That's the same thing. It doesn't matter whether you call it a halt
decider or a termination analyzer. Those are two different names for the
same thing and H does not correctly determine that D correctly simulated
by H cannot possibly reach its own simulated final state and terminate
normally.

>
>>> --
>>> Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
>>> hits a target no one else can see." Arthur Schopenhauer
>>
>
It's 2024 now. You should update that.

On 1/20/24 17:34, olcott wrote:

> *That is the strawman deception and you know it*
> You claimed that he agreed with nonsense

Nonsense which is true. If pigs could fly, they would have wings. This
is true. And useless.

> and this
> is provably false. He agreed that my verbatim
> words are correct. He did not agree with nonsense.
>
>

On 1/20/24 16:25, olcott wrote:
> On 1/20/2024 4:01 AM, immibis wrote:
>> On 1/19/24 23:46, olcott wrote:
>>> On 1/19/2024 4:40 PM, immibis wrote:
>>>> On 1/19/24 23:22, olcott wrote:
>>>>> On 1/19/2024 3:41 PM, immibis wrote:
>>>>>> On 1/19/24 22:12, olcott wrote:
>>>>>>> On 1/19/2024 2:44 PM, immibis wrote:
>>>>>>>> On 1/19/24 19:56, olcott wrote:
>>>>>>>>> On 1/19/2024 12:16 PM, immibis wrote:
>>>>>>>>>> On 1/19/24 17:14, olcott wrote:
>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>> Deciders always must compute the mapping from an input
>>>>>>>>>>>>> finite string to
>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Definition of the HP based on the above definition of a
>>>>>>>>>>>>> decider*
>>>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>>>> determining, whether an input finite string pair of
>>>>>>>>>>>>> program/input
>>>>>>>>>>>>> specifies a computation that would reach a final state and
>>>>>>>>>>>>> terminate
>>>>>>>>>>>>> normally.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Definition of halt decider based on the above definitions*
>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>>> simulated final
>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope.
>>>>>>>>>>>>
>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>
>>>>>>>>>>>> a input finite string pair of program/input specifies a
>>>>>>>>>>>> computation that would reach a final state and terminate
>>>>>>>>>>>> normally
>>>>>>>>>>>>
>>>>>>>>>>>> to
>>>>>>>>>>>>
>>>>>>>>>>>> H correctly determines that D correctly simulated *by H*
>>>>>>>>>>>> cannot possiby reach its own simulated final state.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>> is calling itself.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> H is not allowed to simply ignore that D would detect infinite
>>>>>>>>>> recursion, stop simulating and reach a final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *This is simply over your head*
>>>>>>>>> Unless the outermost HH aborts its simulation then none of them
>>>>>>>>> do.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why?
>>>>>>>>
>>>>>>>
>>>>>>> Each simulated HH has the exact same instructions as the
>>>>>>> others because it <is> the same code at the same machine
>>>>>>> address.
>>>>>>
>>>>>> Does the direct executed HH have the exact same instructions as
>>>>>> each simulated HH?
>>>>>>
>>>>>
>>>>> There is only one HH at machine address [00001032].
>>>>>
>>>>
>>>> Does the direct executed HH have the exact same instructions as each
>>>> simulated HH?
>>>
>>> There is only one HH at machine address [00001032].
>>> There is only one HH at machine address [00001032].
>>> There is only one HH at machine address [00001032].
>>> There is only one HH at machine address [00001032].
>>> There is only one HH at machine address [00001032].
>>>
>>> You must have ADD like Richard. I have to repeat
>>> things to Richard hundreds of times before he ever
>>> notices that I said them once.
>>>
>>
>> Why can't you answer the question?
>
> I answered the question with all of the technical details
> that prove the answer. If there is only one thing in the
> universe then is this thing different than itself?
>
> There is only one HH in Halt7.c and it is never copied.
>
IF they are the same thing (whatever that means) then I am sure you
agree they have the exact same instructions? Why can't you acknowledge
it? Why have you wasted several messages refusing to agree with it?

In comp.theory olcott <polcott2@gmail.com> wrote:
> On 1/20/2024 10:26 AM, Alan Mackenzie wrote:
>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>> On 1/20/2024 9:43 AM, Alan Mackenzie wrote:
>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>> On 1/20/2024 4:41 AM, Alan Mackenzie wrote:
>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>> On 1/19/2024 6:01 PM, Alan Mackenzie wrote:
>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>>>> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>>>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:

>>>>>> [ .... ]

>>>>>>>>>>> In other words no one can possibly tell that the above
>>>>>>>>>>> function will not halt until they waited an infinite amount
>>>>>>>>>>> of time and saw that it did not halt. DUMB, DUMB, DUMB,
>>>>>>>>>>> DUMB.

>>>>>>>>>> That is why attempting to solve the halting problem with a
>>>>>>>>>> simulator is not a sensible thing to do.

>>>>>>>>> The best selling author of textbooks on the theory of
>>>>>>>>> computation disagrees.

>>>>>>>> He does not. This author knows full well that a halting
>>>>>>>> decider cannot be built, as do millions of students and
>>>>>>>> graduates world wide, who have seen a proof (or even written
>>>>>>>> one) and appreciate its clarity, simplicity, and finality.

>>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X

>>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>>> MIT Professor Michael Sipser has agreed that the following
>>>>>>>>>> verbatim paragraph is correct (he has not agreed to anything
>>>>>>>>>> else in this paper):

>>>>>>>>>> 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.

>>>>>>>>>> When one accepts this definition of a simulating halt decider
>>>>>>>>>> then my code shows that H correctly determines the halt
>>>>>>>>>> status of D.

>>>>>>>> I haven't seen you define a halting decider of any type over
>>>>>>>> the last few years.

>>>>>>> When you ignore what I say THIS DOES NOT COUNT AS ME NOT SAYING
>>>>>>> IT. Professor Sipser agreed that the following definition of a
>>>>>>> simulating halt decider is correct

>>>>>> It's like the good professor agreeing that if pigs had wings,
>>>>>> they would fly.

>>>>> Not at all. He would not risk his credibility that way.
>>>>> He gave me permission to quote him.

>>>> He would not be risking his credibility.

>> You've got no reply to this, I see.

You've still got no reply.

>>> (a) If simulating termination analyzer H correctly determines that D
>>> correctly simulated by H cannot possibly reach its own simulated final
>>> state and terminate normally then

>>> (b) H can abort its simulation of D and correctly report that D
>>> specifies a non-halting sequence of configurations.

>>> That you do not understand that the above is correct proves
>>> that you are insufficiently competent to review my work.

>> I understand it fully, thank you very much. You fail to understand it.
>> If I write "if I correctly state that pigs can fly, then bacon will
>> correctly go up", then that is the truth, just as much as your (a). It's
>> inane nonsense, of course, just as your (a) is nonsense.

>>> There has been a very extensive reviews of this in comp.theory back in
>>> 10/13/2022. You can go see what many other people have said. It was
>>> resolved that Professor Sipser really meant to agree with these words.

>> I read, or at least perused, it at the time. The resolution certainly
>> was not that Professor Sipser likely agreed with what you would
>> like him to agree with.

> *That is the strawman deception and you know it*

That's an unwarranted insult. It was what I surmised from those
exchanges at the time. You likely have a different impression of them,
just as you have different impressions of lots of things you post here.

> You claimed that he agreed with nonsense and this is provably false.
> He agreed that my verbatim words are correct. He did not agree with
> nonsense.

He both agreed that your verbatim words were correct and agreed with
nonsense. Those words, although pedantically true, _are_ inane nonsense,
just as my proposition about correctly stating that pigs can fly was both
true and nonsense.

And how about you assenting publically to the halting theorem? Or are
you just going to leave that hovering in limbo?

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

--
Alan Mackenzie (Nuremberg, Germany).

On 1/20/2024 11:23 AM, Alan Mackenzie wrote:
> In comp.theory olcott <polcott2@gmail.com> wrote:
>> On 1/20/2024 10:26 AM, Alan Mackenzie wrote:
>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>> On 1/20/2024 9:43 AM, Alan Mackenzie wrote:
>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>> On 1/20/2024 4:41 AM, Alan Mackenzie wrote:
>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>>> On 1/19/2024 6:01 PM, Alan Mackenzie wrote:
>>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>>>>> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>>>>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>
>>>>>>> [ .... ]
>
>>>>>>>>>>>> In other words no one can possibly tell that the above
>>>>>>>>>>>> function will not halt until they waited an infinite amount
>>>>>>>>>>>> of time and saw that it did not halt. DUMB, DUMB, DUMB,
>>>>>>>>>>>> DUMB.
>
>>>>>>>>>>> That is why attempting to solve the halting problem with a
>>>>>>>>>>> simulator is not a sensible thing to do.
>
>>>>>>>>>> The best selling author of textbooks on the theory of
>>>>>>>>>> computation disagrees.
>
>>>>>>>>> He does not. This author knows full well that a halting
>>>>>>>>> decider cannot be built, as do millions of students and
>>>>>>>>> graduates world wide, who have seen a proof (or even written
>>>>>>>>> one) and appreciate its clarity, simplicity, and finality.
>
>>>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>
>>>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>>>> MIT Professor Michael Sipser has agreed that the following
>>>>>>>>>>> verbatim paragraph is correct (he has not agreed to anything
>>>>>>>>>>> else in this paper):
>
>>>>>>>>>>> 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.
>
>>>>>>>>>>> When one accepts this definition of a simulating halt decider
>>>>>>>>>>> then my code shows that H correctly determines the halt
>>>>>>>>>>> status of D.
>
>>>>>>>>> I haven't seen you define a halting decider of any type over
>>>>>>>>> the last few years.
>
>>>>>>>> When you ignore what I say THIS DOES NOT COUNT AS ME NOT SAYING
>>>>>>>> IT. Professor Sipser agreed that the following definition of a
>>>>>>>> simulating halt decider is correct
>
>>>>>>> It's like the good professor agreeing that if pigs had wings,
>>>>>>> they would fly.
>
>>>>>> Not at all. He would not risk his credibility that way.
>>>>>> He gave me permission to quote him.
>
>>>>> He would not be risking his credibility.
>
>>> You've got no reply to this, I see.
>
> You've still got no reply.
>
>>>> (a) If simulating termination analyzer H correctly determines that D
>>>> correctly simulated by H cannot possibly reach its own simulated final
>>>> state and terminate normally then
>
>>>> (b) H can abort its simulation of D and correctly report that D
>>>> specifies a non-halting sequence of configurations.
>
>>>> That you do not understand that the above is correct proves
>>>> that you are insufficiently competent to review my work.
>
>>> I understand it fully, thank you very much. You fail to understand it.
>>> If I write "if I correctly state that pigs can fly, then bacon will
>>> correctly go up", then that is the truth, just as much as your (a). It's
>>> inane nonsense, of course, just as your (a) is nonsense.
>
>>>> There has been a very extensive reviews of this in comp.theory back in
>>>> 10/13/2022. You can go see what many other people have said. It was
>>>> resolved that Professor Sipser really meant to agree with these words.
>
>>> I read, or at least perused, it at the time. The resolution certainly
>>> was not that Professor Sipser likely agreed with what you would
>>> like him to agree with.
>
>
>> *That is the strawman deception and you know it*
>
> That's an unwarranted insult. It was what I surmised from those
> exchanges at the time. You likely have a different impression of them,
> just as you have different impressions of lots of things you post here.
>
>> You claimed that he agreed with nonsense and this is provably false.
>> He agreed that my verbatim words are correct. He did not agree with
>> nonsense.
>
> He both agreed that your verbatim words were correct and
> agreed with nonsense. Those words, although pedantically
> true, _are_ inane nonsense,

The consensus of opinion at the time was that he
agreed to those literal words and those literal
words were correct thus not nonsense, thus yet
again the strawman deception on your part.

--
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/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.

>
> Begin Local Halt Decider Simulation        Execution Trace Stored at:113027
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> 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
> [00001c42][0015da3b][0015da3f] 55         push ebp
> [00001c43][0015da3b][0015da3f] 8bec       mov ebp,esp
> [00001c45][0015da37][0014da0b] 51         push ecx
> [00001c46][0015da37][0014da0b] 8b4508     mov eax,[ebp+08] ; DD
> [00001c49][0015da33][00001c42] 50         push eax         ; DD
> [00001c4a][0015da33][00001c42] 8b4d08     mov ecx,[ebp+08] ; DD
> [00001c4d][0015da2f][00001c42] 51         push ecx         ; DD
> [00001c4e][0015da2b][00001c53] e80ff7ffff call 00001362    ; HH
> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>
> _DD()
> [00001c42] 55         push ebp
> [00001c43] 8bec       mov ebp,esp
> [00001c45] 51         push ecx
> [00001c46] 8b4508     mov eax,[ebp+08] ; DD
> [00001c49] 50         push eax         ; DD
> [00001c4a] 8b4d08     mov ecx,[ebp+08] ; DD
> [00001c4d] 51         push ecx         ; DD
> [00001c4e] e80ff7ffff call 00001362    ; HH
> [00001c53] 83c408     add esp,+08
> [00001c56] 8945fc     mov [ebp-04],eax
> [00001c59] 837dfc00   cmp dword [ebp-04],+00
> [00001c5d] 7402       jz 00001c61
> [00001c5f] ebfe       jmp 00001c5f
> [00001c61] 8b45fc     mov eax,[ebp-04]
> [00001c64] 8be5       mov esp,ebp
> [00001c66] 5d         pop ebp
> [00001c67] c3         ret
> Size in bytes:(0038) [00001c67]
>
>

On 1/20/24 11:29 AM, olcott wrote:
> On 1/20/2024 10:14 AM, Fred. Zwarts wrote:
>> Op 20.jan.2024 om 15:50 schreef olcott:
>>> On 1/20/2024 4:17 AM, Fred. Zwarts wrote:
>>
>>>> It is not D that has a pathological self-reference. D has no
>>>> self-reference. It is H that has a self-reference. It uses its own
>>>> address.
>>>>
>>>
>>> *D specifies that it calls its own termination analyzer*
>>> *so you are wrong, D was intentionally defined to thwart H*
>>
>> So Olcott can not point to a self-reference in D
>
> *The self-reference in DD is when DD calls HH with itself*
> Its not that hard, I don't understand why you are not getting it.

Except it doesn't, DD just call HH with two copies of its parameter.

DD has NO "references" to anything, just a description of some arbirtary
program.

You don't seem to understand the fundamental meaning of a "Reference".

>
>> and he denies that H has a self-reference, even if Olcott tells us
>> that it uses its own address.
>> What problem does he/it have with the term self-reference?
>>
>> I am more and more convinced that Olcott is/uses an AI program that
>> produces his contributions, because it keeps repeating things that are
>> wrong and his replies are not logical, or do not have a relation with
>> the text it refers to.
>>
>

On 1/20/24 9:59 AM, olcott wrote:
> On 1/20/2024 4:41 AM, Alan Mackenzie wrote:
>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>> On 1/19/2024 6:01 PM, Alan Mackenzie wrote:
>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>
>> [ .... ]
>>
>>>>>>> In other words no one can possibly tell that the above function
>>>>>>> will not halt until they waited an infinite amount of time and saw
>>>>>>> that it did not halt. DUMB, DUMB, DUMB, DUMB.
>>
>>>>>> That is why attempting to solve the halting problem with a simulator
>>>>>> is not a sensible thing to do.
>>
>>>>> The best selling author of textbooks on the theory of computation
>>>>> disagrees.
>>
>>>> He does not.  This author knows full well that a halting decider
>>>> cannot be built, as do millions of students and graduates world wide,
>>>> who have seen a proof (or even written one) and appreciate its
>>>> clarity, simplicity, and finality.
>>
>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>
>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>> MIT Professor Michael Sipser has agreed that the following verbatim
>>>>>> paragraph is correct (he has not agreed to anything else in this
>>>>>> paper):
>>
>>>>>> 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.
>>
>>>>>> When one accepts this definition of a simulating halt decider then
>>>>>> my code shows that H correctly determines the halt status of D.
>>
>>>> I haven't seen you define a halting decider of any type over the last
>>>> few years.
>>
>>> When you ignore what I say THIS DOES NOT COUNT AS ME NOT SAYING IT.
>>> Professor Sipser agreed that the following definition of a simulating
>>> halt decider is correct
>>
>> It's like the good professor agreeing that if pigs had wings, they
>> would fly.
>
> Not at all. He would not risk his credibility that way.
> He gave me permission to quote him.
>
>> And you're taking that as a license to discuss the pigs' flying
>> techniques, their lift to drag ratio, and so on.  In reality pigs don't
>> have wings, and they certainly don't fly.
>>
>> Professor Sipser said what he had to say to avoid getting drawn into an
>> interminable time wasting exchange with a crank.  He's got other things
>> to do.
>>
>
> I told him that I waited two years before I first called him
> so that I did not waste his time. He agreed that I could
> quote him, he would not have done that if he thought what
> he was agreeing to was nonsense.
>

No, he knew that by your quoting him, you would just be reveiling your
own stupidity and ignorance.

>>> 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.
>>
>>> Did you notice that it says: "simulating halt decider H"
>>
>> Yes.  But you haven't yet noticed that little word "if" at the beginning
>> of his sentence.  There is no such thing as a halt decider, simulating or
>> otherwise, so you could just as well write "If simulating halt decider H
>> correctly simulates its input D, then pigs would fly.", and it would be
>> just as true.  But just as meaningless and not at all sensible.
>>
>
> Technically in my case it is a partial halt decider or a termination
> analyzer. Professor Sipser knew that he was only agreeing that a
> specific H/D pair would be decidable as non-halting when the criteria
> has been met.
>

Right, and since the H that answer never does a correct simulation per
the definition in compuation theory, statement (a) become "true" by the
rule that an implication based on a false antecedent is always true, as
it never implies anything.

> Here is my updated paraphrase of (a)
> (a) If simulating termination analyzer H correctly determines that D
> correctly simulated by H cannot possibly reach its own simulated final
> state and terminate normally then

But "paraphrasing" just shows that you are afraid to post the ACTUAL
quotation as that may point out more clearly what you are misunderstanding.

Since THIS H (which is the only one that counts) doesn't do a correct
simulation, it is impossible to conclude ANYTHING about what would
happen if it did. Programs don't work that way.

You are just proving yourself to be a LIAR>

>
>>> --
>>> 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/24 11:06 AM, olcott wrote:
> On 1/20/2024 9:43 AM, Alan Mackenzie wrote:
>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>> On 1/20/2024 4:41 AM, Alan Mackenzie wrote:
>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>> On 1/19/2024 6:01 PM, Alan Mackenzie wrote:
>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>
>>>> [ .... ]
>>
>>>>>>>>> In other words no one can possibly tell that the above function
>>>>>>>>> will not halt until they waited an infinite amount of time and saw
>>>>>>>>> that it did not halt. DUMB, DUMB, DUMB, DUMB.
>>
>>>>>>>> That is why attempting to solve the halting problem with a
>>>>>>>> simulator
>>>>>>>> is not a sensible thing to do.
>>
>>>>>>> The best selling author of textbooks on the theory of computation
>>>>>>> disagrees.
>>
>>>>>> He does not.  This author knows full well that a halting decider
>>>>>> cannot be built, as do millions of students and graduates world wide,
>>>>>> who have seen a proof (or even written one) and appreciate its
>>>>>> clarity, simplicity, and finality.
>>
>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>
>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>> MIT Professor Michael Sipser has agreed that the following verbatim
>>>>>>>> paragraph is correct (he has not agreed to anything else in this
>>>>>>>> paper):
>>
>>>>>>>> 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.
>>
>>>>>>>> When one accepts this definition of a simulating halt decider then
>>>>>>>> my code shows that H correctly determines the halt status of D.
>>
>>>>>> I haven't seen you define a halting decider of any type over the last
>>>>>> few years.
>>
>>>>> When you ignore what I say THIS DOES NOT COUNT AS ME NOT SAYING IT.
>>>>> Professor Sipser agreed that the following definition of a simulating
>>>>> halt decider is correct
>>
>>>> It's like the good professor agreeing that if pigs had wings,
>>>> they would fly.
>>
>>> Not at all. He would not risk his credibility that way.
>>> He gave me permission to quote him.
>>
>> He would not be risking his credibility.
>
> (a) If simulating termination analyzer H correctly determines that D
> correctly simulated by H cannot possibly reach its own simulated final
> state and terminate normally then
>
> (b) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
>
> That you do not understand that the above is correct proves
> that you are insufficiently competent to review my work.

And does THIS H do a correct simulation of the input (remember, aborted
simulation are not correct).

Does an actual unaborted (and thus correct) simulation of this exact
input (that still calls this H) not Halt (it must Halt since the direct
execution does, and the DEFINITION of "correct simulation" is one that
does exactly like the direct execution.

>
> There has been a very extensive reviews of this in
> comp.theory back in 10/13/2022. You can go see what
> many other people have said. It was resolved that
> Professor Sipser really meant to agree with these
> words.
>
> 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.
>
>

And again, if the correct simulation of the input, and all correct
simulation will behave the same (since the input is supposed to be a
computation) will reach a final state, this isn't satisfied, and since
you agree that DD(DD) does halt, the correct simulation does halt and
thus you can't use (b)

The fundamental problem is you don't understand the definition of
"Correct Simulation" and are using a wrong definiton, sometimes even
claiming you are allowed to change it., which you can't

On 1/20/24 9:50 AM, olcott wrote:
> On 1/20/2024 4:17 AM, Fred. Zwarts wrote:
>> Op 20.jan.2024 om 01:36 schreef olcott:
>>> On 1/19/2024 6:08 PM, Richard Damon wrote:
>>
>>>
>>> The definition of correct simulation simply presumed
>>> that pathological self-reference does not change the
>>> execution sequence because no one ever bothered to
>>> carefully examined this.
>>>
>>> Naive set theory presumed that its definition of {set}
>>> was correct and ZFC proved that it was not correct.
>>>
>>> Since it is a verified fact that D correctly simulated by
>>> H1 depends on H aborting its simulation and H cannot
>>> depend on this it is proved that they are not the same.
>>
>> It is not D that has a pathological self-reference. D has no
>> self-reference. It is H that has a self-reference. It uses its own
>> address.
>>
>
> *D specifies that it calls its own termination analyzer*
> *so you are wrong, D was intentionally defined to thwart H*

And what is wrong about that.

Note, D thwarts a SPECIFIC decider H, not "all H's".

You don't seem to understand the difference, because you don't know what
a program actually is.

>
>> It is not D that contradicts itself. It is H that contradicts itself:
>> At the one hand it says that, when called, it has infinite recursion,
>> but at the other hand it aborts and returns a result, which is a
>> contradiction.
>
> DD correctly simulated by HH is a different computation
> than the directly executed DD(DD).

CAN'T BE, BY DEFINITION, So you are just admitting to being a LIAR

>
> This is proven by their differing execution traces:
> (a) DD simulated by HH cannot possibly reach its own final state.

Only because HH "Gave Up" and aborted its simulation, and thus didn't do
a "Correct Simulation" as defined by Computation Theory (and that
definition is absolutely needed to replace the direct execution with a
Correct Simulation)

> (b) The directly executed DD(DD) does reach its own final state.

WHich proves that HH(DD,DD) returns 0, and thus a "Correct Simulation"
of the call to HH(DD,DD) inside DD(DD) must show that HH(DD,DD) will
return 0.

Any other behavior, just violates the meaning of "correct"

>
> *That people disagree with execution traces is a little nutty*
> *It is like disagreeing with arithmetic*

Nope, YOU are the one disagreeing with the plain facts.

The actual call to HH(DD,DD) is KNOW to return 0.

Thus, by any reasonable definition of "Correct Simulation" a correct
simulaiton of such a call must show the same thing.

>
> That people disagree with the execution trace of DD correctly
> simulated by HH yet will not show how to correct it is a little
> deceitful. It is like they know they are wrong and refuse to admit it.
>

Except you have no "Corrects Simulation" of DD by the specified HH, it
always aborts its simulation and beleives the LIE that HH(DD,DD) will
not return.

You then LIE about a DIFFERENT MACHINE that you also intentionally
deceptively call HH, but which ISN'T the HH of the actual problem, and
give it a DIFFERENT DD, that calls this modified HH.

>>
>> Olcott wants to reject self-referencing contradictions, so he should
>> reject H, not D.
>>
>
> *D was intentionally defined to thwart H so the fault lies with D*
>

Nope. H claim to handle ALL input, and that is A input.

The fault lies with Olcott who claims that H correct does something it
does do, and play "shell games" switch H and D around, proving that he
is nothing but a dispicable LIAR.

On 1/20/24 10:38 AM, olcott wrote:
> On 1/20/2024 4:04 AM, immibis wrote:
>> On 1/20/24 01:55, olcott wrote:
>>>
>>> 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
>>> [00001c42][0015da3b][0015da3f] 55          push ebp
>>> [00001c43][0015da3b][0015da3f] 8bec        mov ebp,esp
>>> [00001c45][0015da37][0014da0b] 51          push ecx
>>> [00001c46][0015da37][0014da0b] 8b4508      mov eax,[ebp+08] ; DD
>>> [00001c49][0015da33][00001c42] 50          push eax         ; DD
>>> [00001c4a][0015da33][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
>>> [00001c4d][0015da2f][00001c42] 51          push ecx         ; DD
>>> [00001c4e][0015da2b][00001c53] e80ff7ffff  call 00001362    ; HH
>>> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>>>
>>> That you cannot tell that the above specifies
>>> non-halting behavior makes you a dunderhead.
>>>
>>
>> This trace dishonestly ignores the instructions that tell HH to check
>> for non-halting repeated patterns.
>
> Nothing that HH can possibly do can cause DD correctly
> simulated by HH to reach its own simulated final state.
>
> Anyone that does not know this is unqualified to review
> my work.
>

Only because HH can not correct simulate this input and give an answer.

Your criteria is IMPOSSIBLE to meet, and thus is an INVALID question by
your own rules.

The ACTUAL Halting question has an answer, and HH fails to give it, so
is just an incorrect Halt Decider, even if it might be able to claim
that the input is invalid for a PO-Decider.

On 1/20/24 10:43 AM, olcott wrote:
> On 1/20/2024 4:04 AM, immibis wrote:
>> On 1/20/24 02:26, olcott wrote:
>>>
>>> The full state of D was repeated.
>>> The only thing that changed was the stack address.
>>>
>> You think the stack address doesn't matter?
>
> That each process context has its own stack cannot possibly
> have any effect on the halt status determination.

Why?

Why can't the earlier simulator use information from later simulations
(that it is doing) to decide what to do?

Remember, H is DEFINED to be able to abort, so every H has the potential
to abort.

>
> That you don't know this proves that you are insufficiently
> technically competent to review my work.
>

Your inability to answer this proves that YOU are technically
incompetent to judge your own work.

On 1/20/24 10:56 AM, olcott wrote:
> On 1/20/2024 4:07 AM, immibis wrote:
>> On 1/20/24 01:36, olcott wrote:
>>>
>>> The definition of correct simulation simply presumed
>>> that pathological self-reference does not change the
>>> execution sequence because no one ever bothered to
>>> carefully examined this.
>>>
>>> Naive set theory presumed that its definition of {set}
>>> was correct and ZFC proved that it was not correct.
>>>
>>> Since it is a verified fact that D correctly simulated by
>>> H1 depends on H aborting its simulation and H cannot
>>> depend on this it is proved that they are not the same.
>>>
>>>
>>
>> A Turing machine/initial tape pair has only one execution sequence.
>
> The Peter Linz Proof version of H1 is called H.
> The Peter Linz Proof version of H is called embedded_H.

The Peter Linz proof never mentioned and "H1"

>
> Because ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly
> reach its own simulated final state of ⟨Ĥ.qn⟩ and halt
> embedded_H correctly transitions to its own final state of Ĥ.qn.
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to embedded_H
> (b) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied to
> ⟨Ĥ⟩
> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>
>

Nope, you don't understand how simulation works.

All the simulation is part of the ⊢* code, and never gets back to ⟨Ĥ.q0⟩
like you try to draw an arrow.

Per your description, the copy of H in the actual Peter Linz Proof, is
given the descripion of the input and simulates it, and then at some
point, by your claims, it detects that its simulation has detected that
the simulated program is entering its copy of H and H then decides that
this is enough evidence of non-halting that H goes to its Qn, which is
also Ĥ.qn and the machine halts, thus showing that the compuation it was
deciding on WILL HALT (since it is a copy of what was just run)

Since ALL copies of H behave the same for the same input, and ALL copies
of Ĥ behave the same for the same input, we have just shown that for all
cases Ĥ (Ĥ) will Halt, but H (Ĥ) (Ĥ) which asks about this goes to Qn,
which it should onlu do it the input given represent a non-halting
computation, we have shown that H just fails to meet its requirements.

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.
>

On 1/20/24 12:38 PM, olcott wrote:
> On 1/20/2024 11:23 AM, Alan Mackenzie wrote:
>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>> On 1/20/2024 10:26 AM, Alan Mackenzie wrote:
>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>> On 1/20/2024 9:43 AM, Alan Mackenzie wrote:
>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>> On 1/20/2024 4:41 AM, Alan Mackenzie wrote:
>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>>>> On 1/19/2024 6:01 PM, Alan Mackenzie wrote:
>>>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>>>>>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>
>>>>>>>> [ .... ]
>>
>>>>>>>>>>>>> In other words no one can possibly tell that the above
>>>>>>>>>>>>> function will not halt until they waited an infinite amount
>>>>>>>>>>>>> of time and saw that it did not halt. DUMB, DUMB, DUMB,
>>>>>>>>>>>>> DUMB.
>>
>>>>>>>>>>>> That is why attempting to solve the halting problem with a
>>>>>>>>>>>> simulator is not a sensible thing to do.
>>
>>>>>>>>>>> The best selling author of textbooks on the theory of
>>>>>>>>>>> computation disagrees.
>>
>>>>>>>>>> He does not.  This author knows full well that a halting
>>>>>>>>>> decider cannot be built, as do millions of students and
>>>>>>>>>> graduates world wide, who have seen a proof (or even written
>>>>>>>>>> one) and appreciate its clarity, simplicity, and finality.
>>
>>>>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>
>>>>>>>>>>> On 10/13/2022 11:46 AM, olcott wrote:
>>>>>>>>>>>> MIT Professor Michael Sipser has agreed that the following
>>>>>>>>>>>> verbatim paragraph is correct (he has not agreed to anything
>>>>>>>>>>>> else in this paper):
>>
>>>>>>>>>>>> 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.
>>
>>>>>>>>>>>> When one accepts this definition of a simulating halt decider
>>>>>>>>>>>> then my code shows that H correctly determines the halt
>>>>>>>>>>>> status of D.
>>
>>>>>>>>>> I haven't seen you define a halting decider of any type over
>>>>>>>>>> the last few years.
>>
>>>>>>>>> When you ignore what I say THIS DOES NOT COUNT AS ME NOT SAYING
>>>>>>>>> IT.  Professor Sipser agreed that the following definition of a
>>>>>>>>> simulating halt decider is correct
>>
>>>>>>>> It's like the good professor agreeing that if pigs had wings,
>>>>>>>> they would fly.
>>
>>>>>>> Not at all. He would not risk his credibility that way.
>>>>>>> He gave me permission to quote him.
>>
>>>>>> He would not be risking his credibility.
>>
>>>> You've got no reply to this, I see.
>>
>> You've still got no reply.
>>
>>>>> (a) If simulating termination analyzer H correctly determines that D
>>>>> correctly simulated by H cannot possibly reach its own simulated final
>>>>> state and terminate normally then
>>
>>>>> (b) H can abort its simulation of D and correctly report that D
>>>>> specifies a non-halting sequence of configurations.
>>
>>>>> That you do not understand that the above is correct proves
>>>>> that you are insufficiently competent to review my work.
>>
>>>> I understand it fully, thank you very much.  You fail to understand it.
>>>> If I write "if I correctly state that pigs can fly, then bacon will
>>>> correctly go up", then that is the truth, just as much as your (a).
>>>> It's
>>>> inane nonsense, of course, just as your (a) is nonsense.
>>
>>>>> There has been a very extensive reviews of this in comp.theory back in
>>>>> 10/13/2022. You can go see what many other people have said. It was
>>>>> resolved that Professor Sipser really meant to agree with these words.
>>
>>>> I read, or at least perused, it at the time.  The resolution certainly
>>>> was not that Professor Sipser likely agreed with what you would
>>>> like him to agree with.
>>
>>
>>> *That is the strawman deception and you know it*
>>
>> That's an unwarranted insult.  It was what I surmised from those
>> exchanges at the time.  You likely have a different impression of them,
>> just as you have different impressions of lots of things you post here.
>>
>>> You claimed that he agreed with nonsense and this is provably false.
>>> He agreed that my verbatim words are correct. He did not agree with
>>> nonsense.
>>
>> He both agreed that your verbatim words were correct and agreed with
>> nonsense.  Those words, although pedantically true, _are_ inane nonsense,
>
> The consensus of opinion at the time was that he
> agreed to those literal words and those literal
> words were correct thus not nonsense, thus yet
> again the strawman deception on your part.
>

And that the literal words say that if a correct simulation of the input
halts (by anyone, since all correct simulation of a given input are the
same) then H can not abort its simulation.

Your interpretation of the statement renders it moot, as since changing
H changes the input computation, only if H actually DOES a correct
simulation of the input (which means it can't abort its simulatioN) can
it abort its simulation, but it then can't by definition.

The verison that Proessor Sipser was using was that if you COULD change
JUST THE H deciding (and not any other copies elsewhere, which is how
Turing Machines actually work) to not abort but correct simulate, and
show that this verision would nevef halt, then the original version
could abort the simulation.

Of course, if we try this (after fixing your system to allow this) we
see that the simulation DOES halt, so H never had valid ground to abort
its simulation, and thus gives an answer in error.

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.

On 1/20/2024 11:10 AM, immibis wrote:
> On 1/20/24 16:38, olcott wrote:
>> On 1/20/2024 4:04 AM, immibis wrote:
>>> On 1/20/24 01:55, olcott wrote:
>>>>
>>>> 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
>>>> [00001c42][0015da3b][0015da3f] 55          push ebp
>>>> [00001c43][0015da3b][0015da3f] 8bec        mov ebp,esp
>>>> [00001c45][0015da37][0014da0b] 51          push ecx
>>>> [00001c46][0015da37][0014da0b] 8b4508      mov eax,[ebp+08] ; DD
>>>> [00001c49][0015da33][00001c42] 50          push eax         ; DD
>>>> [00001c4a][0015da33][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
>>>> [00001c4d][0015da2f][00001c42] 51          push ecx         ; DD
>>>> [00001c4e][0015da2b][00001c53] e80ff7ffff  call 00001362    ; HH
>>>> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>>>>
>>>> That you cannot tell that the above specifies
>>>> non-halting behavior makes you a dunderhead.
>>>>
>>>
>>> This trace dishonestly ignores the instructions that tell HH to check
>>> for non-halting repeated patterns.
>>
>> Nothing that HH can possibly do can cause DD correctly
>> simulated by HH to reach its own simulated final state.
>
> HH detects a non-halting pattern and returns 0,
> which causes DD to reach its final state.
>

DD keeps HH stuck in recursive simulation until HH sees this
and aborts its simulation making it impossible for any simulated
HH to return any value to a simulated DD.

If you were an expert in the C programming language this
would be dead obvious to you. That you disagree on the basis
of your ignorance cannot possibly be a valid rebuttal.

--
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 11:11 AM, immibis wrote:
> On 1/20/24 16:43, olcott wrote:
>> On 1/20/2024 4:04 AM, immibis wrote:
>>> On 1/20/24 02:26, olcott wrote:
>>>>
>>>> The full state of D was repeated.
>>>> The only thing that changed was the stack address.
>>>>
>>> You think the stack address doesn't matter?
>>
>> That each process context has its own stack cannot possibly
>> have any effect on the halt status determination.
>>
>> That you don't know this proves that you are insufficiently
>> technically competent to review my work.
>>
>
> You keep saying the code address matters even if the code at that
> address is identical.
>
> By the same logic the stack address matters, even if the data on the
> stack is identical.

That is not the same logic. Why do you insist
on relying on your own ignorance as a basis?

--
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 11:11 AM, immibis wrote:
> On 1/20/24 16:56, olcott wrote:
>> On 1/20/2024 4:07 AM, immibis wrote:
>>> On 1/20/24 01:36, olcott wrote:
>>>>
>>>> The definition of correct simulation simply presumed
>>>> that pathological self-reference does not change the
>>>> execution sequence because no one ever bothered to
>>>> carefully examined this.
>>>>
>>>> Naive set theory presumed that its definition of {set}
>>>> was correct and ZFC proved that it was not correct.
>>>>
>>>> Since it is a verified fact that D correctly simulated by
>>>> H1 depends on H aborting its simulation and H cannot
>>>> depend on this it is proved that they are not the same.
>>>>
>>>>
>>>
>>> A Turing machine/initial tape pair has only one execution sequence.
>>
>> The Peter Linz Proof version of H1 is called H.
>> The Peter Linz Proof version of H is called embedded_H.
>>
>> Because ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly
>> reach its own simulated final state of ⟨Ĥ.qn⟩ and halt
>> embedded_H correctly transitions to its own final state of Ĥ.qn.
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>> (b) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩ applied
>> to ⟨Ĥ⟩
>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the process
>>
>>
> Nonetheless, it is a verified fact that a Turing machine/initial tape
> pair has only one execution sequence.

(a) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩
has a different execution sequence than
(b) H applied ⟨Ĥ⟩ ⟨Ĥ⟩

(c) D correctly simulated by H
has a different execution sequence than
(d) D correctly simulated by H1

The only salient difference between (a) and (b)
and (c) and (d) is that in the first element of
the pair the input calls its own decider and the
second element of the pair the input does not
call its own decider.

--
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 11:12 AM, immibis wrote:
> On 1/20/24 15:50, olcott wrote:
>> DD correctly simulated by HH is a different computation
>> than the directly executed DD(DD).
>
> Thank you for confirming this. This proves that HH is an incorrect
> simulator. NEXT!
>

(a) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩
has a different execution sequence than
(b) H applied ⟨Ĥ⟩ ⟨Ĥ⟩

(c) D correctly simulated by H
has a different execution sequence than
(d) D correctly simulated by H1

The only salient difference between (a) and (b)
and (c) and (d) is that in the first element of
the pair the input calls its own decider and the
second element of the pair the input does not
call its own decider.

embedded_H is the exact same code as H.
embedded_H is merely the exact same code
as H embedded within Ĥ.

--
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 11:13 AM, immibis wrote:
> On 1/20/24 17:14, Fred. Zwarts wrote:
>>
>> I am more and more convinced that Olcott is/uses an AI program that
>> produces his contributions, because it keeps repeating things that are
>> wrong and his replies are not logical, or do not have a relation with
>> the text it refers to.
>>
>
> Unfortunately, olcott has been around much longer than GPT-2.
Since 2004 in these forums.

--
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 11:13 AM, immibis wrote:
> On 1/20/24 17:29, olcott wrote:
>> On 1/20/2024 10:14 AM, Fred. Zwarts wrote:
>>> Op 20.jan.2024 om 15:50 schreef olcott:
>>>> On 1/20/2024 4:17 AM, Fred. Zwarts wrote:
>>>
>>>>> It is not D that has a pathological self-reference. D has no
>>>>> self-reference. It is H that has a self-reference. It uses its own
>>>>> address.
>>>>>
>>>>
>>>> *D specifies that it calls its own termination analyzer*
>>>> *so you are wrong, D was intentionally defined to thwart H*
>>>
>>> So Olcott can not point to a self-reference in D
>>
>> *The self-reference in DD is when DD calls HH with itself*
>
> DD doesn't call HH with itself. DD calls HH with DD's argument, twice.

When HH(DD,DD) is invoked then the simulated DD calls
HH with two copies of its own machine address.

Why use weasel words and double-talk to try to get
away with denying this?

--
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 11:17 AM, immibis wrote:
> On 1/20/24 15:59, olcott wrote:
>> On 1/20/2024 4:41 AM, Alan Mackenzie wrote:
>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>> When you ignore what I say THIS DOES NOT COUNT AS ME NOT SAYING IT.
>>>> Professor Sipser agreed that the following definition of a simulating
>>>> halt decider is correct
>>>
>>> It's like the good professor agreeing that if pigs had wings, they
>>> would fly.
>>
>> Not at all. He would not risk his credibility that way.
>> He gave me permission to quote him.
>
> There is no risk to your credibility by saying that if pigs had wings,
> they would fly. It is most likely true that if pigs had wings, they
> would fly. However, pigs do not have wings, and simulating halt decider
> H does not correctly simulate its input until H correctly determines
> that its simulated D would never stop running unless aborted.
>
>>>
>>> Yes.  But you haven't yet noticed that little word "if" at the beginning
>>> of his sentence.  There is no such thing as a halt decider,
>>> simulating or
>>> otherwise, so you could just as well write "If simulating halt decider H
>>> correctly simulates its input D, then pigs would fly.", and it would be
>>> just as true.  But just as meaningless and not at all sensible.
>>>
>>
>> Technically in my case it is a partial halt decider or a termination
>> analyzer. Professor Sipser knew that he was only agreeing that a
>> specific H/D pair would be decidable as non-halting when the criteria
>> has been met.
>
> It gives the wrong answer on the program it's designed to give a right
> answer for.
>
>>
>> Here is my updated paraphrase of (a)
>> (a) If simulating termination analyzer H correctly determines that D
>> correctly simulated by H cannot possibly reach its own simulated final
>> state and terminate normally then
>
> That's the same thing. It doesn't matter whether you call it a halt
> decider or a termination analyzer. Those are two different names for the
> same thing and H does not correctly determine that D correctly simulated
> by H cannot possibly reach its own simulated final state and terminate
> normally.
>

The consensus of opinion at the time was that Professor
Sipser agreed with my words and my words are correct.

The two objections were:
(a) My own words do not mean what I think they mean.
(b) DD is not correctly simulated by HH.

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.

--
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 11:20 AM, immibis wrote:
> On 1/20/24 16:25, olcott wrote:
>> On 1/20/2024 4:01 AM, immibis wrote:
>>> On 1/19/24 23:46, olcott wrote:
>>>> On 1/19/2024 4:40 PM, immibis wrote:
>>>>> On 1/19/24 23:22, olcott wrote:
>>>>>> On 1/19/2024 3:41 PM, immibis wrote:
>>>>>>> On 1/19/24 22:12, olcott wrote:
>>>>>>>> On 1/19/2024 2:44 PM, immibis wrote:
>>>>>>>>> On 1/19/24 19:56, olcott wrote:
>>>>>>>>>> On 1/19/2024 12:16 PM, immibis wrote:
>>>>>>>>>>> On 1/19/24 17:14, olcott wrote:
>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>> Deciders always must compute the mapping from an input
>>>>>>>>>>>>>> finite string to
>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Definition of the HP based on the above definition of a
>>>>>>>>>>>>>> decider*
>>>>>>>>>>>>>> In computability theory, the halting problem is the
>>>>>>>>>>>>>> problem of
>>>>>>>>>>>>>> determining, whether an input finite string pair of
>>>>>>>>>>>>>> program/input
>>>>>>>>>>>>>> specifies a computation that would reach a final state and
>>>>>>>>>>>>>> terminate
>>>>>>>>>>>>>> normally.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Definition of halt decider based on the above definitions*
>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>>>> simulated final
>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>
>>>>>>>>>>>>> a input finite string pair of program/input specifies a
>>>>>>>>>>>>> computation that would reach a final state and terminate
>>>>>>>>>>>>> normally
>>>>>>>>>>>>>
>>>>>>>>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>> H correctly determines that D correctly simulated *by H*
>>>>>>>>>>>>> cannot possiby reach its own simulated final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> H is not allowed to simply ignore that D would detect
>>>>>>>>>>> infinite recursion, stop simulating and reach a final state.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *This is simply over your head*
>>>>>>>>>> Unless the outermost HH aborts its simulation then none of
>>>>>>>>>> them do.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Each simulated HH has the exact same instructions as the
>>>>>>>> others because it <is> the same code at the same machine
>>>>>>>> address.
>>>>>>>
>>>>>>> Does the direct executed HH have the exact same instructions as
>>>>>>> each simulated HH?
>>>>>>>
>>>>>>
>>>>>> There is only one HH at machine address [00001032].
>>>>>>
>>>>>
>>>>> Does the direct executed HH have the exact same instructions as
>>>>> each simulated HH?
>>>>
>>>> There is only one HH at machine address [00001032].
>>>> There is only one HH at machine address [00001032].
>>>> There is only one HH at machine address [00001032].
>>>> There is only one HH at machine address [00001032].
>>>> There is only one HH at machine address [00001032].
>>>>
>>>> You must have ADD like Richard. I have to repeat
>>>> things to Richard hundreds of times before he ever
>>>> notices that I said them once.
>>>>
>>>
>>> Why can't you answer the question?
>>
>> I answered the question with all of the technical details
>> that prove the answer. If there is only one thing in the
>> universe then is this thing different than itself?
>>
>> There is only one HH in Halt7.c and it is never copied.
>>
> IF they are the same thing (whatever that means) then I am sure you
> agree they have the exact same instructions?

You did not seem to understand that a thing is necessarily the same as
itself.

--
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 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.